layout: true name: fullheader background-image: url(img/david-lezcano-120708-43.jpg) background-size: cover

layout: true name: flockbottom background-image: url(img/shwetha-shankar-137724-43.jpg) background-size: cover

layout: true name: palmsbottom background-image: url(img/jeremy-bishop-257105-43.jpg) background-size: cover

layout: true name: treeright background-image: url(img/meduana-178155-43.jpg) background-size: cover

layout: true name: beachbottom background-image: url(img/alexandre-perotto-46114-43.jpg) background-size: cover

layout: true name: pineapple background-image: url(img/pineapple-supply-co-64690-43.jpg) background-size: cover

layout: true name: closing background-image: url(img/deborah-kunzie-49758-43.jpg) background-size: cover

layout: true name: thanks background-image: url(img/stuart-guest-smith-150560-43.jpg) background-size: cover

layout: true name: menu background-image: url(img/lance-asper-153777-43.jpg) background-size: cover

layout: true name: fossneed background-image: url(img/love-maldives-57551-43.jpg) background-size: cover

layout: true name: logorb class: left background-image: url(img/thehub-logo.png) background-repeat: no-repeat background-position: 88% bottom background-size: 5% background-origin: padding-box

template: fullheader

Coming Up Next


The Apache Way: Effective Open Source Project Management


template: fullheader

The Apache Way

Effective Open Source Project Management


Shane Curcuru




The Apache Software Foundation



template: logorb

The Apache Way

Behaviors and practices developed by 100’s of projects at the ASF

Designed to promote long-lived successful projects

Focus on stable, independent governance and encouraging new contributors

??? This is a brief overview to the comprehensive set of behaviors and best practices developed over many years and hundreds of projects at the ASF. SPACEBAR

template: logorb

The Apache Way

Behaviors and practices developed by 100’s of projects at the ASF

Designed to promote long-lived successful projects

Focus on stable, independent governance and encouraging new contributors

Required behaviors for Apache projects!

??? These behaviors are required of Apache projects - but they will be useful in any distributed project.

template: logorb

Apache Way History

  • Creation of the ASF as a Foundation
    • Provides independent oversight
  • PMCs provide project governance
    • Experience across community styles
    • Effective in multiple industries

??? The behaviors of the Apache Way can be used by anyone, but are born out of extensive experience governing the 100’s of Apache Software Foundation projects ranging from high performance big data streaming tools to end user applications and everything in between.

Having an independent board overseeing all Apache PMCs ensures that governance stays independent; and having each PMC be in charge of their project as a whole keeps the focus on all users of the software.

template: logorb

Skip The History!

  • Long history of the Apache Way
  • Many painful lessons learned
  • Improvements from many sources
  • Copied by other foundations
    • What Can I Do Now?

??? But is that really important? You want to learn the behaviors, right? Actionable information. Let’s get to the good stuff - the behaviors that have worked well for 100’s of Apache projects, and have been copied across the industry.

But in a diverse and dispersed world, having the why behind the rule - or the rationale to the policy - is a key way to ensure the community can understand it, know it’s proven value, and then have an intelligent and focused way that we could work on changes. That’s still there - but we’ll save the whys for after we talk about the whats.

template: closing

Apache Way

Defining The Behaviors

template: menu name: menu

Apache Way: Menu

What do you want to talk about next?

??? Community Over Code also means that You Need To Participate.

Each of these is a set of topics about a kind of behaviors that Apache projects are expected to follow.
What do you want to talk about?

template: flockbottom name: community


.footnote[ Take a different way? | Continue On: Community ]

template: logorb


  • What kind of community do we mean?
    • We don’t live together
    • We don’t work together
    • We don’t know each other
  • Except through our project

.footnote[ Community ]

??? What does community mean here? Working on an independent open source project is very different than most other human activities. There are no other ties between people widely distributed in location, in time, in experience, and in jobs besides the project itself.

template: logorb


  • What kind of community do we mean?
    • We don’t live together
    • We don’t work together
    • We don’t know each other
  • Except through our project
  • Community includes developers, writers, testers, sysadmins, devops… and users

.footnote[ Community ]

??? The important thing is that the community owns the project. Not you, not me, not your company. All of us.

Importantly, users are not necessarily customers. The ways that you may be used to connecting with customers is different than effective ways to communicate and get feedback from other users of the product.

template: logorb

No Jerks Allowed

  • “No jerks allowed” - a key early message
    • We value group contributors, not lone wolves
    • Diverse communities attract new contributors
    • BDFL not allowed in Apache communities

.footnote[ Community ]

??? There are many ways to say this - No Jerks Allowed, Avoid Poisonous People, be decent, whatever. The point is, where everyone is a volunteer and most people are doing this as a side task or second effort, ensuring that everyone is welcome is the most important factor for a long-lived health project.

