OSS Watch team blog

Keeping a low barrier to entry for external contributors is particularly important in an open source project. New developers might emerge from the project’s user base, but may also come from elsewhere, drawn in by the technical challenge, kudos, or opportunity to improve or publicize their programming skills.

Often the amount of disruption generated by these developers contributing ‘from the wild’ is feared by projects with little practice in open source development.

Karl Fogel writes in Producing Open Source Software:

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.

Moreover, once new contributors have been attracted to the project, they have to be given as many reasons to stay on a possible. Ensuring that their contribution is valued and rewarded is important to their successful integration in the community, and crucial to maximising the project’s sustainability. As mentioned in an OSS Watch community building document:

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 who want it, responsibility for more significant pieces of work.

David Neary pointed in an earlier Gnome blog post at a number of interesting governance success stories from online communities including Blender, Inkscape, Drizzle, Subversion and Maemo. A recurring point in these stories was the issue of making the community grow by smoothing the entry path to new contributors.

In one of these governance stories an external contributor submits a software patch to Inkscape, an open source SVG graphics editor. The commiters responsible with that feature check the code and license and accept the patch. Bryce Harrington, the Inkscape developer who tells the story, goes on:

Following our policy to “Patch first, ask questions later”, we integrated the new feature as soon as practical, without wasting time arguing about it on a mailing list. We figure that the best way to evaluate an idea is to code it up and see how it works in practice. A working feature now is better than a perfect implementation that still isn’t done.

And further down:

… maintaining a low barrier to entry for new developers is vital; we don’t want anyone to give up on contributing out of fear their contributions won’t be accepted.

A noteworthy document in this respect is David Neary’s check list of community barriers to entry. Online communities, David writes, fail to reach a critical mass because potential new members trying to engage with the project encounter some form of difficulty that takes too much effort from their part to overcome. One of the main tasks of the community manager is to identify and iron out these hurdles as much and as early as possible.

A new contributor is likely to encounter three types of obstacles, David thinks: 1. Technical (related to product architecture, programming language, tools, documentation, website); 2. Social (related to project infrastructure, governance model, behavioural norms in the community, relationship between employees and community, transparency of community processes, corporate hierarchy, product plans, management of confidentiality); and 3. Legal (related to licensing issues trademarks, patents).

I personally am of the opinion that it is the social barriers, rather than the technical ones, as David believes, that are the most significant and the most critical to resolve. Nevertheless, his check list largely resonates with OSS Watch’s view about the importance of encouraging external participation for the sustainability of the project, as mentioned in this governance model document:

Since it is not possible for a project to be all things to all people, the goal of a sustainable project is to be as complete a solution as it can be for its core stakeholders, whilst still being of interest to other interested parties. The project must be ready to accept input from unexpected quarters, and must be able, wherever possible, to accommodate their needs. Doing so significantly increases the pool of resources the project can draw upon in its quest for sustainability.

To further address these crucial aspects of community building OSS Watch is organizing a workshop on “Engaging developers with open source projects” on 9 October in Oxford, where open source developers who have been directly involved in HE academic projects will talk about their experiences. We hope to see some of you there.