When Apache, when not

A Sourcesense colleague, after hearing that some people were questioning the value of Apache as a destination for open source software, asked me to clarify to him when Apache is, and isn't, a good place for your open source code.

Here's what I told him:

I guess I would say "what are your aims with the project?"

If you are trying to make your development process easier, then yes, Apache likely isn't the place for your project. I believe that the myBatis project has flourished outside of Apache.

However, if your aim is to produce code that is legally easy for your users to consume, then Apache's strictness comes into play. Apache has many rules and procedures, but generally they exist for a purpose. ICLAs are collected so the origins of code can be tracked. Voting happens to ensure that responsibility is held by the ASF rather than specific individuals, providing some legal protection to those individuals. Apache is strict about licensing, not to be difficult to developers, but so that end users can easily understand the terms under which they can use the software: simply those of the Apache License 2.0. Sometimes, as in any organisation, people can take these principles too far. However, by noting the core principles, that can often be brushed past.

This is why the ASF uses a model of mentoring in its Incubator, the place where new projects come to join Apache. If those mentors know and are familiar with these principles and how they manifest in the organisation, they can help the project learn how to use them to their advantage, without being overly hindered by them - thus helping a project's users gain from the principles underlying an Apache approach, while lowering the burden this places upon a project - a burden that the project undertakes for the sake of its users.

Apache does not have a state-of-the-art infrastructure, it doesn't have the finance to build one in the way that, say, Github clearly does. Its aim is, rather, to provide a usable infrastructure and a clear sense of governance for a project.

An example of a project that did make the decision to join Apache is Wave-in-a-Box, now Apache Wave. When they reviewed the issues that they faced in terms of governance, their view was that joining Apache /reduced/ the amount of work they would have to do, whether working out how to organise their community, deciding how to release, how power/influence was distributed, collection of ICLA documents, and ownership of the collective work that they created. Some projects are not at a point where they need to attend to such matters, a loose gathering of individuals collaborating online is quite sufficient. For other projects, as they grow, the above issues become pressing, and at such a point, joining an organisation such as the ASF can provide great benefit and allow developers to focus on coding, rather than on the legalities of setting up yet another open source foundation.

If you are considering joining Apache, the best thing you can do is clarify for yourself what you are looking for. Then look and see if joining Apache helps or hinders that. If you're not sure, attempt to make contact with people already experienced with the Apache approach, either via email lists (e.g. general@incubator.apache.org), or at some of the international gatherings that frequently occur. Then make up your own mind. The ASF isn't for everyone, or every project, but many do feel that they have found the right home at Apache.