How to build an open source community

by Matthew Mascord on 4 January 2008 , last updated

Introduction

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.

Why do open source projects begin?

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 whilst in the latter case, there is the specific intention of sharing the software.

What is a community and why do open source projects want to build them?

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 reward-earning contributions that can be made by community 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 exists 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.

Typical paths for open source communities

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 that works 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’. It should be noted that ‘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 by early releases 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 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. All this is a lot of work. And of course, 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 Github, Google Code, and StackExchange. 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.

Steering clear of the pitfalls

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 of a sufficient quality.

It’s important that an established project continues to serve the needs of its members. If this ceases to be the case, those who feel theit interests aren’t being served by the project may decide to take a copy of the codebase and continue developing under their own governance. This process is known as forking. It’s important to note that forking isn’t necessarily a bad thing, it may simply be that a section of your community have a specific set of needs that they dont feel can be balanced with the needs of the broader community. There may also be a situation where the established governance model no longer serves the best interests of the project, so the community decide to continue development under a new project with a new governance structure. However, forks that result from clashes of personalities or because of simple disagreements should be avoided as they can divide communities and cause confusion for users. To avoid such forks, the project’s leaders should work to ensure that all contibutors feel enfranchised by the decision making process, even when decisions do not go their way.

When is a fork not a fork?

With the rise of distributed version control systems, and particularly through hosting sites such as GitHub, the term fork has taken on a new meaning, where an individual developer takes their own copy of a published codebase, making changes to suit their needs, and often submitting the changes back to the original code (known as a pull or a merge). This differs significantly from the type of forking described above, where it’s the community around the project that is split, not simply the code.

Letting go

In order to be considered healthy, open source communities must have the capacity to outlive their founder’s original interest in them If they rely heavily on a dictator, they risk fragmenting and falling apart when their leaders move on or retire.

In most communities, even those governed by dictatorships, people other than the founder will increasingly become responsible for making key decisions. The natural outcome of this is a move towards consensus-based democracy. This new arrangement does not imply that all decisions, however minor, are made by committee. Most of the time proposals are decided on the basis of ‘lazy consensus’ where ‘silence gives assent’. To deal with proposals that don’t reach consensus most communities institue some form of voting.

The more complicated these habits and procedures become, the more important it becomes 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 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 project’s outputs.

Conclusion

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 ensure that when key contributors, including the founders, move on, their roles are adopted by others.

Further reading

Links:

Related information from OSS Watch: