Open Source and Community: Does it matter?

Funny what comes to your mind when you are forced to sit for 13 hours straight in one tight, crammed spot. At least that was my experience recently on a flight from Sydney to SnapLogic’s California offices in San Mateo. Trying to distract myself from aching limbs and my wistful thoughts about the far-away comforts of business class, I instead tried to – again – get my head around what it is that makes open source projects successful.

Aside from the obvious commercial measure of success there is certainly the other, slightly less tangible way to check on the state of an open source project: Community contributions. After all, the source is open to be examined and modified freely. So, an active developer community is then often seen as a key indicator of a project’s success. With a large, active developer community, the traditionally touted benefits of open source come to play: Peer review by many, quick fixes to any identified issues because of a large number of developers, and so on.

However, looking at some of the most prominent open source applications, such as Firefox and OpenOffice, the number of developers is entirely insignificant compared to the numbers of users. And even in absolute numbers, the contributor communities in these projects is not huge by any measure. For example, Ohloh knows of only 429 contributors to Firefox. I know that the numbers in Ohloh are not always correct, but I assume that they give at least a decent indication of the magnitude.

Of course that is to be expected: Just like with a read/write enabled web, we know that there are many more consumers of content than producers. Same with software. If it is the openness of the source that drives community contributions, we in the open source industry do not have to wonder why these developer communities are small. After all, hacking or extending someone else’s source code is a daunting endeavor:

  • Understanding someone else’s source is hard. Good code documentation, design and architecture may ease this pain, but usually it remains a challenge.
  • You could break (other people’s) stuff, which is something we naturally shy away from.
  • Your stuff will be examined, critiqued and possibly rejected as you are trying to check it in. Most people don’t like rejection or even critique.
  • Along the same line: Maybe your modifications or new feature are not what the maintainers of the project have in their vision of the roadmap. Again, your contribution may have to be rejected or will have to wait for a better time to be incorporated.

But does it really have to be the open source that drives the community contributions, and thus defines at least this measure of the success of the project?

Maybe the answer to this has been completely obvious to most people in the industry already, but for whatever reason, it took me that long, uncomfortable flight from Sydney to San Francisco to realize the truth: Open source actually does not matter at all when it comes to harnessing community contributions. It’s not the open source, it’s the open APIs!

Web 2.0 has shown us that community contributions can also add significant amount of value to entirely proprietary, closed source projects. Just look at the number of developers who use the APIs from Google, Amazon, eBay, Facebook and others. And even in the non-Web 2.0 world there are traditional examples like Microsoft’s APIs for Windows, which is obviously used by millions of developers. None of the source of these companies is open, the code under the hood is entirely proprietary. Instead it’s all in the well-defined, open APIs that are being published by these companies. The APIs, the entire businesses they enable, and the contributions that have been made by the community have increased the value of these platforms immeasurably.

What makes contribution-via-API so attractive (as compared to contribution-via-source)?

  • You don’t need to understand someone else’s code, which is a huge factor for many potential contributors.
  • You can start with a simple ‘hello world’ example, which is normally provided in the documentation for any of the APIs, and go from there. This is a model that tends to work very well with a lot of people, since you will instantly have something to try and run. Instant gratification for developers.
  • No risk of breaking things: The API (should be) designed in such a way that whatever you do will not impact anyone else who uses the service/application.
  • No risk of rejection: You just use the API. No maintainer has to agree to your view or vision. You can make your contribution public in any way you like, if necessary completely independent from the actual project.

The source might be there for anyone to work with, but even open source companies should spend time and effort to design open APIs, since that is often the much easier, less painful way for contributors to get started. And some of the closed-source vendors with their APIs can teach us a valuable lesson.

Some traditional open source projects, such as Firefox, already have a good approach in that they support well documented APIs for extensions (plugins). For them this is an effective way to harness a very creative and active user community.

On the other hand, open source companies have an important advantage over the closed, proprietary providers of open APIs: Some contributers just want to get into the guts of the system, contributing on much deeper levels than just the APIs. In that case, well designed and inviting code and clear architecture can go a long way to attract those extremely valuable developers. For this reason, I like to see the code in an open source project as a feature in itself: Every feature ads value, and if good code is a feature that attracts good developers then it certainly ads value as well. But those developers are the exception. Most potential contributors will feel much more comfortable in the safety of a ‘sandbox’ offered to them by a well defined open API.

Sometimes it is said that developers get into open source because they need to ‘scratch an itch’: They needed something done for which no right tool was available. In many cases this is what draws people to become contributors to already existing projects as well. I would say that open APIs to key components of your system allow many more developers on different levels of expertise to contribute and to scratch their itch without having to go through the often frightening process of hacking code.

So, if you aim to build a large contributor community for your open source project quickly, aim for open APIs, not only open source.

Subscribe to Blog Updates

Quickly connect apps, data, and devices

Start Free Trial
Contact Us Free Trial