Delivering on the promise

The year 2010 was a troubled one for several open source projects. We’ve seen projects leaving hosting services in a hurry after finding their services blocked for unspecified amounts of time.

People and companies fighting over ownership of project names and trademarks. Contributors leaving projects after realizing they were not really in charge after all.

In those examples, a few missing agreements or rules in the project’s organization and governance made failure possible.

The Apache Software Foundation (ASF) does not claim to be a perfect organization, but our model is definitely geared towards project sustainability, and makes most or all such events impossible by design.

Let’s discuss a few concepts that promote and enable this project sustainability.

Newcomers to the ASF sometimes complain about our “red tape”. People have to sign our CLA [1] before being granted commit access. Projects have to follow strict rules for voting and releasing software. Adding a committer also requires a specific process, which lasts at least 72 hours. None of this is really complicated once you’ve done it a few times, but it sometimes seems like extra overhead for people coming from smaller projects where everything just happens.

One very important aspect, that outsiders don’t always see, is that once you start a project at the ASF it doesn’t belong to you anymore.

It belongs to the foundation, including the project’s name, trademarks and logos. Having to give up ownership of a project name that you love might be hard, but the obvious benefit is that no disputes over names or trademarks can happen between project members: those things belong to a neutral entity (the ASF) so no one else can claim ownership of them at your expense.

The ASF, in turn, is governed by its members. ASF members are individuals, not companies, and a member is expected to act in the interest of the foundation, whatever his company affiliation might be.

In a way, companies do not exist as far as the ASF is concerned.

Companies don’t get a vote, and acting as company delegate is a major sin within the ASF, which is usually quickly identified and corrected by peer pressure, and could lead to exclusion if the member is unwilling to cooperate. Not having companies involved also removes a whole spectrum of possible disputes and political games.

By signing the CLA [1], committers grant the ASF a copyright license on their work. The copyright is then shared between the contributor and the ASF, both having the right to use the contribution as they want. Not requiring copyright assignment is also a good thing in terms of potential disputes, as the contributor keeps all their rights on their contributions. The CLA also includes a patent license clause, which in turn removes a whole spectrum of potential problems.

Thanks to the Apache License, anybody is allowed to fork an ASF project elsewhere if the need arises. A single project community is of course usually better than a split, but sometimes such things have to happen, and the Apache license makes forking as painless as possible.

The ASF’s voting rules make dictatorship impossible.

Every PMC member [2] in a project has an equal voting right, with clearly defined rules about vetoes, majority and vote form and duration.

This helps create an inclusive environment, at the expense of being too egalitarian sometimes. Nobody is perfect, and the ASF model might not be suited for all types of projects and communities, but those rules have proven to be very robust over time and work well for our types of projects.

Dictators don’t live here, not even benevolent ones.

Another very important rule in terms of inclusiveness and sustainability is that every project decision has to happen on the project’s developers mailing list. No one can claim that an important decision was made without pointing to a mail thread marked with [VOTE] on that list, so the decision process is clear, asynchronous and visible to all. If it didn’t happen on that list, it didn’t happen.

This enumeration of “sustainability enablers” is probably not exhaustive, and you’re welcome to complete it in this post’s comments, but I hope you see how these small things, put together, make all the difference. Apache is a place for sustainable projects.

These rules and best practices mainly revolve over our “community over code” mantra, which states that a good community with bad code will eventually produce good code, whereas a bad community with good code might just split and stop caring about their project.

Note the word “eventually” in that last phrase: the Apache model might not always be the quickest way to get there, but once your project starts being useful, and sometimes critical for businesses, Apache is one of the best places to help make it useful for a long time.


[2] .


Copyright © 2011 IDG Communications, Inc.

Download: EMM vendor comparison chart 2019
Shop Tech Products at Amazon