Having an Open Source license is not enough to bring users and developers to your project. You need an active and supportive community too. This document looks at what makes a successful open source community.
Note that to discuss aspects of community development you can join the OSS Watch community-development mailing list.
- Types of Community
- Developing Community
- Keeping the Community Informed
- Inter-Community Communication
- Tracking Community
- External Links
Communities must be managed. It is important that community members feel valued, appreciated and important. This creates some overhead for the project in the early stages. However, the payoff is high. If you manage to build a self-sustaining community you are well on the way to building a self-sustaining project.
How a community is managed and built depends on exactly what kind of community you are trying to create. However, one thing that is common throughout is that potential community members should understand how it works, what the governance is and how they can contribute if they desire. Failure to communicate this to potential community members will result in lost opportunities, as can be seen in the following excerpts from a thread on the OpenProj forums.
"OpenProj is about 80% of the way there to being usable in production and looks *really* promising. However, I think it will take a bit more effort to get it to 90%, so that we can really begin using it and relying on it (nothing ever gets to 100% ). I really think you need more QAers in on this, but that will mean that you'll be hit with a lot more work as more bugs get detected, you'll have to proof-read documentation etc. etc.
- I'd love to give it a go but what do the developers think?"
to which another user responded (in part):
"I agree that OpenProj is very close to being a really good piece of software, but unless there is no change in handling the issues, I have to move on and try to find another solution. (And, yes, should the software become usable to me, I would be willing to offer own effort as far as requested an possible.) "
and a further comment from the original poster included:
- "My feeling was that there are a couple of developers who do get into answering questions. They do seem to be 'members' of the project. However, there appears to be no information anywhere as to how to 'join' the project."
Here we see a project that could, with a little effort, gain the expertise of two new users and, more importantly, contributors (one of whom I happen to know represents a fairly significant institution with access to reasonable resources).
Types of Community
There are a number of different stakeholders in any project, each of these stakeholders will be part of one or more communities. Sometimes these will be communities nurtured by your project, other times they will be pre-existing external communities. This page is concerned with creating, managing and engaging with open development communities. People interested in more restricted communities may want to read our page on CommunitySource.
Your user community is the one you need to nurture the most. Users are the lifeblood of any project, without them there is no project. However, they provide more than a reason for being, they also provide valuable feedback about whether the project is doing the right thing. You should give your users the opportunity to tell you what the requirements of the project are, which are the most important features to implement, which bugs are the most important and what strategy the project should adopt.
Users are also the best people to support other users. People who work on the code are often too involved to be able to give clear and concise answers about how to do something. However, those who are actually using the code on a day to day basis understand the frustrations of being a new user and have found the simplest way of doing things.
Finally, your users are important because they are your future developers. Their contributions may be in the form of documentation, or they may be in the form of bug features or even new features. If they do not have the skills themselves to implement what they need they may have the financial resources and sufficient desire to seek out a contractor to do the work as a paid employee.
Rule number one of community development is "look after your users".
A committer is someone who has shown commitment to the project. They have contributed to the project in some way other than asking for things to be done. That is, they have done more than report bugs that need fixing or make feature requests, important as these things are, someone has to actually do stuff. Committers show commitment through one or more of the following actions:
- write documentation
- fix the bugs
- implement features
- support other community members,
- manage infrastructure and IPR
- evangalise about the project
Project Management Community
Depending on the GovernanceModel of the project there may also be a project management community. This consists of those who are able to make decisions about the future of the project. In some projects the committer community and the contributor community are the same thing, in others the project management community is a subset of the committer community.
Communities change shape throughout the life of a project. For example, in the early days a project will be made up of a small number of contributors an no users. As project outputs mature users will be attracted. In a healthy community users become contributors.
It is necessary to create an environment in which this kind of community development takes place. For more information see CommunityMetrics.
Attracting Community Members
At different stages in the life of a project you are likely to find the need to focus different types of community member. For example, in the very early stages you will most likely be looking for strategists and experts, people with a vision for where the project should be going. As your strategy and direction becomes clear it is likely that you will focus more on expanding your contributor base, that is you'll need to take early releases into something more concrete and useful. As your outputs become useful you will want to attract more users and encourage them to provide you with valuable feedback.
Each type of community member will respond to different types of message. In the following sections we discuss what messages you should be trying to communicate with each type of community member.
However, knowing what message to convey is only half the problem. Understanding how best to communicate your message is also important. In the following sections we also point to some common tools for communicating with different types of community member.
Attracting Strategists, Experts and Early Adopters
Strategists, experts and early adopters like to get into a new community early. They like to feel that they are at the forefront of something new.
Strategists usually have a fairly wide view on things. They think about how one solution may interact with other solutions in order to help address a bigger problem. They are the kinds of people who recognise the need for joined up thinking. However, they will often lack the detailed understanding of a specific part of the problem to be able to contribute directly to the solution.
Strategists are attracted by the idea of solving a bigger problem than the project itself may be addressing.
Experts, on the other hand, have a narrow focus. They know all there is to know about a specific problem domain and can help find solutions. However, they often lack the wider knowledge to see how any given solution will fit in to the bigger picture that strategists see and users are a part of.
Experts are attracted by the fact that they can have an immediate impact on the problem being addressed.
Early adopters are the people who are affected by the problem being addressed. They are willing to join a project early in the hope that, one day, it really will solve their problems in a meaningful and useful way.
Early adopters are attracted by the fact that if they help out their problems may go away.
The Message for Strategist, Experts and Early Adopters
Strategist, experts and early adopters need a clear indication of what the problem is that is being tackled. They may need pointers as to how this problem interacts with other related problems. They will certainly need to know that this is an early stage project and therefore appropriate engagement would be welcome and of considerable value. It is therefore necessary to clearly define what is considered to be appropriate contributions.
Tools for Communicating Your Message
These early adopters are most responsive to information about the project in terms of where it currently stands and where it is intended to go. This is discussed further in our page on MarketingDocumentation.
Contributors are more interested in working directly with project outputs than with strategy discussions.
Tools for Communicating Your Message
In addition to the documentation content described above contributors will appreciate more technical documentation.
=== Attracting Users ===]
Users are most interested in how to get started solving their problems.
Tools for Communicating Your Message
In addition to the documentation content described above contributors will appreciate more descriptive documentation.
Supporting Common Interests
Communities have common interests, one way of ensuring that new members become aware of your community, and to ensure existing members keep coming back, is to provide services supporting those common interests. This section describes how you can leverage other sites services to increase the offering to your own community.
Targeted Search Engines
Create a customised Google search engine Great if there are several sites containing the bulk of the community and these sites a google-accessible. Less good for communities which google doesn't index.
Examples of Targeted Search Engines
Your community will undoubtedly be interested in events relating to their interests. Why not maintain a calendar containing these events?
Keeping the Community Informed
There are two types of community member, the user community and the committer community. Each requires different information, so each requires a different communication channel.
The user community is not interested in developer level discussions, however they are interested in how to use the software, how to report bugs, how to make feature requests and advances in the software since the last time they looked at it. Typically a user will expect to see:
Announcements MailingList and/or RSSFeed
MarketingDocumentation (although they would see it as project information)
Users who are moving towards being a committer will also expect to see:
The committers need to be able to keep track of what is happening in the project, what is changing and what people are working on. They will usually expect to see (in addition to user tools above):
Project management should, in the main, be done using the standard committer tools. However, some aspects of management need to be carried out in private, consequently there will may be:
Project Management MailingList
Lazy Consensus is a governance/management technique in which action-takers publicly announce they will take a particular action after a specified time, unless someone objects. If objections are raised, other governance/management techniques are used to resolve the issue. If no-one objects the action is taken and those to whom the action was announced to are deemed to have consented to it. Lazy Consensus, also called lazy approval is common in the Apache projects.
Lazy Consensus explicitly gives power to those active in a project by giving action-takers a clear path to get community approval for an action they want to take which is unhindered by the need for the multi-party involvement of techniques such as consensus. Lazy Consensus is ideal for small, technical changes which the action-taker believes will have the support of the community. It should be avoided for large, controversial actions, particularly those which are irreversible.
Version Control Commit Mails
Most version control systems will send an email to a mail list whenever a change is committed. This can create a considerable amount of mail, however, it is a very useful mechanism for keeping your contributors informed. Once you get used to reading them they don't take a great deal of time to process. Also a good way to encourage committers use good commit comments, because people actually see the comments immediately.
My approach is outlined below:
I use Thunderbird so the Colored Diffs add-on is really useful. It makes reading the emails much easier.
- have filters that separate the commit mails into sensible groups (the subject is always the same form, so I filter on the module name, in this case "trunk/communityWorkshop"
- review subject line first - it may be a file you don't care about
- Review the log message - this should be enough to understand the intent
- if appropriate review the actual change (check for spelling errors, get full details of the change etc.)
- if comment is necessary just hit reply, it will go to the team discussion list
- if no comment is necessary archive the mail
For instructions on how to set up your SVN server to send commit mails see SVN_Commit_Messages
It is important that you understand who your community members are and that you are providing the information they need. There are many ways of doing this, without doubt, the most effective is having a very open environment in which your community is encouraged to voice their concerns (and you listen to them). However, don't be disheartened by the proportion of negative against positive comment. People will complain, but they will rarely praise.
Another useful approach is to track your community members use of your web site. We currently use Google Analytics for this (we'd love to hear about open source solutions that provide similar tracking). However, it is important to not obsess about statistics. Set yourself a few simple goals and work towards them, tweaking a little at a time. We have a page for GoogleAnalyticsTricks that we find useful.
It is less productive to track download statistics, such information is not really that useful. This is because each download may be passed to multiple users and there is no guarantee that a download translates into a successful install and use.
However, it is a good idea to add something to your installation scripts or your GUI that requests that users register with you. Make it as simple as clicking a send button on a pre-filled form (wherever possible). You may even add a user tracking feature that periodically pings you to tell you an installation is still in use. However, if you are going to do this ensure that you tell your users and give them the option to turn it off.
Another useful trick is to have an obvious link to your issue tracker and mail lists on every significant page of the application. Encourage your "unknown users" to become "known users" through engagement with your community tools.