template: logorb

No Jerks Allowed

  • “No jerks allowed” - a key early message
    • We value group contributors, not lone wolves
    • Diverse communities attract new contributors
    • BDFL not allowed in Apache communities

Be Excellent To Each Other

.footnote[ Community ]

??? In the immortal words of Bill and Ted: Be Excellent To Each Other.

This is important for any community, and doubly so for Apache projects, since we’re all also part of the larger ASF community. We have a code of conduct - not because we want to use it, but because we don’t want to have to use it, since the great majority of our communities keep discussion polite to start with.

Remember: your community doesn’t work for you. It needs to be to their advantage to contribute to the project too - either in code, or docs, or answering questions on the mailing list.

template: logorb

Wear Your Hats

  • You are an individual - not an employee
  • No corporate participation at Apache
  • Individuals get recognition
    • Side effect for corporate teams: all team members participate separately
    • Side effect for you: your merit stays with you

.footnote[ Community ]

??? The ASF does not allow direct corporate participation in projects.
We only recognize individuals. Merit accrues to individuals, and they are expected to act for the best interests of the project as a whole.

This may be a polite fiction - many employment agreements mean you have to look out for your employer first - but it’s a key part of how our projects work.

This both ensures that newcomers - from big employers or small ones - are welcome in our projects, and also means that the merit you gain in an Apache project stays with you, no matter where you work. That helps encourage long-lived participants, across jobs.

exclude: true template: logorb

Check Affiliations At The Door

  • FOSS communities don’t have employees
  • Act as individuals
  • Volunteers all have same powers

Apache PMCs don’t care what your dayjob role is

.footnote[ Community ]

??? Wearing your project hat means you’re acting on behalf of the project as a whole, not your employer. Sometimes you need to do things as an employee; that’s fine. But mark it clearly, and when voting on serious project decisions, wear your project hat.

template: logorb

Independent Governance

  • ASF owns all trademarks
    • ASF ensures neutrality, open development
  • PMC owns project brand
    • PMCs govern independently

“It’s not a hierachy, it’s a community”

.footnote[ Community ]

??? The net effect of all the above is that projects are governed for the public good and the best interests of the project community as a whole.

PMCs are expected to make releases and vote in new committers based on merit - how much an individual creates value for that project.

When PMCs slack in their duties, the board is here to provide oversight and if necessary, correction. Both at the PMC level and the board level we expect people to act for the public good - and the fact we are a 501C3 organization, with directors elected from merit - not sponsor dollars - means we can back it up.

template: pineapple name: merit


.footnote[ Take a different way? | Continue On: Merit ]

template: logorb

What You Can Do

Defined by the value you bring to a project

In the context of that project by the project community

“You gain merit by doing things that a specific community values”

.footnote[ Merit ]

??? Meritocracy is a word we use that is often misunderstood - some other communities see it as having a different connotation than the ASF uses.

Your merit is the value you bring to a project as judged by that project’s community.

Every project is it’s own merit structure. Merit is not transferable, and it doesn’t expire. It may get stale, but it stays with you through jobs and careers.

template: logorb

Growth In Ability

The more you do, the more power you may be granted to take actions:

  • User
  • Contributor
    • Committer
    • PMC Member
    • PMC Chair / VP
  • ASF Member
    • Director

??? Each step is defined by the merit you are recognized for by that specific community. Each step means you can get a binding vote on new tasks.

While all committers can directly checkin code to their project(s), PMC members can also vote on new committers and on product releases.

ASF Members don’t have any extra abilities with projects; however they can vote for the board of directors. Directors don’t directly affect project technical direction, but do appoint corporate officers, and do provide social and organizational oversight to all Apache projects.

template: logorb

Not Authority

  • Leaders vs. managers

“Merit does not buy you authority: community must still agree”

“Merit gets you privileges: commit access, votes on committers”

.footnote[ Merit ]

??? You are still part of the community - it’s not a hierarchy; everyone with merit (commit bit) has a say in basic decisions.

Everyone can propose and do new work. Just because you might not find some new work valuable doesn’t mean some other part of the community doesn’t value the new work. Any vetoes (in the rare cases they are allowed) must have a technical justification.

template: logorb

Umbrella Projects

Problem area!

Apache Jakarta was an umbrella project - with many different subprojects and components - and communities.

The PMC must be a coherent community to be able to recognize merit in all contributors.

.footnote[ Merit ]

??? A cautionary tale: in the past, we have had successful projects that grew in scope - both technical and social - until they were too big to govern themselves effectively - either socially or technically.

When a project grows such that different groups of committers running modules can’t evaluate each other’s work - or vote on releases - it’s probably too big.

The board is here to backstop communities. Each community needs to be coherent and work as a single unit - when you’re bigger than that, you should split up into separate projects.

template: palmsbottom name: open

