Openness

What it means

The concept of doing as much work as possible in public is fundamental to The Apache Way. For a community to best work and grow, it's technical work must happen in the open.

• Open communication promotes community growth. Having existing and past technical discussions and decisions available in the mailing list archives makes it easier for new users to understand the project and the choices the community made to get where it is today.
• Open communication ensures community health. Having every email you write to the project lists be published may be unnerving to some at first, but it's crucial to ensure that the whole community can contribute to the work. This also ensures that community members in different regions, or who work on different schedules, can still participate.
• Face to face meetings must have results published and voted on. While in-person meetings or telephone conferences are sometimes held to increase collaboration, the results of any meetings must be published to the project mail lists. Any decisions made off-list must be ratified by a vote or lazy consensus on the public lists to be valid.
• Open work ensures everyone can participate. Having all of the technical discussions, consensus building, and code and documentation work happen in the open ensures that everyone can participate and everyone – contributors and just lurkers alike – can learn from the process and understand where the project is going.
• Open work ensures our projects remain neutral. A healthy community has some diversity, and ensuring that all work on the project happens in the open means that no one set of contributors or no corporation or other organization can command the project or use it solely for their own ends. Everyone can see what the project is doing and who is advocating what within the project.
• Open communication allows for oversight. Within the ASF, there are a few core values that we expect all our projects to follow. Having the project's work happen in the open ensures that the board and the PMC can review what's happening to ensure the core values are accepted and followed.
• Open status ensures that everyone can know what's going on. New users don't need to know who to ask to learn about the project: everything is on the mailing list, the archives, the website.
• Open lists promote open reputations. Merit within a community is gained through open work within that community. While each community has it's own standards for levels of merit (i.e. at what point an individual may be voted in as a committer), open lists mean that all of a person's work on other communities is also visible.

Merit

What it means

Merit accrues to Individuals through their visible and productive work within a community. To put it another way, merit is the invisible currency that you gain by contributing useful work to the project. There are a number of common aspects to merit as it's recognized within The Apache Way, the most important one is it's recognition by the community. You don't gain merit by simply doing a lot of work; you gain merit by doing things the community values.

• Merit is measured by the community. In a general way, it's the community's perception of your value to the project. Different communities have different measurements of value, both in terms of what's important to do, how it's important to act, and in particular where the bar is to get recognized.
• Merit can and cannot be measured. The concept of merit - or useful work - within technical communities does allow for some measurements. The code you contribute compiles, or it does not; it meets the spec, or it fails the tests; it performs a function that the community values, or it does something silly. This technical aspect is a key difference to the term 'merit' as it's used in The Apache Way than it often is used in other social or political areas.
• Merit accrues to individuals. It doesn't matter who you work for, or why you're contributing. The merit accrues to you as a person, regardless of the Hats you may wear.
• Merit is not transitive. Your co-workers contributing to the same community do not share in your merit. Your company is not necessarily recognized for either the number of projects contributed to nor the number of developers assigned to work on projects.
• Merit is not transferable. The merit gained in one community is not necessarily valued in another community. Web Services experts should not expect to immediately gain a vote in the SpamAssassin community. Likewise, the bar for significant recognition varies significantly between different communties.
• Merit does not expire. It may get dusty if you stop participation for a while, but you still typically keep your recognition within the community if you come back later.
• Merit can be lost through harmful actions within the community, and in some cases through harmful or distrustful actions elsewhere.
• Merit is not just for code. Most communities value documentation, website, infrastructure, and mailing list help as well as code or bug report contributions.

The most obvious reward for your merit is being voted in to be a committer within a specific community. The merit level to become a committer varies from community to community; it can span anything from a handful of useful patches and helpful questions on a mailing list, to several months of sustained hard work on the code, mailing lists, or website.

How ASF Projects Recognize Merit

Within the ASF, most projects have fairly similar processes for actually recognizing merit. The specific processes are specific to the ASF, but in many cases are echoed in other open source projects as well.

Committers have write access to their project's code repository. This means they may directly contribute to the project's code, website, and other materials. Committers who continue to show merit may be recognized by voting them onto the Project Management Committee (PMC). PMC members have binding votes on the strategic direction of the project, and on making formal releases. One PMC member is typically voted in by the community to become the chair of the PMC, and with that comes the role of Vice President of that particular project.

