Community Doesn’t Come for Free

At Eclipse, we talk a lot about community. Developing a community is an important part of being an open source project. It is from a community of users, adopters, and contributors that a project draws strength and longevity. Without a community, an open source project is just a bunch of code that might as well buried on a server behind a firewall somewhere in parts unknown.

I can’t think of a single open source project that has found community success through a simple application of “if you build it, they will come“. Some projects are luckier than others: sometimes a technology is just so compelling that minimal effort returns huge dividends. More often, the overnight success of an open source project comes after weeks, months, and years of a combination of long work and hard work.

It takes effort to get your message out; and if you want to develop a community around your open source project, you have to get the message out. To cultivate a vibrant community of users, adopters, and committers, a project has to have somebody who is responsible for community development. Somebody has to own it. Everybody on the project team has to dedicate some significant amount of their time to community development, but one person on the team has to be responsible for it. For some projects, this may be a full time job; for others, it may be a huge part of one. In fact, may open source projects have more than one full time person working on community development. In some circles, this role might be called the project’s evangelist, or maybe it’s the project lead that manages community development. Whatever the title, the role should be that of making everybody else successful in community development activities.

Minimally, there are valuable activities that the project member responsible for community development can do for those lucky people who actually find your project:

• Co-ordinate responsibility for monitoring the project’s communication channels. Project developers can take turns monitoring community forums, and triaging bugs.
• Establish a response policy for responding for questions. How long should somebody expect to wait for a response? Will project committers create bugs on behalf of community members, or invite the community to open bugs themselves?
• Teach your team members to be courteous and polite in all communication. Make sure that anybody who finds your project has a pleasant experience.
• Ensure that the project is operating transparently. Decisions regarding project architecture, features, and more should be discussed in transparent forums that invite participation.
• Ensure that the project’s website and other sources of information are correct and up-to-date.

Being responsive for people who find your project is important. But is only effective when people actually find your project. There are many things that you can do to generate buzz and grow your community. Blogging, social media, attending and speaking at conferences, podcasts, and just simply speaking to everybody who will listen through all available media are important activities. But an attitude of “we blogged it so everybody knows about it” isn’t enough. Frankly, writing an occassional blog post just isn’t going to get people excited about your project. At least not in great numbers. Here are some things to think about:

• Know what kind of community you want to build and tailor your efforts to address that community through native channels. Know where the type of people who should be part of your community hang out. Find out where they get their information and take the necessary steps to get your voice heard on those forums.
• Develop an elevator pitch for your project. An elevator pitch is a 30 second to two-minute “sound bite” that describes your project in a way that be understood by a layperson. Make sure your developers can recite it.
• Establish drum beat of outward communication. Identify team members who can regularly blog, Tweet, podcast, host webinars and otherwise provide outward communication. Coordinate their efforts so that communication is regular: daily, bi-daily, weekly, whatever. It’s hard to ignore regular communication.
• Present and represent your project at demo camps, user groups, and other local networking opportunities.

Make community development a part of your project’s regular work that is every bit as important as writing the actual code. Make sure that all of your developers understand that community development is important and encourage them all to participate. Assume that it’s going to take a while. You’ll know that you’ve been successful when it starts to take on a life of it’s own (e.g. when people from your community start writing articles, blog posts, doing talks about your project at conferences, .,.).