What It Takes to Build an Open Source Community

People often wonder about what it takes to build an open source community. Either if you think that is just about throwing code over the wall or you believe it’s a daunting task, this blog post is for you.

An historical perspective

For an historycal perspective on the matter, a recommended reading is Brian Behlendorf’s “Open Source as a Business Strategy“. Make sure to read the bootstrapping paragraph, it gives you a pretty good understanding of how much effort requires implementing and maintaining an open source strategy.

About Giving Away the Crown Jewels

Assuming you know the difference between differentiating and non differentiating features – courtesy of Bruce Perens – and giving for granted that you won’t give away your crown’s jewels, let’s discuss why you want to share your code. The main reason why you want to do that is because you want to cut maintenance costs and because you love external innovation happening at your project. We’ll assume that the marketing hype associated to the launch of an open source project isn’t as common as it used to be, and we won’t dig into such tactilities.

Borrow or Share

There are basically two approaches: borrowing existing open source code and improve it or share a brand new piece of code. Borrowing might sound trivial but it requires a lot of home work to evaluate and select open source software, but no effort to build open source communities. The idea is that such communities are already out there, and all boils down to learn how to participate. Engaging with an existing community might be trivial if all you need is to open a ticket or ask for a tip, most of the time an understanding of classic netiquette.

While open a ticket maybe easy, get your own patch, module or plug-in accepted could be more complicated. Few open source projects, especially those backed by foundations, provide documentation and how-to that explain how their architecture of participation works. The point is that in general it is not so easy to figure out how a community works until you become an active member of such community. So said, there are some common pitfalls that you can avoid, namely:

– Throwing your code over the wall out of the blue (you need to engage early, and release often);
– Push hard the community to take action (others’ time need respect, as much as yours);
– Having no one taking care of community relationships (name a liason person);
– Forking (bottom line, avoid higher maintenance costs unless you have a very compelling reason for that).

Sharing your code is a way more complicated, yet might well be part of your Key Activities, one of the 9 building blocks of your business model. As anticipated we’re focusing only on sound business strategies based on open source co-creation, that is we do not consider pure marketing reasons as valid raison d’être.

Scratching your personal itch may well be a good start – as Eric Raymond says in “The Cathedral and the Bazaar” – but it might not be sufficient to get others willing to maintain and enhance your code. You definitely want to answer few questions before sharing your code, and among them at the least the following:

– Does already exist another piece of code doing the same job? And if it exists, how your project would be “different”?
– How are you going to manage all IP issues? Which license would you choose, what third parties need to do to join the project?
– Would you craft your architecture of participation from scratch, or would you take inspiration from other communities?
– Would you incubate your project at an existing foundation, create a new one or none of them?

Asking yourself if something like that exists is mandatory. Homesteading the noosphere isn’t easy, and you want to know if others are already actively pursuing hackers and third parties to actively engage with open source communities having the same goals as yours. Being a first mover is not a badge for success, but if you know others are already doing something similar, if not equal, you’ll need to know why people should prefer your project. And communicate it effectively, eventually.

IP Management is key for a growing a sustainable community, and you can’t expect people to join you if you don’t make clear under which conditions you make your code available to them (and others) and what it takes to become part of your community. There is no reason to explore all open source licenses here, you might want to read some good articles or look into existing tools to compare licenses and more. We believe there are enough freely available resources around to make your own mind around this choice. Last but not least you might even change license later, especially if you adopted a Contribution Agreement policy that allow you to do so.

Copyright Licensing/Assignment. When it comes to establish how copyright is managed by a given project there are basically two choices: contributors are required just to abide a given license and to license their copyright work, or they are asked to assign their copyrights to someone else. Beyond what kind of approach you’ll like, there are also clear trade-offs between asking or not asking contributor to sign an agreement. If you want to reserve the right to change license at a later stage, there is little choice, though. It must be said that making compulsory to sign an agreement won’t help much to attract external contributors. You might want to read this excellent guide to the Contributor agreements, and then eventually pick up your favorite agreement, if any. Note that it’s uncommon (at best) to see vendors adopt a very light approach to the topic, while there are few open source projects not requiring any paperwork at all.