Celebrating 20 years of community-led development "The Apache Way"
Each Project Management Committee (PMC) votes on software product releases and elects new PMC members and committers to their Apache project.
Fundamentally, the most important organization at the ASF is a PMC, or Project Management Committee. These are the actual groups that decide what software our projects release, and as such do the bulk of the actual work of the ASF.
Note that this document is intended as background or explanatory information about how - and why - organizations at the ASF work they way they do. For official policy information and for "How To" style guides, please see the documents under References or in apache.org/dev.
Apache projects are managed by Project Management Committees (PMCs), comprised of committers elected within a specific Apache project community to provide oversight for the project for the ASF and to decide the release strategy for the project. PMC members are expected to act as individuals, making decisions for the best interest of the project when acting on PMC or development lists.
Each project's PMC is independent. PMCs are free to set community and technical direction for their project, and are directly responsible for overseeing releases and the healthy development of their communities. PMCs are responsible for ensuring their project follows certain core requirements set by the board or other corporate officers of the ASF, like following Legal, Branding, and Infrastructure related requirements, along with ensuring their community operates within the basic outline of the Apache Way.
PMC members nominate new contributors to the project as either committers or as new PMC members, and PMC members cast votes on electing new committers or PMC members to the project. PMC members also have binding votes on any project matters.
PMCs must comprise at least three (3) active members. This is because the minimum number of positive votes on product releases is three +1 votes.
The board creates new PMCs to manage specific named projects by resolution at monthly meetings. New top level projects (TLPs) are created from podlings in the Apache Incubator after a successful graduation vote from Incubation. The board appoints a Vice President - an officer of the corporation - to serve as the chair of the PMC itself when creating the PMC.
PMC Chairs - who are VPs - serve as normal PMC members, with one vote on project matters just like other PMC members. The primary duty of a PMC chair is providing quarterly reports to the board about the health and status of their project. PMC chairs are expected to subscribe to the board@ mailing list, and be aware of any board concerns about the project, and are responsible for working with the PMC as a whole to address any board concerns.
When PMCs elect new potential PMC members, the chair of a project sends a NOTICE e-mail to the board. After a 72 hour wait - and assuming that the candidate accepts the offer of membership - the PMC chair may update the official roster of the members of that PMC. The process is designed to ensure that all PMC changes are explicitly notified to the board, and the waiting period ensures that all directors have a chance to object or comment on any improper changes.
For more details on the process, please read Adding a new PMC member
For people leaving the PMC, please read A PMC member wishes to be resign/go emeritus. Now what?
Changes in PMC chairs are only made by board resolution at monthly meetings, since this involves appointment of an officer of the ASF; please follow the PMC Chair Change process.
As official committees of the ASF, PMCs provide the legal oversight of project operations and releases, ensuring that software releases are made on behalf of the ASF as an organization, and not as individuals. This helps to ensure that any legal liability for the products of Apache projects is borne by the ASF and not by our committers individually. All PMC chairs provide quarterly reports to the board, which ensures that the board has oversight of all the projects of the Foundation.
PMC members should always be subscribed to their project's private@ list, and certainly should be subscribed to at least the dev@ list to be aware of the operations of the project.
Virtually all PMC communication should happen on the dev@ list or any other appropriate public mailing list. The private@ list for each PMC should only be used for matters that require confidentiality, such as discussing personnel matters or inviting new committers or PMC members, or security-related issues that have not yet been publicly disclosed. Ensuring that PMC discussions about the future of the project are held on the public dev@ list ensures that all of the community - including non-committers - can follow the discussion and comment on issues. While only PMC members or committers have binding votes on project matters, healthy PMCs certainly work with the larger community of their project.
PMCs are free to use JIRA/Bugzilla, wikis, and other infrastructure-hosted tools that provide for public view and comment, along with the normal project mailing lists. PMCs should make specific requests to the Infrastructure team for services that the project desires.
Some PMCs sponsor regular or occasional in person meetings, teleconferences, or IRC chats to brainstorm project ideas, but are expected to bring all information back to public lists for further discussion and to make final decisions. Many PMCs either directly organize, or have contributors or organizations in their technical space organize Meetups, BarCamps, or other in-person events focused on end user education and technical information sharing.
Given the distributed and volunteer nature of our projects, in-person meetings of PMCs are quite rare. All project business is conducted on normal public mailing lists.
PMCs are free to set the bar for merit within their projects, as long as decision making is done in a collaborative fashion as in the Apache Way. Healthy PMCs will regularly review contributions from non-committers - both specific code patches, bugs reported or commented on, or just helpful interaction on their project lists - to evaluate contributors as potential committers. Ensuring that PMC members are helping to mentor helpful new contributors to their projects helps to ensure a healthy and growing project community.
PMCs vary significantly in the level of commitment and work expected to be considered for a committership. Some PMCs vote in new PMC members typically from their existing committers (i.e. the progression is contributor -> vote -> committer -> vote -> PMC), while other PMCs always elect new committers into the PMC simultaneously (contributor -> vote -> committer & PMC member). PMCs are solely responsible for managing votes and granting commit privileges for new committers; however new PMC members elected must always be recognised by the board before they are officially added to the PMC (as described in the Legal section above).
Merit within one PMC is not transferable to other PMCs; each project's committer list is independently managed by its own PMC. PMC members or committers with a long history on one project will often be known by their past activities by other project's PMC members, but they are expected to build merit on each separate project they wish to become a committer on. There are many PMCs who work closely with other PMCs, and have correspondingly-large intersection in personnel; but the merit on each PMC is independent.
Although the plain sense of the word "committer" is "someone who can create new revisions in the source repository", the notion of committership is a social one—someone is a committer if they have been invited by the PMC to be a committer, and accepted the invitation.
While only PMC members have binding votes on project releases, in general PMC members participate equally with their project committers and contributors on the dev@ list. PMC members can help to ensure a healthy and diverse project community by ensuring the project's mailing lists are welcoming to newcomers and that community standards are promoted on its mailing lists.
While there are many projects with overlapping communities - and therefore some shared personal or technical relationships - fundamentally each project is its own community in terms of the bulk of project work. While all projects are part of the overall ASF, and as such share certain basic requirements and bits of the Apache Way, all technical direction and most of the community focus is within each project individually.
PMCs are expected to report on the health and diversity of their project's community to the board. While there are no strict requirements on the makeup of PMC members (in terms of employment or affiliation of the individuals on the PMC), the board does expect PMCs to operate independently of outside commercial influence. PMCs that are unable or unwilling to ensure their actions are on behalf of the whole community - or act in ways targeted to specific commercial interests - will be contacted by the board and required to make corrections.
The board does not provide technical direction for any of its projects or activities; every PMC is free to manage its technical direction independently. PMCs are the governing body for their project, and are expected to manage the project's technology in the best interest of the whole project community, independent of outside commercial influence.
While this may be a surprise to some, it is a key reflection of how the ASF is intentionally structured to provide maximum freedom to its projects. The board and the ASF are happy to provide a home to any software project communities that are willing to follow the Apache Way. The mission of the ASF is to provide software for the common good: we are happy to help like-minded communities to provide that software; are confident that communities will form around software that is useful; and understand that there are many different ways to effectively and collaboratively build software.