Starting a large-scale open source project? The Apache Software Foundation is the benchmark against which you will be measured.

We’re now well beyond the point where open source has “won”. We’re seeing the open source idea starting to mature beyond even adolescence into adulthood. As it does so, our understanding and expectations of open source communities need to expand.

First there’s the matter of practical scale. In the last few years, we have seen huge trade associations formed around open source projects like Eclipse, OpenStack and Cloud Foundry, as well as equivalent public benefit structures in organisations like CloudStack at the Apache Software Foundation and pseudo-independent community activities — that remain legally attached to parent corporations — such as Fedora, Ubuntu and OpenSUSE.

Second there’s the matter of economic scale. Each of these projects drives a valuable market for multiple corporations. That has the natural consequence that as these projects grow in importance, the forces of corporate politics will increasingly be brought to bear on them. We have multiple examples of how communities of developers can scale around code projects, but these large-scale communities with large-scale economic politics are a different case.

So how do you design a new open source community for these kinds of scale? It’s worth spending some time looking at one of the oldest, largest and best open source communities to see what the maturity issues will be for these large organisations.

Studying Apache

Apache is the best-thought-through open source community I know, having been thoughtfully established in 1999 and then steadily evolved as each new challenge emerged in the following decade. It is also home to some of the most important, widely-used and truly independent open source projects I know, such as Apache Httpd and Apache Tomcat (among many, many others – Hadoop for example has created a whole industry).

When I experimented with a scorecard for governance quality a few years ago, Apache came out with the highest score of any open source community, a perfect 10. Apache embodies all the key principles that make open source communities work. For example, and in no particular order:

1. It is contribution-driven, where those who can do, those who can’t stay out of the way and decisions are usually based on contribution rather than debate – a “do-ocracy” where “code talks”.
2. It maintains a separation of powers. Its governance separates organisational authority – the operation of the board of directors – and technical authority so that orderly compliance with organisational rules (in their case associated with being a non-profit US corporation) has no practical bearing on technical decisions. As a result, there is a surprisingly broad range of approaches to individual project governance — see “modular”, below.
3. It has the expectation of transparency, with all decisions taken in public. A well-known saying  at Apache is “If it didn’t happen on a mailing list, it didn’t happen.”
4. There’s an expectation of affiliation diversity in each project, so that no single company runs a project. When this is breached, as occasionally happens, the Board will step in.
5. It is a level playing field where status is based on the skills of each individual rather than on their affiliation and every contributor has equal rights and opportunities regardless of their personal attributes.
6. It is modular, with projects taking decisions largely independently of the larger organisation while doing so within its framework of rules.
7. It embodies IP certainty, where every line of code is from a known source and licensed in a compatible way that has as few side-effects for the developer and deployer as possible, using an OSI-approved open source license with patent protections.
8. It is decentralised, both in terms of governance (per “modular” above) and in terms of copyright ownership. Apache avoids gaining ownership of the copyright of contributions, preferring to secure just a copyright license (which it does twice; one through the open source license and again through a contributor agreement – this may not be something to copy). This means Apache projects can’t be readily subverted through ownership of the copyright.
9. It embodies software freedom while not evangelising it. Apache’s rules each exist for pragmatic reasons, yet the connection between them and the four freedoms is undeniable, strong and a compass for navigating them.
10. New projects enter Apache through an incubator project, so that all the above can be established transparently in advance of project permenance.

To summarise, Apache creates a safe space for collaboration where everyone has the same rights and everyone has the certainty they are free to innovate. There’s more in the Apache Way Primer.

Apache has provided a reference point for many, many communities as they have designed their governance and you should be prepared in every case to say why you’re doing it differently if you choose to invent a new legal entity. This is not to say Apache is perfect; its rules are occasionally “gamed” and there are other caveats too which I’ll cover another time.

So Why Not?

So why not just join Apache? That’s a great question every group that’s thinking of starting a new “open source Foundation” should ask. Some of the better reasons include:

• Scale of project: If the project you’re starting already has such a large community, market presence and codebase, it may be hard to force-fit into Apache without significant breakage. Going through the incubation process really does mean everything is open to question and change.
• License choices: Apache’s strict and unvarying requirement that all code in the project be licensed under the Apache License may prove an insurmountable barrier. Your community may adhere to norms that expect use of another license or even dual licenses, or your project may have dependencies on significant amounts of code under a license that’s incompatible with the Apache License such as the GPLv2.
• Governance realities: Your project may exist in a business-political context that means an open and level playing-field is simply impossible in practical terms. But to quote a famous song, “There May be Trouble Ahead” if this is true.

Even if one of these applies, you still might be smarter to join an existing “umbrella” like Software Freedom Conservancy in the US or Public Software in the UK. But if you do end up devising your own organization, you won’t go far wrong by starting with the Apache Software Foundation’s principles.

[Made possible by Patreon patrons]