Note that within the ASF, voting in committers is done solely by each project's PMC individually; they act independently in this respect. When voting individuals onto the PMC itself, the Board of Directors of the ASF exercises oversight, and approves all PMC changes by a simple 'ACK' email. The Board also specifically passes resolutions at monthly meetings to appoint, remove, or change Vice Presidents of Apache projects.

Welcome to The Apache Way!

The Apache Way is sort of like Zen. It's something that's difficult to explain, has many interpretations, and the best way to learn it is to do it.

This is devoted to one interpretation of The Apache Way – the one that I've learned over the years of participating at The Apache Software Foundation. Many of the communities at the ASF believe that some form of The Apache Way is a great way to collaboratively develop software, and many individuals at the ASF exemplify the values of The Apache Way.

In one sentence – but wait, let's be serious: how could you describe even part of Zen in one sentence? The Apache Way is primarily about Community, Merit, and Openness, backed up by Pragmatism and Charity. The ASF as a whole promotes the use of The Apache Way within it's projects; indeed some of these concepts are required of it's projects. Many other organizations and especially open source groups have adopted or modified many of these same concepts.

Community

Many of us are more effective than one of us.

Community over Code is a frequent saying that exemplifies ASF projects. Community uses Openness and Merit, expressed through Collaborative and Consensus driven work, to build lasting projects that use a Pragmatic License. While a diverse community is a requirement for every ASF project, we also expect people to contribute as Individuals, and wear appropriate Hats.

Merit

Those that have proven they can do, get to do.

Merit defines who is allowed to participate at various levels within a project community. Users help a project over time, and existing Committers Vote to invite the user to become a committer. Committers are allowed write access to the project's source code, allowing them to imrpove the project. Strong communities rely on Openness in their work, usually on public Mailing Lists, to be able to recognize merit. Merit accurues to individuals regardless of affiliations, and typically does not expire.

Openness

Technical decisions are made publicly.

Strong communities can best function when work is done openly. All ASF projects use Mailing Lists as their primary means of working and communicating. Code is always publicly available, and Votes about all aspects of project direction are performed publicly, over a specific period of time – allowing contributors worldwide time to participate. Individuals participating in healthy communities make their affiliations public, and ensure that they are wearing an ASF contributor's hat when they are participating in the community. Releases of software products are voted upon publicly, and our code and decisions are always available for review. Openness allows new users the opportunity to learn. Every non-public mailing list at the ASF must have a specific reason to be kept private.

Pragmatism

All ASF projects use the Apache License.

The mission of the ASF is to provide software for the public good. We use the Apache License to do this, which ensures that users of our software have the freedom to use our software however they see fit – even in proprietary products. Our steadfast belief in freedom for our users both serves our public purpose, as well as ensures that users from all areas are able to - and often desire to - contribute back to our communities. Our pragmatic license allows contributors from individuals to corporate teams to join together, secure in the knowledge that their product is freely usable by all.

Charity

The ASF's core mission is providing software for the public good.

The original Certificate of Incorporation ensures that the ASF operates as a public charity. The most important action the ASF does is providing useful software products to the world, for free. Many parts of the The Apache Way are a happy coincidence of altruism and selfishness. Many contributors believe in our service to the public, and contribute from a belief that we can make the world a better place. They work side by side with contributors who are simply “scratching their own itch”: people who simply want to fix their own problems, but who find it's often easier to do that in concert with others as it is to do alone.

Welcome to The Apache Way!

This feed will be an insight into The Apache Way, as told by Shane Curcuru. There are a lot of folks practicing their own versions of what we call "The Apache Way", and a few sites with some of the key ideas written down. But I liked the name so much that I decided to organize some of the best concepts about the Way that I saw in practice, and write them up in a more permanent format.

This, then is my particular version of the Way: useful practices for community-driven open source projects. I hope you enjoy it.

The edges are still being edited, but I did want to get this up in time for ApacheCon US 2009, coming soon to Oakland. We'll be celebrating the 10th anniversary of the Apache Software Foundation there, and hope you can join us there - and if not, then raise your glass to Apache!