Building an Open Source Community

There are many books published that explain how to build communities, but not so many explaining how to build a developer community, and hardly any which focus on open source communities. Some might say that open source communities "just happen", and that they operate on intuition and unwritten social rules, but this logic overlooks the vast quantity of open source projects that fail.

Given the importance of the communities around open source software, it's essential to understand the hallmarks of successful open source communities when starting your own open source project. Creating an effective framework in which the community can operate often makes the difference between success and failure.

Doing this properly involves thought and effort, both up front and in life. It's best for you and your organisation to be aware of this before you get started, rather than being under the illusion that the framework will somehow create and manage itself!

So here are some guidelines to consider. There's no guarantee they'll work, but the better these are implemented, the higher the chance that the community will coalesce with unforeseen benefits.

1. Might seem obvious, but figure out why you're building the community in the first place. Is it just to improve adoption? Improve credibility? Improve quality? Develop an ecosystem of support? Whatever it is, figure this out and make sure everyone on your team knows and agrees. Try and hang some rudimentary metrics off the targets, so you can track progress and make course corrections.

2. Get ready to relinquish control of “your” product. The most successful communities form around things they can influence and drive. The more control you hand over, the more chance your community will form, and the more chance someone will come up with an idea you haven't thought of. I'll say it again: Give away as much as your business can handle.

3. Consider the motivations of the community. Most developers are driven by some or all of the following: (a) a desire to be creative, (b) a desire to share, (c) the need to make a living. Let's look at these in more detail.

3a. The desire to be creative. Consider the nature of what you're handing over. Is it obvious what it should be used for? Or has it been designed to be used in all sorts of interesting ways? Try to design products that can be used in as many ways as possible. Make it interoperable and extendable, so it can be combined with other products. Open standards are the way forward. The quality of the  supporting documentation can also make a big difference.

3b. The desire to share. Open source developers take pride in sharing their work with their peers, and this is how they establish credibility in this space. If you're creating community tools, make it as easy as possible for developers (and potential users) to share their work and for others to find it. Help developers to find each other, and work together, and then get out of the way!

3c. The need to make a living. By giving people a platform to demonstrate their creativity and skill, you improve their employment prospects.

4. Demonstrate humility. You need the community more than they need you. Someday, if you behave the right way for a long period of time, they will start to trust you and treat you as their moral leader. Even then you'll still need them more than they need you! You are the servant of the community, and thinking this way will drive all sorts of appropriate behaviour. And if you're experiencing friction with the community further down the path, there's a good chance you've forgotten this guideline.

5. Choose your language carefully. Avoid using terminology such as 'managing', 'exploiting' or 'owning' the community. Chastise your colleagues for doing so. Respect needs to be ingrained in your corporate culture. Once you've established the community framework, the only thing you can manage is your relationship with the community. Use words like 'influence', 'support' and 'help'.

6. Feedback loops need to be built into the core. Give the community tools for communicating with you, and make sure someone is responsible for dealing with this. Resources allocated to this must be fiercely protected; they are your ambassadors. Your best people should be involved. It is one of your top priorities, regardless of whether you've hit critical mass or not. If someone has a question, you'll need to be well positioned to immediately jump on the opportunity to give as much help as they'll take. Let your people develop personal relationships with community members. Let them meet in real life, and be ready to pay for the beer. Be ready to relinquish control over your staff as well as your product.

7. Be observant. The responsiveness outlined above is perhaps the most important responsibility when running an open source community, especially so in the early days. And if you're a large company, and like many large companies you're struggling to innovate, this relationship puts you in a unique position. From here, you can observe what people are doing with your tools, so you can improve them quickly in response. Build the products with this quick 'reconfigurability' in mind. And from this vaunted position, you can also identify potential partners with whom you could move your business forward.

8. Ship a quality product. If you think the developer community is going to finish your job for you, you're in for an unpleasant shock! Don't use a beta release as a reason to ship a product that's either incomplete or full of bugs. If you do this, you'll lose any credibility you may have with the developer community, and they mightn't come back a second time. In this day and age, there is no excuse for not building in quality as you go along.

9. Details *really* matter. If you're about to make a change to a product, service or community, no matter how small, make sure the community is happy with this. Without spamming forums, you still need to be sure the important people find out and can respond. If you're lucky, and you've done a good job creating the feedback loops, the community will tell you what they think.

10. When you've made a decision, explain it. Your explanation should stand on it's own; don't just point at a conversation - actually spell out the logic and the feedback that has led to your decision. Again, do so on the same forums as before. You owe the community that much.

11. Give some thought as to the most appropriate tools that the community will be familiar with – and use those tools. You need to relinquish control over the conversation as well as the product itself. There are perfectly adequate tools out there such as getsatisfaction, Google Groups,  Facebook, Soureforge, Trac, blogging software, simple mailing lists and so on. Anything that smells like BigCo might put off potential community members.

12. Be ready to provide financial support. Obviously, this depends on your budget and project, but it needn't be expensive. It could simply involve buying community contributor Bob the latest Nvidia card so he can write drivers, or paying for Manuela to attend a conference so she can talk about the project. Having the feedback loops mentioned above should help you spot these opportunities to develop ambassadors outside your organisation.

Of course, even if you take account of all of these opportunities, there's still no guarantee that your project will be a success! But as we can see there's an awful lot of things that can be done to improve the odds.