There’s a huge amount of volunteer energy that flows around Apache’s Annual Member Meeting every year. Old members and new alike come together and brainstorm all sorts of new ideas, both organizational and technical – and we have plenty of online… discussions, let us say. There is an amazing amount of energy from a lot of very smart people, and when we focus this energy, we make real improvements to the Foundation and sometimes in some of our projects.
As we’ve grown, keeping a full shared understanding of all the details of membership and corporate operations has become much harder. We have some documentation, but we also still have a lot of tribal knowledge and decisions hidden in our mailing list archives. To understand the same things, we need to be able to see what rules or policies we’ve actually decided on – or at least written down.
So here is an overview of all the different roles that people can have with the ASF as either a Foundation or with specific Apache projects. In particular, I’m focusing on the specific agreements we make with individuals, or the explicitly posted policies that we expect people to abide by. For more information on how Apache works, see /dev, /governance, and Community.
Users – Indirect
Given the amount of software that includes code from an Apache project within them, I’d say that the majority of computer-using people in the world today qualify as indirect users of Apache software.
Indirect users often don’t even realize they are using Apache software, since they downloaded or installed software from some other company. For example, virtually every Java environment anywhere includes Apache Xerces and Xalan among other bits. While indirect users may not realize it, they are still subject to the terms of the Apache license in that underlying software – along with whatever (often commercial) license they purchased or downloaded the overall software with.
Given that the Apache License puts virtually no restrictions on using the software, indirect users have essentially no direct connection with the ASF.
Users – Direct
Direct users download Apache software knowingly, typically from apache.org/dist directly. In this case, the legal requirements should be obvious to the user, because our overall history and project websites as well as source releases have ample notice that the Apache License applies to our software.
These users need to ensure they follow the license, but otherwise there is no relationship with the ASF: no-one need tell us how they use our software, nor do we ask.
While many projects have welcoming information for users, the Community Development project is another place where we try to welcome all newcomers to using or contributing at Apache.
Many companies download Apache software, repackage it as part/all of their own branded software product, and then redistribute that to the public. They are bound by the Apache License, which does have a very few requirements for redistributors; namely propagating LICENSE, NOTICE, and the like.
Other than the License, the ASF asks nothing nor expects anything of redistributors. They are legally allowed to ship their overall code under a different license, and may charge for their software, all without ever informing the ASF of that. Nor, as a public charity, does the ASF really expect such.
Mailing List Or Website Participants
When someone participates on our mailing lists or websites (JIRA, wiki, etc.), there are two corporate policies we expect them to abide by: our Code of Conduct for their behavior, as well as the Apache License in the case of IP rights. Section 5 of the Apache License attempts to address the second point, in that “Contribution(s) intentionally submitted” are meant to be under the Apache license as well.
It may not always be obvious to people who simply send mail to an email address (for example, that they found in some forum as the way to get help) that they are bound by these policies, but hopefully our clear posting of the license as well as our active communities who answer questions ensures it’s understood.
Mailing list submissions are also subject to our mailing list archiving policies. This is an often unknown policy, as is evidenced by regular requests from users to remove emails from our archives, which is virtually always denied.
With other tools, the relationship should be clear to the user: JIRA and wikis require logins to be able to submit information, so the user is knowingly and explicitly agreeing to something before they submit.
Patch Contributors (code, docs, etc.)
Users who submit code, docs, tests, or other useful information for inclusion in Apache software or websites are contributors. Normally, contributors would be well aware of the above policies of CoC and Apache License. Depending on how users contribute code, we sometimes ask them explicitly to confirm their intent; this is in addition to section 5 of the license.
Again, for contributors, the ASF does not ask for anything besides following the license and CoC. We are happy to accept contributions, but don’t expect anything in addition. In addition, by long-standing policy, we also ask that our projects only accept voluntary contributions.
The apache.org/dev pages have a basic “How to Contribute” guide, and some projects have their own very detailed guides for contributing.
Becoming a committer is the first time that the ASF has a specifically documented relationship with someone. Once an individual shows merit within a project, and is voted as a committer by the PMC, they must sign the Individual Contributor License Agreement. This legal agreement requires a signature, and clearly defines that their contributions to the ASF are made under the terms of the Apache license. The ICLA does not mention the Code of Conduct, however PMCs are expected to enforce the Code of Conduct in any case for all regular participants.
The PMC inviting the committer should then send a welcome packet, and we have many ASF-wide committer resources available. Along with then being able to write to their project’s software and websites, committers generally can vote or comment on issues and other code submissions within that project.
PMC members are recommended by a vote of their PMC, and ratified (or appointed, for new projects) by the board. Documented PMC policy outlines various responsibilities for PMC members. The definition of a PMC is in the ASF bylaws, making PMCs official committees of the corporation. Thus when software releases are made and voted on, it is the PMC as a whole – and as a body of the corporation – that is legally approving and posting the release. PMC members may also nominate and vote on new committers or PMC members within their own project.
While many projects have good welcome notes to new PMC members, we don’t necessarily have a great “welcome to your new role” starter documentation beyond apache.org/dev. Some projects also define their own project participation bylaws which PMC members are expected to follow and help ensure.
PMC Members (Emeritus)
Projects sometimes want to continue to recognize the past merit of an individual, while recognizing that they are not currently actively contributing or voting. These PMCs then ask to move these members to “emeritus” – which is not a status the ASF officially recognizes. Since PMCs are defined in the bylaws, individuals are either on a PMC (because the board appointed/ratified them) or not (because they resigned or the board removed them).
Emeritus PMC members are not on that PMC. Many PMCs however define a simplified way that emeritus members can request to re-join the PMC, which happens when the board ratifies the addition. PMCs may allow their emeritus members to remain on their private@ mailing list, but emeritus members do not have any voting rights.
The specific process for adding PMC members was updated by board resolution.
VPs of Apache Projects (also are Project Chairs)
The bylaws specify that the Chair of any PMC is also an officer (Vice President) of the corporation. Therefore changing project VPs is always done by board resolution. The Secretary has a welcome note for new project VPs. While in most project operations the ASF expects that the VP acts as an equal with the rest of the PMC, they are still legally an officer responsible for that project, and in limited cases may sign documents on behalf of their project.
While the board and experienced PMCs provide plenty of oversight (via board reports and elsewhere) of project VPs, overall we do not have a really detailed “Welcome to being an officer, here’s what it means” document yet.
Project VPs most important duty is providing their quarterly report to the board, and ensuring their PMC responds to any board feedback. Project VPs are expected to subscribe to the privately-archived board@ mailing list to do so.
VPs of Apache Policy or Operations
The board delegates operations and specific policy areas to a number of corporate level VPs, which is always done in board resolutions. These officers have specific authority to sign documents, enact policy, or manage operations for the ASF as a whole, including Apache projects.
While we do not have a specific “Welcome to being a VP” document, as a consensus-driven organization, the board only appoints individuals to these positions where it’s clear the person understands the role. While a project VP may be appointed merely because they were the lead organizer with an incoming podling, corporate VPs have been long-standing Members with deep experience in their areas already.
While specific VPs set ASF-wide policy, Apache projects report directly to the board. Only the board can change the makeup of a PMC or otherwise enforce oversight. Most Corporate VPs report monthly to the President in terms of being in charge of day-to-day operations. The President then rolls up reports monthly to the board.
The bylaws specify the same executive officers as any other corporation: Chairman, President, Secretary, Treasurer, and assistants. The board typically appoints executive officers annually, after a board election. As with corporate VPs, individuals appointed here are either already Directors sitting on the board, or are Members with extensive experience with these roles already.
As executive officers, they legally have broad powers in operations and signing documents on behalf of their area of the corporation. In particular, the board has delegated day to day operations to the President (and VP, Infrastructure), which over the past few years has led to a much more efficient organization of paid staff, alongside the traditionally large group of Member volunteers that help with corporate operations.
As with corporate VPs, “operations” here mean ASF-wide operations in support of projects. Each project PMC manages their own day-to-day operations independently, reporting directly to the board.
Nine directors are elected to the board at each annual Member’s meeting. The Membership is allowed to nominate anyone to stand, although historically only Members have been nominated. Every Member of the corporation gets one vote, although we use a Single Transferable Vote process to conduct the election.
Directors have the legal powers as they would in any corporation. However our consensus-driven history and style means that formal board decisions are typically unanimous; if there is any significant concern with an action, it is usually tabled. In particular, board members are often personally involved in mentoring and working with PMCs, members, and our communities to help them operate better.
The ASF is a Delaware Membership corporation; Membership is like being a corporate shareholder in that you get a vote for the board. But ASF cannot issue stock, Memberships cannot be traded, and only individuals are elected as members.
Existing Members can nominate any individual for membership; nominees are voted on by the entire membership at an Annual Meeting. If a nominee is elected and accepts, they must sign and submit a Membership Application, whereby they explicitly agree to uphold the bylaws. A new member welcome is provided with links to member-only resources and reminders to keep private@ communications confidential.
By policy, Members have the right to inspect virtually all corporate records and proceedings, including subscribing to PMC private@ lists. This inspection right helps Members to provide oversight to the ASF; however it does not translate into merit. Members have no particular commit or voting rights on any projects unless they are otherwise voted into that project’s committer list. The one exception is the Apache Incubator project; any Member may be added to the Incubator PMC by simply requesting it (no vote is needed). This is because Members are typically helping to mentor new podlings hoping to become Apache projects.
The reality of ASF Membership is often different from what people expect. There is no “special power” that Members get, other than voting for the board and new members. The outside perception of Membership often greatly overstates what members can do. However the merit required to be recognized with a nomination is significant, and that tends to mean that members are often listened to, because of their broader experience with FOSS and communities.
The bylaws define an emeritus status for members, wherein the ASF recognizes their past work, but they are no longer legally members nor allowed to vote on board or member nominees. Many members choose to go emeritus when they realize that they’re not actively participating in members meetings anymore. In a few cases, the membership has involuntarily moved non-participating members to emeritus, primarily to ensure that future membership meetings can reach quorum requirements in a timely manner.
By board policy, emeritus members are still allowed oversight of operations, including reading private lists, and are still prominently listed on our membership rolls. Many emeritus members continue to work in various projects as well. Reinstatement from emeritus requires a new membership vote.
Many businesses and individuals send monetary donations to the ASF, which are very much appreciated. Beyond accepting the donation, and providing any required receipts, there is no other specific relationship between the donor and the ASF. In particular, our policy and history make it exceptionally clear that donations come with no strings attached, and donations in no way give benefits to the donor in terms of influence or ability at Apache.
Some businesses – and individuals – choose to make annual donations of a specific amount in exchange for being listed in our formal Sponsorship program. This is typically memorialized in invoices or purchase orders, and is formally recognized by a defined placement of the Sponsor’s logo or name on our page. At higher Sponsorship levels, the ASF may also provide quotes for a formal press release by the Sponsor.
Otherwise, Sponsors have no other specific influence, nor does the ASF generally accept Sponsorships with strings attached. While the ASF may be experimenting with limited directed donations going forward, in all cases we evaluate the true needs of the Foundation and our projects first, not the wishes of any potential (or existing) donors.
Corrections and Improvements Welcome!
Please comment if you have corrections or suggestions for improvement. Alternately, suggestions or patches to the official /governance website at Apache are a great idea too. In particular I’m curious how well understood the nuances of Apache operations are.