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 improve the project. Strong communities rely on Openness in their work, usually on public Mailing Lists, to be able to recognize merit. Merit accrues to individuals regardless of affiliations, and typically does not expire.

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 its 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 About Your Work, Not You

The concept of Merit within the Apache Way is often misunderstood, both on it’s merits and in particular with the specific meanings of the word within our communities. Within the Apache Way, “your merit” is always about the work you do, and never about you as an individual. Many newcomers see this at odds with common conceptions of someone’s merit meaning their character, their behaviors, their abilities, and past actions.

Since the word “merit” itself is overloaded with several meanings, here’s a more explicit phrase to try on instead. As a general concept, merit equals your Previously Accepted Contributions To A Project. That’s a mouthful, so let’s unpack it:

  • Previously - you typically only get elected as a committer after you have made a number of contributions to a project. Since we work in distributed and asynchronous projects, merit is about past contributions.
  • Accepted - making contributions isn’t enough. A project community needs to value the contribution enough to actually accept it to be worthwhile. It’s up to the project as a whole - independently and separately from other projects - to judge contributions and say that they’re valuable.
  • Contributions - merit is typically based on actual work done, not plans for work, ideas, or statements of something in the future. Note that answering questions on user@ mailing lists and other ways to evangelize a project can help - once you’ve actually done them.
  • To A Project - each project decides what’s valuable for that project. The merit needed to become a committer or PMC Member in different projects varies, and being a committer on one project does not translate to any other projects.

More About Merit

  • 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 communities.
  • 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.