Engaging Open Source Communities
- The Open Source Community
- Free as in Lunch
- Existing Communities and the Stealth Geek
- The License Question
- Why Bother?
Quite often, I'm asked how academic or commercial organizations can engage with open source communities. The most recent person to ask had a complex model, used by a number of climate research groups, and wanted to encourage independent developers to review and extend the code.
This problem is increasingly common. A lot of companies are open sourcing products for the sake of the public relations advantages, but discovering that no one cares. They go to a lot of effort to ensure that they own the rights required for a fully hippyware release, often rewriting some third-party components, and then find that they get no outside contributors. So what can you do to avoid this situation?
The Open Source Community
The most common reason for opening code is the promise of thousands of developers working on your code for free. Ohloh currently tracks more than half a million developers, so surely it must be easy to persuade some of them to contribute to your project, right?
The mistake is in thinking of the "open source community" as an organization. This is like referring to the European Community in 1914, or the "corporate community" now. There are lots of open source projects, each of which has a smallish community. Some people are members of more than one community, and some of the projects are closely related.
I contribute to a project that provides an obvious example. Most of the Étoilé developers also contribute to GNUstep, which is a major dependency of Étoilé, but the converse isn't the casemany GNUstep developers don't contribute to (or even use) Étoilé.
Even if you look at closely related projects, such the Linux kernel, GNU libc, and the GNU Compiler Collection, which are most commonly used together, you'll find a widely different set of contributors. A few people contribute to all three projects, but most work on only one. Many people work on only one component of one project.
If you set out thinking that the community is one large homogeneous blob and that you can approach it as a whole, you're doomed to failure.