Open Development

.footnote[ Take a different way? | Continue On: Open Development ]

template: logorb

Time Shifting

  • Asynchronous communication is critical
    • …dispersed in space
    • …dispersed in abilities / expertise
    • …dispersed in motivation
    • …dispersed in time

.footnote[ Open Development ]

??? Yes, we use mailing lists!

Remember: we are a dispersed community, each with our own lives and jobs. We need to show the work we’re doing - and allow feedback - in whatever timeframe works for everyone else on the project. In many cases the only connection community members have to each other is through the code itself - and the mailing lists.

You don’t need to wait for everyone’s feedback - but you do need to recognize that sometimes other committers will have better ideas, or will be willing to do some of the work for you.

This is doubly important when your team works in open source: remember, the rest of the community isn’t around the coffeemaker in your office! Bring your discussions back to the list!

template: logorb

Archive Everything

If It Didn’t Happen On-List It Didn’t Happen

  • Must be public list unless there’s a reason
  • Asynchronous lists provide time for
    • Feedback
    • New ideas
    • Others to show their work

Allows newcomers to learn at any time

.footnote[ Open Development ]

??? Archiving everything means that newcomers can get up to speed with all the information of the project available for them. Even if your documentation doesn’t lead new users through this, having it available both for people to find, and especially for people to reference when questions come up is the most important thing.

This means that IRC, Slack, Hipchat, and the like must bring any interesting conversations back to the mailing list, so that the rest of the community can participate in any decisions.

exclude: true template: logorb

Project Motivation

  • Your motives aren’t transparent to the community
    • Motivated by your boss, by outside technical need, by just being a geek
  • New work should be done for benefit of project as a whole

.footnote[ Open Development ]

??? Ensuring decisions are made openly - when everyone has the same information and time to read it - is required of Apache projects. This is a key area where “corporate open source” falls short, and doesn’t truly practice “open development”.

Open source does not always mean open development.

Apache projects always practice open development - it’s required.

template: logorb

Transparent Decisions

The best way to work is to:

  1. Telegraph your intent
  2. Draft designs openly
  3. Submit work in chunks
  4. Welcome feedback along the way

.footnote[ Open Development ]

??? Ensuring the community has enough information on the work being done and coming up soon is important for open development. Just dumping complete code prevents others from adding their expertise or ideas - some of which may lead to better code than you’ve developed alone.

The best way to get something done well in open source is either to do everything yourself, or to implement something half-way - and wait to see how the rest of the community will improve your code.

template: logorb

Pragmatic License

  • Apache License v2.0
  • Maximum user freedom
  • Trust in ASF as corporation
    • To maintain open development
    • To continue to provide source code

Apache Attic - where quiet projects slumber

.footnote[ Open Development ]

??? A goal of the ASF is to encourage maximum inbound contributions. Using the broadly permissive Apache License v2.0 is a key part of this - both from the legal details point of view, and from our brand.

People trust they can just use stuff from Apache without being surprised by any unusual licenses or changes.

Stick with standard licenses, CLAs. Don’t customize - customizations, no matter how much your lawyers want them - scare off new contributors.

template: beachbottom name: decision

Decision Making

.footnote[ Take a different way? | Continue On: Decision Making ]

template: logorb

Consensus Preferred

  • Consensus within community
  • Choose best path forward
    • Or even an improvement
    • Your perfection may be someone else’s “meh”

.footnote[ Decision Making ]

??? There is no perfection - just getting better step by step. Our goal is to serve the public good, so any new features - as long as they don’t fail the tests or unduly slow down performance - is a good thing.

Consensus doesn’t mean everyone thinks it’s perfect - just that any proposed change is better somehow than we have now.

.footnote[ Decision Making ]

template: logorb

Vote Only When Needed

“Voting is a shortcut to move consensus forward in a timely manner”

“Voting is a way to record an official consensus”

.footnote[ Decision Making ]

??? Here are two quotes about voting - the +1/-1 you’ve all heard about. One of these is a good use of voting, the other is… not as good.

You must vote on releases. In some cases, the vote is the formal record that a PMC or the board made a decision. That keeps the decision as being an act of the ASF as a foundation, and not just a bunch of individual developers.

Voting to speed consensus… it can be OK in some cases, but where possible we prefer to work through to a better consensus. Some projects choose as a whole community to use votes more often, but it’s not required.

template: logorb


  • Minimum time to make a decision: 72 hours

  • Allows timeshifted input from community

.footnote[ Decision Making ]

??? Your project community is from around the world, and from all sorts of backgrounds. For example, some people commit during a dayjob; some people only have time on weekends or when the kids are asleep.

Ensuring sufficient time for most community members to comment is required for many major decisions in Apache projects. Note: not needed on every change, just significant code changes, releases, or the like.

