The Seven Habits of Highly Effective Open Source Products

This morning I talked with Andreas Constantinou of VisionMobile who was pleasantly surprised that all of our source code checkins (“internal” and external) were available publicly on open source repositories (specifically the superb GitHub) and that our bugs and issues were also all publicly available (on the similarly excellent LightHouse). It seems like commonsense to me, that this is necessary to be able to claim that your product is open source. But, alas, many companies are not following such a process. For example, in the mobile space both Symbian and Android do NOT keep all of their checkins and issues available externally (nor do they really follow many of the habits listed below today, though I expect that to change). It’s great that those technologies are available under an open source license like GPL. But is that enough to truly say they are “open source”?

I was asked by Andreas what we believe is necessary to claim your product is open source. Here’s our take on the appropriate criteria, roughly in order of importance and prevalence in the industry.

1. public source viewing – Of course you need the source for your product to be publicly viewable and reviewable. Most products claiming to be open source meet this criteria at least on a release by release basis (whether this is sufficiently granular and realtime we’ll discuss below)
2. common license – you need to make it available under some prevailing non-company-specific open source license. For example, our product is available under Gnu Public License Version 3 (GPLv3). Making up your own license does not count. I’m a busy software developer. But I understand BSD, GPLv3 and other common licenses. If you make up your own license and I have to read it all, its not open source in my opinion
3. public source code checkins - all checkins need to be available realtime on a publicly available source code repository such as GitHub or SourceForge. No “internal company repositories” or even a publicly available source code repository hosted by the company themselves.
4. public bugs – defect reporting needs to be on a publicly available bug database such as LightHouse.
5. public forums – discussions and support should be available on a google group or some other publicly available forum. Lurking (for other users to learn) is good and should be encouraged. Few companies are doing this
6. anyone can contribute – contributions from the community are good and should be encouraged. For open source dual licensing companies (companies like ourselves that make a commercial license available for users who need one), a contribution agreement will almost always be necessary. But it should be brief and similar to others.
7. public complete and modifiable documentation – Specifications and user documentation should be publicly available on a Wiki that users are allowed to contribute. Almost noone does this now but it should be encouraged and I believe will eventually become the dominant model.

In all fairness, right now the list of companies doing all of these things is quite small. However, plenty of individual open source developers (probably the majority) follow these guidelines, mostly because each one is a win-win for getting as much done as possible with as few resources as possible, leveraging the power of the community. I believe the first four (viewable source, common license, public checkins, public bugs) should be an absolute requirement to label your product open source. The last three are very good practices that we think will become more predominant over time.