How the ASF works (2024)

This page provides an overview of everything you always wanted to know about theApache Software Foundation but were afraid to ask: the difference between membership andcommittership, who decides what, how elections take place, how ourinfrastructure is set up, what the board is and does, what a PMC is, what's thephilosophy behind the incubator, and how the ASF deals withthe incredible growth in new projects and contributors over the years. Come and see behind the scenes of the ASF.

• What is the Apache Software Foundation?

• Meritocracy

• The Foundation structure

• Roles

• Project management and collaboration

• The Foundation Infrastructure

• The Foundation Incubator

• Other Foundation entities

• Conclusions

What is the Apache Software Foundation?¶

The Apache Software Foundation (ASF) is a 501(c)3 non-profit public charity organizationincorporated in the United States of America. It was formed in 1999 primarily to:

• provide a foundation for open, collaborative software developmentprojects by supplying hardware, communication, and business infrastructure

• create an independent legal entity to which companies and individuals candonate resources and be assured that those resources will be used for thepublic benefit

• provide a means for individual volunteers to be sheltered from legalsuits directed at the Foundation's projects

• protect the 'Apache' brand, as applied to its software products, frombeing abused by other organizations

That's the dry facts, but how did all this come to be and what does itreally mean? We need to step back a little in history.

Meritocracy¶

Unlike other software development efforts under an open sourcelicense, like the Linux Kernel or the Perl/Python languages, no single developer initiated the Apache Web Server. A diverse group of people who shared common interests developed the project as they exchanged information, software fixes and suggestions.

As the group started to develop their own version of the software, movingaway from the NCSA version, more people were attracted and started to helpout, first by sending little patches, or suggestions, or replying to emailon the mail list, later with more important contributions.

When the group felt that a person had "earned" the merit to be part ofthe development community, they granted direct access to the coderepository, thus growing the group and increasing its ability to develop the program, and to maintain and develop the software moreeffectively.

We call this basic principle "meritocracy": government by merit.

The process scaled very well withoutcreating friction because, unlike in other situations where power is ascarce and conservative resource, in the Apache group newcomers were seenas volunteers who wanted to help rather than people who wanted to steala position.

With no limited and therefore valuable resource (money, energy, time) at stake, the groupwas happy to have new people come in and help. They only filtered those who expressed interest to find and include those whom they believed were committed enough for the task and matched thehuman attitudes required to work well with others, especially when there weredisagreements.

After explaining the structure of the ASF, we will see how the meritocracyrelates to the various roles.

The Foundation structure¶

As the Apache Web Server started to grow in market share and popularity,due to synergy of its technical merit and to the openness of the communitybehind the project, people started to create satellite projects. Influencedby the spirit of the community they were used to, they adopted the sametraditions of community management.

By the time the ASF came into existence, there were several separatecommunities, each focused on a different side of the "web serving" problem,but all united by a common set of goals and a respected set of culturaltraditions of both etiquette and process.

These separate communities were referred to as "projects" and, whilesimilar, each of them exhibited little differences that made them special.

To reduce friction and allow diversity to emerge, rather thanforcing a monoculture from the top, the ASF designates the projects as the centraldecision-making organizations of the Apache world. Each project has authority over development of its software, and has a greatdeal of latitude in designing its own technical charter and its owngoverning rules.

At the same time, the cultural influence of the original Apache group isstrong and the similarities between the various communities are evident, aswe'll see later.

The following entities govern the foundation:

• Board of Directors (board) governs the foundation and is composed ofmembers.

• Project Management Committees (PMCs) govern the projects, and they arecomposed of committers. (Note that every PMC member is, by definition, also acommitter.)

• Various Officers of the corporation, appointed by the board, who setFoundation-wide policies in specific areas (legal, brand, fundraising, etc.)

For all the details, read our Governance overview.

Board of Directors (board)¶

The board is responsible for management and oversight of the business andaffairs of the corporation in accordance with the foundationBylaws. This includes management of the corporate assets(funds, intellectual property, trademarks, and support equipment) andallocation of corporate resources to projects.

