Meritocratic project governance in action

At OSS Watch we work with projects that develop software within and for academia. When these projects use the open development approach, they have the opportunity to engage third parties with the project and receive contributions from people with an interest in the project. In order to be able to do that, the project needs a governance model that makes it clear for external parties how to engage with the project. An example of how such a governance model would work in practice is the Cocoon project at the Apache Software Foundation (ASF), which is a classic example of how a meritocratic governance model works in practice. In this post, I will highlight bits of a case study that Andrew Savory has written about the project. It will demonstrate how the project governance at the ASF is organised and can help you when considering a governance model for your own project.

The Apache Software Foundation and ‘the Apache Way’

The Apache Software Foundation (ASF)is a non-profit 501c(3) organisation incorporated in the USA, set up to support open collaborative software development by supplying the hardware, communication and business infrastructure. The ASF is an independent legal entity to which companies and individuals can donate resources and be assured that those resources will be used for the benefit of the public. The Apache Software Foundation provides the structure and governance to support the Apache community of open source software projects. That community is made up of nearly 100 top level projects that cover a wide range of technologies.

All Apache projects follow what has become known as ‘the Apache way’ in that they follow the guiding principles behind the Apache Foundation and its community of developers and users:

  • collaborative software development
  • commercially-friendly standard licence
  • consistently high quality software
  • respectful, honest, technical-based interaction
  • faithful implementation of standards
  • security as a mandatory feature

The illustration below shows the layout of the Apache Software Foundation and the projects within it. The Board of Directors is responsible for maintaining the business affairs and legal oversight of all parts of the Foundation subject to a set of byelaws. Reporting to the Board is a Project Management Committee (PMC) for each of the projects within the foundation. The PMCs are established by the board to be responsible for the management of one or more communities. They provide oversight, ensure legal issues are addressed and procedures are followed, and are also responsible for the long-term health and development of the community as a whole. The PMC’s responsibilities do not include coding, although they do play a crucial role in approving all software releases. The PMC has a chair, but this is for legal and bureaucratic reasons only—the emphasis is always on a community of peers. Each PMC has the freedom to set up their own byelaws to arrange matters such as the election of the chair.

Within the ASF the emphasis is very much on individual contribution rather than the contribution of companies (or people working on behalf of companies). No developer is directly paid by the ASF for the work they do on projects although developers may be, and often are, paid by their own employers to work on the project. The roles that an individual may play within a project and within the ASF as a whole are very clearly defined, and this helps individuals to understand how, when and where they can make a contribution.

Each project community revolves around a code base, and operates as a meritocracy—literally, governed by merit. When an individual working within the community is felt to have earned their place in the community, they are granted direct access to the code repository, thus increasing the group and increasing the ability of the group to develop the code. The roles defined within the meritocracy are shown below and are as follows:

  • User: someone that makes use of ASF software. They may be a passive user (simply downloading and working with the software) or an active user (providing feedback via suggestions or bug reports), and they can participate in the community by helping other users via the mailing lists.
  • Developer: a user who contributes to the project in the form of code or documentation. They actively contribute on the developer mailing list, provide fixes, suggestions and criticism. Developers are also known as contributors.
  • Committer: a committer is a developer who has been recognised by the community and given write access (the ability to make updates to a project’s code) to the code repository, and who is also able to make short-term decisions for the project.
  • PMC member: a developer or committer elected due to their contribution to the evolution of the project and their demonstrated commitment. They have the right to vote on community-related issues and to propose other developers for committership.
  • ASF member: similar to a PMC member, the ASF member is nominated for commitment and contributions to the ASF as a whole and membership is by invitation only. They participate across several projects, and have the right to elect the ASF board.

There are two ways for decisions to be made within the community. Because the committers have already been recognised as responsible developers by their peers, mutual trust and peer pressure are in place to ensure committers act responsibly and know when it is appropriate to make decisions themselves and when to call a vote.

Minor decisions are usually made on the assumption that ‘code talks’, i.e. developing and committing the code to prove a concept or provide a solution is often more effective than endless discussions. For changes that are a bit more drastic, many ASF projects use the tag [PROPOSAL] in an email to suggest a certain direction. If nobody objects in this email thread, the person proposing the change is entitled to go ahead in the proposed direction. This is known as lazy consensus and it has proven to be a powerful mechanism to keep things moving within the community.

For more important decisions, such as architectural changes or major new features, votes are required. Voting is carried out by voting, that is, a discussion is started on the project mailing list titled [VOTE], and is left for at least 48 or 72 hours (depending on the project’s byelaws) before the initiator sums up. A lack of response is assumed to be tacit agreement. The period is designed to take into account the distributed nature of development, and to allow developers in different time zones to play equal roles.

Votes are cast by either providing a +1 (in favour of the proposal), a 0 (no opinion) or a -1 (against the proposal). Any negative votes must be accompanied with full explanations, to reduce friction within the community and to stimulate discussion of better solutions.

Anyone can vote, though only committer votes count. Non-committer votes are considered ‘non-binding’, i.e. recommendations or expressions of preference that help the committers decide what is best for the community.


The key to the Apache Software Foundation’s sustainability model, and to the projects underneath the ASF umbrella, is the emphasis on reducing ‘conservative’ resources (e.g. money, energy, time) whilst emphasising non-conservative resources (e.g. fun, respect, friendship, visibility).

Sustainability is achieved by removing some of the traditional constraints on the lifetime of a project (the conservative resources), and focusing on attributes that have proved to be good for long-term project viability. The good health of the community is guaranteed by providing a neutral environment for developers to interact as peers. This has been seen to work in many ASF projects.

When academic software development projects consider their sustainability, joining a foundation such as the ASF can be a viable option. If there is sufficient interest in the software, the ASF has a separate project called the Incubator which deals with these new projects. The Wookie project is an example of software developed in an academic setting that has joined the Incubator. If you are considering the sustainability of your project, feel free to contact us.

1 thought on “Meritocratic project governance in action

  1. Pingback: Governance of your open source project matters at OSS Watch team blog

Comments are closed.