Building a Developer Community

Many companies say they want to build communities, but take completely the wrong approach. They say something like 'If You Build It They Will Come'. This might be true in certain rare instances, but for the rest of us there is much to do to improve the odds of success.

There are numerous books out there that explain how to build communities, but not so many explaining how to build a developer community. These communities are more sensitive and enigmatic than, say, Digg-like communities, and I think they're more interesting too. We're talking about a class of community that can conjure up something completely new from your tools, which represents an intriguing path to innovation.

So here are some guidelines to consider. There's no guarantee they'll work, but I can guarantee that, the better these are implemented, the higher the chance that the community will form with unforeseen benefits. There are several planets you have to push into alignment, and then you have to keep them there. So here goes:

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 take course corrections.

2. Get ready to relinquish control of your product. The most successful communities form around things they can influence and help 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) a desire 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? If you were a creative type, would you rather have access to this:










Or this?










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 source and open standards are the way forward. Just having an api doesn't count on its own; the quality of the api itself and the supporting documentation can make the difference between success and failure. For webby projects, see REST.

3b. The desire to share. Software is abundant; easy to copy and reuse. In this environment, hoarding just doesn't make sense. The best way to get the respect of your peers is by demonstrating your prowess in your chosen profession. If you're creating a community, 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, and work together, and then get the hell out of the way.

3c. The desire to make a living. By giving people a platform to demonstrate their creativity and skill, you improve their employment prospects. Also, there's the tantalising prospect of acquisition (see 6, below).

4. Learn humility. You need the community much more than they'll ever 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. You don't 'own' anyone or anything, not even your product (if you've done it right), regardless of what the licence terms say. 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 shouldn't just be bootstrapped onto your service or product, they must be built into the core. Resources should be allocated to this, and fiercely protected. They are your ambassadors. Your best people should be involved. It is your top priority, 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 ready to change your product. The responsiveness outlined above is perhaps the most important responsibility when running a 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 innovative ideas that you can learn from, and possibly swoop in with an acquisition offer before your competitors get wind of it.

Does this sound predatory? Then consider the facts that developers (a) deserve to get paid like everyone else (b) might want to be acquired (c) might need the support to really get their idea off the ground and (d) have the option to turn down the offer. But don't be too surprised if the developer is offended by your overtures; for some developers, money isn't an incentive and their passion for the technology is more akin to a religion than a business.

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 won'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 cool 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. Lucky you.

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 is familiar with - don't force them to move the conversation over to your shiny new platform. You need to relinquish control over the conversation as well as the product itself. If you've followed the other points, there's nothing to be scared about. There are perfectly adequate tools out there such as getsatisfaction, Google Groups, Twitter, Facebook (which sucks, of course, but your audience might still be there), 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.

So all this should be considered nothing more than a general introduction; if you're charged with building your own community, I'd recommend you conduct some more in-depth studies to improve your chances. I can recommend reading the Cathedral and the Bazaar and Here Comes Everybody, and JP recommends reading Community Building on the Web. If you've got anything to add to this list of guidelines, or the list of the best books, please add them in the comments. Thanks!

Photos shared under a Creative Commons licence by Flickr users baboon and atomicShed.