However, each Apache project's PMC has technical decision-making authority regarding the content anddirection of the project.

The board is currently composed of nine individuals, elected by and from themembers of the foundation. The bylaws don't specify the number of board membersthat the foundation should have, but this was the number of thefirst board and it has never changed. The board is elected every year.

The board website has more information, the list of the currentdirectors, a schedule of meetings, and minutes of past meetings.

Project Management Committees (PMC)¶

The Board establishes Project Management Committees (PMCs) to be responsible for the active management of one or more specificcommunities.

Each PMC includes at least one officer of the ASF, who shall bedesignated its chair, and may include one or more other members of theASF.

The Board appoints the chair of the PMC, who also becomes an officer (Vice President) of the ASF. The chair has primary responsibility to the Board, andhas the power to establish rules and procedures for the day to daymanagement of the communities for which the PMC is responsible, includingthe composition of the PMC itself. See further discussion about the role of thePMC chair and why chairs areofficers.

The ASF Bylaws (section 6.3) define a PMC and the positionof chair. Some emails help to clarify:here andhere.

The role of the PMC from a Foundation perspective is oversight. The mainrole of the PMC is not code and not coding, but to ensure that its community addresses all legalissues and follows stated procedures, and that each and everyrelease is the product of the community as a whole. That is key to ourlitigation-protection mechanisms.

The second role of the PMC is to further the long-term development andhealth of the community as a whole, and to ensure that balanced and widescale peer review and collaboration takes place. Within the ASF we worryabout any community which centers around a few individuals who are workingvirtually without review. We believe that this is detrimental to quality,stability, and robustness of both code and long-term social structures.

We firmly believe in hats. Your role at the ASF is one assigned toyou personally, and is bestowed on you by your peers. It is not tied toyour job or current employer or company.

However those on the PMC are held to a higher standard. The PMC, and thechair in particular, are eyes and ears of the ASF Board, so we rely on and need to trust you to provide legal oversight.

The board can to terminate a PMC at any time by resolution.

The Apache Developer Information pages have more details of how PMCs work.A complete list of all Apache projects is also available.

Officers¶

The Officers of the Apache Software Foundation oversee the day-to-dayaffairs of the Foundation. The Board ofDirectors elects these officers.

Roles¶

The meritocracy typically has various roles within each individual Apache project community:

user | developer | committer| PMC member | PMC chair | ASF member

User¶

A user is someone who uses our software. They contribute toApache projects by providing feedback to developers in the form of bugreports and feature suggestions. Users participate in the Apache communityby helping other users on mailing lists and user support forums.

Developer¶

A developer is a user who contributes to a project in the form ofcode or documentation. They take extra steps to participate in a project,are active on the developer mailing list, participate in discussions, andprovide patches, documentation, suggestions, and criticism. Developers arealso known as contributors.

Committer¶

A committer is a developer who has write access to the coderepository and has a signed Contributor License Agreement(CLA) on file. They have anapache.org mail address. Not needing to depend on other people to make patches to the code or documentation, they are actually making short-term decisions for the project. ThePMC can (even tacitly) agree and approve the changes into permanency, or they canreject them. Remember that the PMC makes the decisions, not the individualcommitters.

PMC Member¶

A PMC member is a committer who was elected due tomerit for the evolution of the project.They have write access to the code repository, an apache.org mail address,the right to vote on community-related decisions and the right topropose other active contributors for committership. The PMC as a whole is the entitythat controls the project, nobody else. In particular, the PMC must vote to approve any formal release of their project's software products.

PMC Chair¶

The Board appoints the Chair of a PMC from the PMC members. The PMC as a whole is theentity that controls and leads the project. The Chair is the interfacebetween the Board and the Project. PMC Chairs have specific duties.

ASF Member¶

