Community is vital to an open source project. An active and supportive community is the heart of the project. However, having an open source licence is not enough to bring users and developers to your project and build a community. This document looks at what makes a successful open source community.
Open source software projects are not really any different from other kinds of software projects in how they are initiated. They start out either because someone wants something built or, in the case of product development, someone intends to meet the future needs of others. In the former case, the possibility of sharing the end-result may never even be considered. In the latter case, there is the specific intention of sharing the software, often generating revenue from an appropriate business model.
Communities are simply groups of individuals sharing common interests. Both closed and open source projects have communities of users, most of whom will be relatively passive in terms of their interactions with other community members. On the other hand, either type of community may have members who decide to take on more active roles through, for example, reporting bugs, helping other users, writing documentation or evangelising. The most active members may even be rewarded for their efforts. Microsoft, for example, rewards those in their user community who help people make the most of Microsoft technology through a Most Valued Professional (MVP) programme. In open source communities, active members tend to be rewarded by being granted additional access to, and control over, the project.
Although there are some rewards in closed-source projects, there is a clear limit on the types of contributions that can be made by members. Because the code is not open to inspection, there is ultimately no way for users to actually go ahead and fix problems or develop new features and contribute code back. By contrast, the possibility exists in open source communities for a flow of information (code and documentation) from any member of the community into the centre, albeit in a moderated form. More importantly, for any given problem, the possibility is there for a large number of "eyeballs" to be looking at it, harnessing the brainpower of the entire community. In a closed-source project, the maximum number of people looking at any given problem is always bounded by the total number of employed developers.
At their outset, open source communities may be extremely small, perhaps with one or two developers and hardly any users. Depending on the type of project, this situation may go on for some time, even years, as an "incubation period" during which the initial team works hard to get something working off the ground. Eric Raymond, in The Cathedral and the Bazaar , states that a necessary pre-condition for success is having "something runnable and testable to play with". On the other hand, "runnable" does not mean perfect or even complete. "Release early and often" is a well-known mantra of open source development, not least because doing so can attract invaluable early feedback and build confidence in the project. For this reason, communities should not be fearful or hesitant about putting out materials early; significant benefits can be realised provided expectations are managed clearly and truthfully.
If the software is to eventually attract users, the presentation and branding must convince prospective users that the software does something significantly better than the competition. Once interest has been secured, the barrier to entry must then be low: for example, simple things, like the installation procedure, need to be extremely slick. Signing up users is not the end of the story though; in the long run, developers are needed too, at least to handle the the smaller contributions that may bog down a lone developer. Developers might emerge from the immediate user-base but may also come from elsewhere, drawn in by the technical challenge, kudos, or opportunity to improve or publicise their programming skills.
Opening up a project in this way can add whole new sets of complexities. Karl Fogel in Producing Open Source Software states, "Opening up means arranging the code to be comprehensible to complete strangers, setting up a development web site and email lists, and often writing documentation for the first time. This may appear to be a lot of work. Plus if any interested developers do show up, there is the added burden of answering their questions for a while before seeing any benefit from their presence. However the extra effort is at least partly countered by the ready availability of collaboration tools like Sourceforge and Google Code. In addition, opening up projects does not necessarily mean losing control. Many projects, in their early days, are run as "benevolent dictatorships" with a single person responsible for developing major new functionality and reviewing contributed code.
Benevolent dictators need not possess the greatest technical skills, but they will, according to Fogel, have "the ability to recognise good design". Fogel goes on, however, to make the point that their main responsibility is ensuring participants continue to share the belief that they "can do more in concert than individually". Developers will only remain if their leader can make the project a place they want to keep coming back to. This means rewarding hard work by giving credit where it is due and, for those that want it, responsibility for more significant pieces of work. Management of open source projects has been described as active, informal, and low-key. Successful benevolent dictators are also said to "speak softly". All of this requires considerable people skills and as Raymond suggests, "a little skill at charming people".
It is the responsibility of community leaders to ensure conditions continue to be right for the full potential of open source to be realised. This does not happen automatically and has to be carefully managed.
In their early stages, the most significant concern for projects is likely to be dealing with the inevitable support burden. Handled badly, this might at best, lead to users turning away and at worst might lead to the founder giving up. If success is to be achieved, the leader ultimately has to find people to carry out this work. Employing people is one option; another is encouraging users to help out each other by writing documentation and fixing bugs. However, if this is to happen, there must be an infrastructure in place to allow them to do this. Contributions need to be proactively encouraged and leaders also need to ensure that contributions are helpful and not just opinions.
Once projects do become well established, other dangers come into play. One is the ever-present possibility that someone might take the code and set up a competing project. This eventuality, known as a "fork", is damaging because it divides and dissipates the developer community, confuses and undermines the trust of the user community and leads to needless duplication of effort. As the user and developer communities are the life-blood of any open source project, any damage to these will always threaten the overall sustainability of both projects. The urge to invoke a fork might arise for any number of reasons, be they technical or political, but it is only likely to be significant if carried out by someone with enough of a following within the community. In any case, their well-documented disadvantages have led to strong social pressure against them and participants consequently tend to compromise first.
Healthy open source communities must have the capacity to outlive their founder's original interest in them; while they rely on a dictator, they risk fragmenting and falling apart when their leaders move on or retire.
In most communities, even those governed by dictatorships, those other than the founder will increasingly become responsible for making key decisions. The logical extension of this is a transformation away from dictatorship towards consensus-based democracy. This new arrangement does not imply that all decisions, however minor, are made by committee. More frequently, decisions are made by "lazy consensus": if nobody objects to a given proposal within a certain timescale, it is passed. Another convention that speeds things along is for small, easily revertible changes to be commonly made before they are discussed. If there are objections, changes are simply reverted through the power of source code revision control. Some questions, however, will be impossible to resolve through consensus and many communities, for this reason, institute some form of voting.
The more complicated these habits and procedures become, the greater is the need to aid newcomers with instructions on how they can begin to take part and have a say in the decision making process. Young communities might fall back on the body of knowledge built up and captured in mailing list threads but this does not always help newcomers and can leave them confused. What is needed is something written down, a "governance model", to capture this shared understanding in a concise documentary form. Formalising arrangements such as these helps ensure the community has a life of its own - independent of any one individual - that can survive and flourish for as long as there is a genuine sustained need for the software in question.
Building a community around a piece of open source software can be slow, hard work and success is contingent on many things. Nevertheless, without a community, there simply is no project. Community building does not happen automatically and has to be carefully managed. All communities start with users, attracted by the software's packaging and branding, or word-of-mouth recommendations. Once they arrive, however, the challenge then is living up to these high expectations. A thriving developer community can meet and exceed these expectations, but only if their leader can keep it together and ensure participants do not go off on their own. In the long run, communities need to have open development mechanisms in place to allow roles to be replenished as members, including their founders, move on.
It is licensed under the
Creative Commons Attribution-ShareAlike 2.0 England & Wales licence.
OSS Watch is funded by the Joint Information Systems Committee.