template: logorb


  • Because we don’t have any - besides those we agree on together

  • Because our deadlines are “earliest date” something can happen

.footnote[ Decision Making ]

??? The ASF relies on volunteers (from the Apache perspective) to do our work. Therefore in project areas, we don’t have deadlines, other than ones the project defines as a community.

If you truly follow open development, you need to allow for input from the rest of the community. This isn’t to say a few developers can’t make progress and even cut a release - but the community may still come along later to make changes.

One exception: security fixes, which must be done responsibly and quickly.

template: treeright name: communication


.footnote[ Take a different way? | Continue On: Communication ]

template: logorb

Avoid Poisonous People

  • Don’t be a jerk

How Open Source Projects Survive Poisonous People

.footnote[ Communication ]

??? You can’t overemphasize this message!

We all come from different backgrounds, and email loses all the social hints at behavior that we are used to in real life. Assume the best of people, and when upset more than ever, write your email but don’t send it. Give it time. Unless it’s a security issue or a release vote, the community can take the time to defuse poor behavior.

template: logorb

Code Of Conduct

  • Don’t allow poisonous behavior to go unaddressed

ASF Code of Conduct

.footnote[ Communication ]

??? This is how we operate, in all Apache project and foundation spaces.

FOSS projects and foundations without a code of conduct will not attract as many contributions as ones with a healthy and friendly community.

See the recent GitHub Developer’s survey, which showed a large majority of developers - of every background - believed that encouraging diverse contributors was an important thing for projects.

template: logorb


“Core development activity must be in English.”

  • Translation software isn’t social
  • Whole community must be able to evaluate all project work
  • ASF Board provides oversight to all communities

.footnote[ Communication ]

??? At the current time, it’s only practical for the ASF to provide governance and hosting to communities that can operate their dev@ list in English.

This doesn’t mean it can’t be done - it certainly is being done in China and elsewhere - just that the ASF can’t support non-english as the primary development language.

template: fossneed name: client

Comcast - Call To Action

.footnote[ Take a different way? | Continue On: Comcast To Dos ]

??? So what can you do as an organization to improve your open source work?

template: logorb

Corporate Policies

  • Simple contribution policies for FOSS work
  • Use OSI-approved licenses (Apache or GPL)
  • Provide non-developer resources to FOSS projects

.footnote.small[ Comcast - Call To Action ]

??? Big takeaway: ensure employees aren’t blocked from working in open source - either by legal, management, or worries about IP risk.

If you bring a project to the ASF, plan ahead for branding, community, and leadership issues in the project, and expect the Incubation process.

If you have changes to an existing project, then submit them in an open and iterative fashion, and work with the existing project community.

FOSS foundations want to see your employees engaged in open source.

template: logorb

Project Planning

  • Be honest about open source vs. open development
  • Consider architecture choices in FOSS
    • Easy to understand modules
    • Functionality useful for others
    • Highly customized features: keep internal

.footnote.small[ Comcast - Call To Action ]

??? “Recognise that your project isn’t necessarily about your needs - but plan a project that is valuable to many people - and you have a much better chance of building a vibrant community.” - @VMBrasseur

Open sourcing an internal tool is easy. Attracting a community and getting the benefits of open development take work, and take some time to allow community to grow. Planning the architecture and how the staff treat users and contributors is key to attracting good contributions.

Have a policy - and make sure you task team developers to review pull requests or bug reports. Even if you don’t accept some code patch, providing feedback to the submitter goes a long way.

template: logorb

Employee Growth

  • Encourage employees to work in open source
  • Introduce InnerSource concepts across teams
  • Recognize existing FOSS contributors

.footnote.small[ Comcast - Call To Action ]

??? Top talent expects to be able to work on open soruce - whether as part of their dayjob project work, or on the side. Ensure employees are encouraged to responsibly contribute, and have a culture of submitting fixes upstream.

Ensuring the management culture is fully accepting of open source behaviors goes a long way to getting employees comfortable with it.

InnerSource is a great re-framing of The Apache Way that is valuable to get experience internally, without the license complications, and gives employees the “Ah-ha” moments about sharing maintenance costs and un-duplicating work on purely internal projects.

template: closing

Where next?

.footnote[ Take a different way? | Ask Questions? ]

template: thanks name: closingslide

The Apache Way

Wants Your Input!

These slides - and Shane’s website - are open source.

Get involved with documentation - improve the Apache Way!


name: last-page template: thanks


Thanks for your feedback!

.footnote[ By: @ShaneCurcuru | Apache v2.0 | ]

name: thankyou template: thanks

Thank You

  • Thanks to the ASF Membership and the Apache project communities for developing the Apache Way
  • Slides written in remark.js (MIT)
  • Background images from Unsplash (CC0)

.footnote[ By: @ShaneCurcuru | Apache v2.0 | ]