OSS Watch workshop – Engaging developers with open source projects

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.

Contributing to an open source project

OSS Watch spends a lot of effort actively promoting the practice of open development as an effective means of achieving project sustainability. There are also important benefits for users who are developing tools based on an open source project and today I came across a great example that illustrates how to engage with the community and reap the rewards.Mark Johnson is employed by Tony Whitmore at Taunton’s college to develop their Moodle VLE. What makes his work particularly interesting in terms of open development is that where appropriate he works directly with the Moodle community. He has now had his first patch accepted into the main Moodle code and so congratulations are in order.The issue was a small accessibility problem and you can can follow the process on the Moodle ticket. The main points that I want to emphasise as being  important for similar community interactions are:-

  • Once the problem was found Mark investigated it and when he could reproduce it and describe it he raised a ticket to alert the community of the issue.
  • A discussion followed with a possible problem being suggested by the Moodle developer who picked up the ticket (Tim Hunt). This was followed by a request for either more information or further investigation.
  • Mark then tried harder to track down the problem, keeping Tim updated, until he eventually located the source. He then created a solution. Note Mark was not an expert on the code in question but developed an improved understanding through digging deeper. In general the community will provide any help you need to do this.
  • Mark then submitted a patch allowing Tim to see his solution and review it.
  • Tim graciously confirmed the error and accepted Mark’s patch into the Moodle code. It will appear in Moodle 2.0.

An alternative scenario is that Mark simply made a local fix to their Moodle code. Doing that would miss out on the opportunity to engage with and learn from the development community. Worse that fix would have to be reapplied each time a new Moodle release is installed, something that could involve costly merging of changes.However the actual result is that Mark now has better understanding of the code, Moodle has bug fix and both parties have a positive interaction to look back on and that will hopefully encourage further work together. Mark also has a good standing with the Moodle community, something of benefit to him personally as well as his employers.This small bug and subsequent resolution neatly illustrates how to engage as a user with the community and some of the key benefits of practising open development. No bug is too small to bring to the attention of the community. Perhaps you have an outstanding bug you could submit right now?

JISC Funding Call: Access & Identity Management

The Joint information Systems Comittee (JISC) in the UK have issued a new call for funding proposals titled “Access and Identity Management“. As with most JISC calls, proposals must come from UK educational institutions although other organisations can partner with appropriate institutions. Finding partners is one of the services OSS Watch offers as part of our bid writing consultation service (free to UK academic institutions).

As with all JISC calls, bidders are expected to consult with OSS Watch in order to understand how the JISC open source policy and the open development approach to project sustainability apply to their project (see paragraph 57 of the call details).

We look forward to helping you write your bids.

Open development and the art of community

The first chapter of Jono Bacon’s long awaited ‘The Art of Community’, to be published by O’Reilly later this year, is available for preview. So far the reviewers’ comments have been enthusiastic. I’m not surprised. I have followed Jono’s blog posts for some time and enjoyed most of them. His vast experience as a Community Manager at Ubuntu, combined with an alert and imaginative writing style, makes him one of the most insightful authors writing about the social aspects of open source collaboration.

The first chapter introduces the main themes of the book – collaboration, belonging, trust, social capital, communication – and this is done in an engaging combination of theoretical vignettes and personal accounts drawing on the author’s early experiments with open source. There are a couple of extremely well made points in this chapter, but in particular the importance of fostering a sense of belonging in the process of building an online community grabbed my attention.

Writes Jono:

In the same way that we judge a strong financial economy by prosperity, wealth, and a quality standard of living, belonging is the reward of a strong social economy. An economy is a set of shared concepts and processes that grow and change in an effort to generate a form of capital. In a financial economy, participants put goods and services on the market to generate financial capital. The processes and techniques they use include measuring sales, strategic marketing, enabling ease of access, and so forth. A social economy is the same thing—but we are the product, and the capital is respect and trust. The processes and techniques here are different—open communications mediums, easy access to tools, etc. — but the basic principles are the same.

Building social capital by welcoming new members and helping them develop a sense of being part of the community is a crucial aspect of making it sustainable. This was the subject of an OSS Watch Community and Open Source Development Workshop last year, and Ross alluded to it in an earlier post on software sustainability:

Now that OSS Watch have started to show that closed communities are not required, the next step is to encourage people to develop their software in such a way as to ensure non-community members are empowered to participate. It is these third party contributions that spread the cost of development across multiple financial pots and thus reduces centralized risk. We recognize that policy is all very well but it is practice that matters. The adoption of open development practice requires a significant cultural change, but this is a change that our research shows is desired by enough practitioners to make it viable.

I’m looking forward to reading the rest of Jono’s book. I’m particularly keen to see if he has anything to say about matching personal and institutional drivers in making the cultural change associated with adopting open source effective.