Engaging developers workshop, Oxford, 9 October 2009

by Elizabeth Tatham on 12 January 2010 , last updated 24 August 2012

Introduction

Why should software developers who create local customisations of open source software take the further step of submitting their changes back to the main project? Where do people who make contributions fit in to an existing open source project, and why do projects want them? These are some of the questions addressed by a recent OSS Watch worskhop I attended, which set out to present the issue from both sides: that of the open source projects that look to encourage contributions, and that of the external developers who might want to make them. Personally, as a newcomer to open source, I hoped the workshop would provide an answer to a question that intrigued me: what motivates people to get involved in open source projects?

The workshop, entitled Engaging Developers with Open Source Projects, was held at the Oxford University Computing Services (OUCS) offices in Oxford on 9 October 2009. Attendees, most of whom, according to a show of hands, were also new to open source, came from various UK higher education (HE) and further education (FE) institutions. We were welcomed by Ross Gardler, service manager at OSS Watch. Following a brief introduction to OSS Watch, he set us the challenge of drawing the person next to us in 15 seconds. This both broke the ice and vividly made the point that it can be embarrassing to share your creations. Moving out of your comfort zone - whether you are drawing a stranger or contributing to a project - is scary. But this can be easier to do, Ross suggested, if you remember that most people are actually pussycats, not tigers, when you get to know them.

Drawing on his own experience as an Apache contributor, Ross rounded off his introduction by encouraging developers not to spend years ‘lurking’ on project mailing lists, as he had done, but to take the plunge and make that first contribution, even if that contribution is to ask a meaningful question. This workshop was to look at the benefits - for projects, communities and individuals - of overcoming the fear of contributing.

The life of a Wookie

The first speaker was Scott Wilson. He is assistant director of CETIS, a JISC Innovation Support Centre providing advice to the UK HE and FE sectors, at the University of Bolton. He talked about the Wookie project, which creates open source software for adding widgets to applications, and has recently been accepted as an incubator project at The Apache Software Foundation (ASF).

Scott began by describing various community models. These ranged from no community, to ‘geek high priesthood’ (open source but closed community), to lots of developers but no users, to lots of users but no developers, and finally, to both users and developers.

He then talked us through the composition of the Wookie community:

those interested in using Wookie
those already using Wookie
those developing but not contributing back
those submitting bug reports and contributing to the mailing list
those submitting patches
project committers

Scott sees it as his job to make sure that there is a steady supply of people moving up this ladder of involvement, focusing on stage 3: those developing but not contributing back.

What are the barriers to contribution? Some might be put off by the fact that licence agreements are complex and hard to understand; others are deterred by a lack of clarity on processes; and managers might be concerned about the level of commitment required. Most surprisingly, many developers are not yet familiar with tracker-based workflows and distributed development - skills that help developers understand the way in which open source projects operate and lower the barrier for open source contribution. In fact these tools and processes are also used in many closed source development projects, therefore these are skills sought by all software teams.

How might these obstacles be overcome and contribution encouraged? For the project’s part, it is essential to document and explain processes, provide feedback, help and advice, and to actively reach out to developers. Developers, in turn, need to extend their understanding of tracker-based workflows and distributed development. And being nice is an important survival strategy in open source, while flexibility also brings its rewards.

External contributions can benefit all concerned. For the project, external contributors provide valuable work, like fixing bugs, adding features and identifying user requirements. Through diversity of community, more markets are accessible, and the process forges links, and therefore opportunities, for the organisation. For the individual, getting involved can have many benefits, including the development of professional and social skills.

Questions followed. For me, the most interesting was what would happen when key people wanted to leave the project. Would there be a moral obligation for the project to continue? Scott replied that the diversity of community resulting from the involvement of more organisations reduces the problem, and Apache has a diversity condition for entering the incubator for that very reason.

How the Sakai project engages with open source communities

The second presentation was given by Dr Ian Boston, Chief Technology Officer for Caret at the University of Cambridge and chief architect for the Sakai Foundation. He kicked off with an overview of Sakai, an open source collaboration and learning environment used globally in 161 HE institutions, with 100,000-200,000 users and 50-60 committers. Begun in 2004, Sakai now comprises 1.8 million lines of code, and Sakai 3 development is underway.

Looking back, Ian described the lessons learned during Sakai’s lifetime: it is essential to have community around code to sustain it in the future; someone has probably written a better implementation already, so don’t reinvent the wheel; and code is not the only thing that matters. Expanding on this last point, he suggested that great code equals bad community and bad code equals great community: if you have less than perfect code, you are more likely to attract a community than if you have perfect code to start with, so getting the code out early is important.

Getting involved in an open source project is a three-stage process: engage, contribute, influence. Ian’s advice to would-be contributors is to read and understand before responding, ask ‘stupid’ questions (but search the FAQ archive for answers before doing so), listen, and supply patches and bug fixes. He suggested ‘lurking’ on the mailing list for a while to get a feel for things, before making that first contact (‘Hi, I’m a newbie. I can’t find documentation to tell me how to …’), and submitting that first patch, which could be something as simple as fixing a spelling mistake. Ian also provided insight into ‘committer pain’, useful for aspiring contributors to bear in mind: keep it brief - nobody has time to read pages and pages of text; and don’t expect anyone else to take responsibility for your patch. For the process to succeed, the development of trust is essential, he added.

