Community over code.

The biggest mantra at Apache is: “Community over code”. In brief, this means that the most successful long-lived projects value a broad and collaborative community over the details of the code itself. Apache is best at helping communities of individuals work better together - the code is a secondary, if critical, part of how we work.

Obviously, the code needs to be useful; that’s what makes it worthwhile to work on over time. But while the best code around right now may turn into a tool that everyone uses today, the best community around will create and maintain a project that everyone helps build and improve for the long term.

Community Over Code is a way of encouraging long-term collaborative and stable projects that have a robust enough set of people working on them to be productively self-governing of the community while they continue to maintain the code. Community Over Code is also the new name for our ApacheCon conference!

What this means in practice

The most obvious example of Community Over Code in practice is how the Apache Incubator works - in particular, the exit criteria for podlings to become official, top level projects.

While many people ask: “Is the code ready yet?”, Apache asks: “Is the community ready yet?”

The Incubation process ensures that a new podling is following various ASF policies around IP, licensing, voting, and the like. How the podling community manages all these processes is part of the learning process, and are underlying criteria for deciding if a podling is ready to graduate.

But the most important exit criteria for a podling is: is the community ready to self-govern? Do the participants act as a coherent group that can fairly and independently lead the project’s code and it’s whole contributor community going forward?

In terms of podling graduation, that includes an evaluation of factors like:

  • Are there active committers from multiple diverse employers?
  • Does the podling hold fair votes, and welcome all productive contributors to the community?
  • Does the podling have enough active committers to survive some leaving in the future?

Why this is important

As a whole mindset about effective ways to build software products over time, there are many different reasons to emphasize collaborative communities over the details of the code itself:

  • Code is infinitely forkable. Open source is about allowing anyone to take, modify, and use the software. The value is in a collaborative group that is working in a mutually supportive way, where everyone can get out more than they put in. The project home that has the most engaged and active community will grow fastest, and has the best chance at being maintained into the future.

  • Broader communities - especially ones with a diversity of employers - are more likely to survive the withdrawal of any individuals or companies. Thus, Apache prohibits BFDLs, because what happens when that person leaves? Similarly, Apache requires a certain level of diversity, so that when one company changes direction (and all of it’s employees basically stop working on the project), there are sufficient continuing committers that the project has a chance to continue.

apache.org references

This phrase is used on the official apache.org website in many places, although there isn’t a comprehensive text reference as to why this is such a deeply important concept to the Apache Way.

This motto has been covered briefly in a number of overview sessions at ApacheCon over the year; so it appears in numerous slides, although the real explanation only comes out in the live talks (or videos).

Community is a persistent group mutually supporting each other

Tom McIntyre here provided a great way to think about community that closely echos what Apache looks for.

Watch what Tom McIntyre @tomisphere said about community (1min)