An ASF member is a person who was nominated by current members andelected due to merit for the evolution and progress of the foundation.Members care for the ASF itself, usually through project-related and cross-project activities. Legally, a member isa "shareholder" of the foundation, one of the owners. They have the rightto elect the board, to stand as a candidate for board election and topropose a committer for membership. They also have the right to propose anew project for incubation (we'll see later what this means). The memberscoordinate their activities through their mailing list and through theirannual meeting. We have a full listing of Apache Members.

Project Management and collaboration¶

Apache projects are managed using a collaborative, consensus-basedprocess. We do not have a hierarchical structure; rather, different groupsof contributors have different rights and responsibilities in theorganization.

Since the appointed PMCs have the power to createtheir own self-governing rules, there is no single vision on how PMCsshould run their projects and nurture the communities they lead.

At the same time, while there are some differences, there are a number ofsimilarities all ASF projects share:

Communication¶

Communication is via mailing lists. These are "virtual meetingrooms" where conversations happen asynchronously, which is a generalrequirement for groups that are distributed across manytime zones (as is normally the case for Apachecommunities).

Some projects additionally use more synchronous messaging (for example, IRCor instant messaging). Voice communication is extremely rare, normallybecause of costs and the language barrier (speech is harder to understandthan written text).

In general, asynchronous communication is important because itallows archives to be created and it's more tolerant on the volunteernature of the various communities.

Documentation¶

Each project is responsible for its own project website.Further information to assist committers, developers, and PMCs is availableat ASF Infrastructure.

Decision Making¶

Projects are normally auto governing and driven by the people who volunteerfor the job. This is sometimes referred to as "do-ocracy" -- power of thosewho do. This functions well in most cases.

When coordination is required, projects make decisions with a lazy consensusapproach: a few positive votes with no negative vote is enough to getgoing.

Voting is by numbers:

• +1 -- a positive vote

• 0 -- abstain, have no opinion

• -1 -- a negative vote

The rules require that a PMC member registering a negative vote must include an alternative proposal ora detailed explanation of the reasons for the negative vote.

The community then tries to gather consensus on an alternative proposalthat can resolve the issue. In the great majority of cases, the concernsleading to the negative vote can be addressed.

This process is called "consensus gathering" and we consider it a veryimportant indication of a healthy community.

Specific cases have some more detailed voting rules.

Philosophy¶

While there is not an official list, people often cite these six principles, often referred to as "The Apache Way",as the core beliefs behind the foundation:

• collaborative software development

• commercial-friendly standard license

• consistently high-quality software

• respectful, honest, technical-based interaction

• faithful implementation of standards

• security as a mandatory feature

All ASF projects share these principles. Similarly, Apache projectsmust govern themselves independently of undue commercial influence.

Operation¶

All participants in ASF projects are volunteers and nobody (not even members orofficers) is paid directly by the foundation to do their job. There are manyexamples of committers who are paid to work on projects, but never bythe foundation itself. Rather, companies or institutions that usethe software and want to enhance it or maintain it provide the salary.

The ASF does contract out various services, including accounting,Press and Media relations, and infrastructure system administration.

Individuals compose the ASF¶

All of the ASF including the board, the officers, the committers, andthe members, are participating as individuals. That is one strength of theASF: personal affiliations do not cloud the person's contributions.

Unless they specifically state otherwise, whatever an ASF participant posts on any mailinglist is done as themselves. It is the individual point-of-view, wearingtheir personal hat and not as a mouthpiece for whatever company happens tobe signing their paychecks right now, and not even as a director of theASF.

All ASF participants implicitly have multiple hats, especially theBoard, the officers, and the PMC chairs. They sometimes need to talkabout a matter of policy, so to avoid appearing to be expressing a personalopinion, they will state that they are talking in their special capacity.However, most of the time this is not necessary: personal opinions workwell.

Some people declare their hats by using a special footer to their email,others enclose their statements in special quotation marks, others usetheir apache.org email address when otherwise they would use their personalone. This last method is not reliable, as many people use theirapache.org address all of the time.

Balancing confidentiality and public discussion¶

We endeavour to conduct as much discussion in public as possible. Thisencourages openness, provides a public record, and stimulates the broadercommunity.

However sometimes internal private mail lists are necessary. You must neverdivulge information from such a list in public without the express permission of thelist. Also never copy an email between private and public lists (no Cc).Such an event would go beyond the normal need for email etiquette and would be aserious breach of confidence. It could have serious ramifications, causingunnecessary confusion and ill-informed discussion.

Private lists are typically only used for matters pertaining to people asindividuals (like voting in new committers), and legal matters that requireconfidentiality.

The Foundation Infrastructure¶

The ASF does not have offices or buildings. Its only physical existence is the technical infrastructure that enables it to operate, and the staff.

The ASF Infrastructure team, known as "Infra", supports services that help the ASF and its projects function and flourish. Learn more.

The Foundation Incubator¶

To support and encourage new projects, the ASF created theIncubator to help newefforts join the foundation.

Since the meritocratic rules operate across the ASF from bottom to top, itis vital for the long-term stability of this form of government that a project'sinitial set of committers has to understand very well the dynamics of such asystem, and to share the same philosophical attitude towardcollaboration and openness that the ASF expects from its projects.

The incubator is responsible for:

• filtering proposals about the creation of a new project orsub-project

• helping create the new project and the infrastructure that it needs tooperate

• supervising and mentoring the incubated community to help it createan open, meritocratic environment

• evaluating the maturity of the incubated project, and deciding whether to promote it toofficial project / sub-project status or, in case of failure, to retire it.

The incubator (like the board) does not performfiltering on the basis of technical issues. The foundationrespects and supports a variety of technical approaches. It doesn't fearinnovation or even internal confrontation between projects which overlap infunctionality.

The incubator filters projects on the basis of the likelihood of projectsbecoming successful meritocratic communities. The basic requirements forincubation are:

• a working codebase -- over the years and after several failures, thefoundation came to understand that without an initial working codebase, itis generally hard to bootstrap a community. This is because merit is notwell-recognized by developers without a working codebase. Also, thefriction that can develop during the initial design stage is likely tofragment the community.

• the intention to assign sufficient intellectualproperty rights to the software to the ASF -- this allows thefoundation to obtain an irrevocable and permanent right to redistribute andwork on the code, without fearing lock-in for itself or for its users, whilestill allowing the original author to maintain their copyright.

• a sponsoring ASF member or officer -- this person acts as the mainmentor, giving directions to the project, helping out in the day-to-daydetails and keeping contact with the incubator PMC.

The incubation period normally serves to estimate whether the project is able to increase the diversity of its committer base andplay within the meritocratic rules of the foundation.

It might seem rather easy to achieve, but, in avolunteer and highly selective environment, attracting new committers isnot automatic.

Diversity of committership is important for two main reasons:

• it gives long term stability to the project's development. In fact, withall the developers affiliated to the same entity, the chance of seeing allof them moving away from the project at the same time is much greater thanwith a community of individuals affiliated to unrelated entities.

• it gives a greater variety of technical visions, This guarantees a better adherence to the environment and users' needs, thus ahigher chance of finding real-life use of the software.

Other Foundation Entities¶

Along with the Incubator, the foundation has several othercross-foundation projects. For example, the ASF does not have offices orbuildings. It's a virtual entity that exists only on the internet, and the Infrastructure team manages thetechnical infrastructure that enables it to operate.

Read more about these and other cross-foundation projects on the FoundationProjects page.

The ASF also hosts some foundation-wide mailing lists, which you can learn abouton the Mailing Lists page.

In review...¶

The ASF represents one of the bestexamples of an open organization that has found balance between structureand flexibility. We have grown from 200 committers to around 3000, and thatnumber continues to grow on a daily basis. We have been able to createsoftware products that are leaders in their markets. We have alsobeen able to find balance between openness and economical feasibility. Thishas earned us respect from individual users of Apache software andmultinational corporations. We hope to continue to provide inspiration forbusinesses, governments, education programs, and other software foundations.