Simple things that work and those that don’t

It is tempting to have a philosophical exchange on whether building a software community is more of an art or whether there is science behind it. Matt Assay in his News.com blog writes that it takes time, leadership and fair amount of luck. I don’t want to dwell much on luck except to say that timing plays an important role.

Instead in this blog entry I like to talk about some of the tricks of the trade that I have seen be successful and also a few traits that don’t help your community along.

Many of the successful software communities share behavioral characteristics:

• Its discussions air different points of view – in other words participants feel free to speak up;
• There is a sense of belonging, an interest in helping each other;
• There is encouragement to contribute according to one’s abilities rather than in strict pre-determined places.

How do you get there?

Humans want to interact with humans.

Before all else participants in your community must feel, must know that they are interacting with peers, with named individuals within your organization rather than with functions (“Admin” or “Tech Support” or whatever) and are doing so on equal basis. You will want to let relationships develop. Early on the JBoss community did something simple and very effective: a slideshow on the home page of profile photos of community members and their location. Not only did it put names to faces, it also showed the geographical breadth. Many of us have experienced that dispersed team members interact much better once they have met face-to-face. For your online community find ways to emulate that.

Almost always your freshly launched community will mainly have participants from your own organization. And so initially much of the forum discussions will be between members of your organization. A very important step towards the success of your community is to get others to speak up – to state their desires for the community, for the technology, to state their likes and dislikes, to answer (technical) questions from other members. In the Jini community (since then moved from Jini.org to the Apache Software Foundation) the Sun Microsystems engineering team adopted the practice to wait a day before answering a forum query. This moment of silence encouraged others to step in and provide answers. Very similar tactic as how to get people to sing along: pause half a note before the next line, if you keep singing on cue the audience will think “you’re doing just fine by yourself.”

You must follow through. If you ask for feedback, for ideas, for contributions then you must answer the phone when it rings. When asking for something you must be ready to act when responses come in. If you do a survey, you should share the results with the community. If you ask for bug fixes you should respond – accepting or rejecting with reason – within a decent time frame. Now this can be hard. If you have just open sourced several million lines of code of a long running project, you may not yet have had time to also make your engineering decision process accessible and transparent. But if you know you’re not ready to receive then don’t ask; communities tend to be quite unforgiving (and unforgetting) on this point.

Help newcomers find a home in your community. When new to a community it can be daunting to learn where one’s skills and available time match the community’s needs. Make sure there is a beginner’s guide, a place where newcomers can ask questions, pointers to various areas where one can participate (testing, bug fixing, documentation, translation, marketing etc etc). A few years ago a non-profit open source community started a new large scale project which drew much attention. On its mailing list several times discussions took place following the same pattern:

Newcomer: “Hey, this is great! Where can I best help?”
Project lead: “Hi! Anywhere you want!”
Newcomer: “But where do you need help?”
Project lead: “Everywhere!”

The project lead was probably honest about the everywhere part and one has to compliment that. Many of these exchanges ended in a similar fashion, however. The newcomer drifted away because the hurdle of joining in was perceived too high. Everybody is busy so don’t require someone to invest a lot of time to figure out how to come and play. Instead, the project lead might have wanted to interview the new person asking him/her their areas of expertise, what attracted them to the community and from there make suggestions:

“Well, as you speak Spanish and Portugese… you know … it would be great if you could help with translating some of the material. And that will help you find your way around and also get to learn other participants.”

Always find ways to draw people in.