This is the second in a series of essays describing Apache governance. 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.
Apache projects are managed by Project Management Committees (PMCs), comprised of committers elected within a specific 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 committers, and PMC members cast votes on electing new committers to the project. PMC members also have binding votes on any project matters.
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 or existing members resign, the chair of a project requests an “ACK” from the board. Once one director ACK’s email is sent recognizing the change in the PMC membership, and after a 72 hour wait, the PMC chair may update the official roster of the members of that PMC. The ACK process is designed to ensure that all PMC changes are explicitly acknowledged by the board, and the waiting period ensures that all directors have a chance to object or comment on any improper changes. Changes in PMC chairs are only made by board resolution at monthly meetings, since this involves appointment of an officer of the ASF.
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 ensures that any legal liability for the products of Apache projects is born 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 voting in 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 ACK’d by the board before they are officially added to the PMC.
Merit within one PMC is not transferable to other PMCs; each project’s committer list is independently managed by it’s 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.
While only PMC members have binding votes on project releases, in general PMC members participate equally with their project committers 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 it’s mailing lists.
While there are many projects with overlapping communities – and therefore some shared personal or technical relationships – fundamentally each project is it’s 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 it’s projects or activities; every PMC is free to manage it’s 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 it’s 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.
One of the most important pieces of advice I’d personally give to PMC members is to feel a sense of leadership and responsibility for their projects as independent projects. Apache relies on it’s PMC members to ensure that their projects are managed in an open and fair manner, and that their projects act to serve the public interest by providing free software under the Apache License. In many ways, PMC membership is a duty to the project as a whole, and a call to set aside outside influence to act for the best interests of the project’s active community itself.
- Project Management Committee Guide – how-to of PMC duties
- PMC Branding Responsibilities – ensuring their projects follow Apache Branding Requirements
- Podling Project Management Committee Guide – expectations for Incbator podlings’ governance
- Brief overview of what a PMC is from the How It Works
- Apache Projects are Independent