The line of code that could: contributing to Moodle

How exactly does a would-be contributor set about taking that first step? Here, to share his experience, first hand, was the final speaker of the day, Mark Johnson, in-house web developer at Taunton’s College, Southampton. Mark recently had his first patch accepted by Moodle, the virtual learning environment (VLE) used by his sixth-form institution. With infectious enthusiasm, he described how he made his contribution, and urged his fellow developers to do the same.

Mark set the scene by explaining that in his role as web developer, he had developed an accessibility tool for changing text size. But when he started porting changes to Moodle 2, his accessibility tool exposed a bug in Moodle. After checking that he hadn’t made a mistake, he posted to the Moodle community forum. A core developer responded, asking him to create an issue on the project’s bug tracker. He was familiar with trackers, and did so. After a few questions, he uploaded the code and the developer made more suggestions for Mark to investigate. He duly investigated, and discovered the problem. He then uploaded a patch.

Mark has benefited both personally and professionally from contributing to a project. Not only did he feel ‘warm and fuzzy’ after being congratulated by his peers and offered an OSS Watch guest blog post, but the experience has also ‘got his name out there’. And he has begun to build the merit that will in time qualify him to help shape a project. In addition, by joining a community he has received positive feedback from other developers, and his code has been peer-reviewed. This would not normally happen in his organisation as he is the only developer, and means better quality code and added value to the software. And the entire experience has motivated him to make further contributions.

Rounding off his presentation, Mark recommended the following steps to making a contribution:

check the licence terms
get permission from the copyright holder (your employer)
identify some suitable code you’ve written
post on the project’s forum or mailing list
bring the code up to scratch with the project’s guidelines
release

He added this advice: politeness has always resulted in a friendly response, so don’t be afraid.

Mark had further opportunity to give advice during question time, when he was asked how to ensure that your patches are seen. He suggested the direct approach: find out who it has been assigned to and ask them via the appropriate channels. Another questioner wanted to know if he’d become more involved in Moodle after that first patch. He replied that he has submitted another and is now working on an internal feature, perfectly illustrating what making that first contribution can lead to.

Panel discussion

Ross introduced this session with another activity: turn a page of circles into pictures of sport and leisure activities. Bicycle wheels? Goggles? After sharing some of our drawings, we tried again, and produced many more pictures this time. This illustrated that we learn from sharing ideas and that ideas from different perspectives, even without quality control, along with openness, transparency and constructivism, all add value. This is what we see in a viable open source project. Ideas are shared, reviewed and improved. The initial incomplete ideas are fleshed out with input from a wider community, thus providing inspiration and quality control.

We then moved on to the panel discussion, led by Ross and featuring all the presenters. Ross asked the speakers if they could have achieved as much without engagement with the wider open source community. Ian confirmed that community was essential in the case of Sakai, simply because of the volume of code, which would have been impossible to maintain without the support of the community. The main challenge for software projects in the academic environment, he added, is not to produce perfect code meeting closely defined requirements, but rather to learn how to adapt and reuse components developed and maintained by existing communities. For Mark, support from the Moodle community was crucial, both psychologically and technically. Without it, the accessibility tool he had developed would not have become functional within the VLE, and had he not been encouraged to create the patch by a more senior developer, he wouldn’t have dared to do it. The discussion continued on the VLE theme for a while, with a participant mentioning that the availability of direct support via the community was an important factor in his institution’s migration from Blackboard to Moodle. Others agreed that community support was essential in their decision to switch to Moodle, as they had realised the inefficiency of so-called honey-trap communities built around other proprietary VLE systems.

This was followed by an interesting discussion on the issue of funding, prompted by a question from Ross: what is the single most important trigger that would accelerate the change to an open source culture in higher education? In Ian’s opinion, the funding model needs to change, which needs to come from government. Scott made the point that money needs to come from sources other than those currently funding academic projects. Continuing on the topic of funding, someone asked whether, as a matter of principle, publicly funded projects should produce publicly available code. Ian replied that yes, the project should be sustainable if publicly funded, so that the deliverables are available for further public use, either directly or through derivation. Mark Johnson’s view was that if the public has paid for it, they should own it. If not, it should be open source so that people can do what they like with it. Scott felt that the project should not be required to be sustainable if this doesn’t make sense for that particular project, and Ross concurred. Lively discussion continued until it was time to wind down and retire to a local pub for more informal discussion.

Conclusion

In closing, Ross asked delegates what they would take away from the workshop. One theme that emerged was that the workshop had made contributing to a project seem achievable, explaining how to move from being a user to actually joining in with the community. One attendee had seen that open source projects are actually keen to have people get involved and are generally nice. Another had realised that you are not alone as a developer, and that many face the same issues. A couple of others said they now felt inspired to return their fixes to the community. In short: getting involved is not so frightening.

And what would I take away from the workshop? I had undoubtedly gained insight into how open source ticks and now understood how rewarding contributing can be. I even found myself idly wondering if I might one day be able to contribute to a project, inspired, in no small part, by the story of the line of code that could - and the developer that did.

OSS Watch provides unbiased advice and guidance on the use, development, and licensing of free software, open source software, and open source hardware.