Community over Code is a frequent saying that exemplifies Apache projects. A healthy Community uses Openness and Merit, expressed through Collaborative and Consensus driven work, to build lasting projects that use a Pragmatic License. While acting like a diverse community is a requirement for every Apache project, we also expect people to contribute as Individuals, and wear appropriate Hats.
The community behind a project are empowered with the technical decision-making for that project. Apache projects must follow a brief set of organizational rules, but otherwise technical and other decisions are completely up to the project and its PMC.
Some key aspects of Community are:
Collaborative
Apache projects are run collaboratively; that is, the whole of the community that has shown merit gets to decide technical direction.
Consensus
Communities working in The Apache Way strive to get consensus on major decisions. Having the community work together is one of the most important parts of the Way, as well as one of the most difficult to implement.
Diversity
Community diversity is often a key element to community health. The most important factor is a diversity of employers, for those committers who are doing some or all work on behalf of the employers. Projects that solely comprise active committers from a single project are frequently at risk of abandonment when their employer’s business cycle changes. Projects with active committers from multiple employers - or including students and hobbyists – can continue work and to draw in new contributors, even if one employer changes direction.
At the ASF, diversity of employers is a graduation requirement for Incubating projects. Incubator Podlings must show that they can attract committers from various employers to ensure that the project and technology is likely to be useful for a wider audience.
Diversity of learning and experiences within a community is often a bonus. Committers with different backgrounds will bring new ideas and perspectives to a project, which can make for stronger and more innovative technical decisions.
Hats
Everyone within a community comes with their own background, and may perform different roles within the community: user, writer, developer, PMC member. The concept of Hats relates to the roles you may play within a community at various times.
When you’re requesting a new feature, you’re wearing your user Hat. When checking in code to fix a bug, you’re wearing your Committer Hat. Votes on project releases are made while wearing your PMC member hat. While the difference is sometimes subtle, in a perfect world it’s an important lens to consider your actions through.
For example, as a user you might want your new feature shipped as soon as possible, because your organization needs to deploy it. When properly applying The Apache Way, however, as a PMC member you probably shouldn’t propose a release vote until the project as a whole is tested and stabilizes its API. Good community members often realize this distinction, and are happy to simply pull a changeset locally to your own organization to deploy just the new feature, while continuing to work with the community on getting to the right place for the next project release.
Hats are also another aspect of your Affiliations. While we hope committers keep their Committer Hat squarely on when checking in code, we realize that everyone has their own, external reasons for participating here – whether because of your dayjob employer, because of a consulting contract, or because you are seeking the fame and fortune of being an open source contributor. (Hint: fame and fortune not guaranteed.)
Mailing Lists
Work at Apache is done on mailing lists. Nearly all of these lists are publicly archived. An old adage is: “If it didn’t happen on-list, it didn’t happen.” Ensuring that all work and especially all decisions happen on-list ensures that the entire community is able to participate.