Event report: OSS Watch workshop: Engaging developers with Open Source projects

Oct 17, 2009 by michelle-pauli

Are open source software developers really pussycats? That was the intriguing proposition offered by OSS Watch‘s Ross Gardler at the start of this workshop on engaging developers with open source projects.

Open source communities have a reputation for being filled with tigers ready to devour any naïve developer foolhardy enough to enter their territory. This workshop sought to dispel that myth and provide concrete advice to help developers overcome their fears and feel more confident about contributing their code modifications and customisations back into the community. The participants in the workshop, who came from a range of higher education institutions, were also offered compelling reasons why they should contribute to as well as use open source software, with benefits for the developers themselves, their managers, institutions, end users, and the open source coding community as a whole.

Michelle Pauli reports back from the event.

It all starts with a line of code

The workshop’s three key speakers provided perspectives from across the open source community spectrum, from an established Apache contributor to a young developer who had recently contributed his first line of code (and lived to tell the tale). All offered encouragement and positive stories from the open source frontline.

Scott Wilson is assistant director of CETIS, the JISC’s innovation support centre for interoperability and standards in the UK higher and further education sectors. His team at the University of Bolton has developed the Wookie widget server, an engine that provides support for W3C widgets and related technologies (such as Google Wave Gadgets) in a way that can be easily integrated into other applications, including Moodle, LAMS, WordPress, and Elgg. It has recently been accepted into the Apache incubator, part of the Apache Software Foundation. Scott explained that the decision to take the project down this route was partly for sustainability reasons. “Code is easy but managing stuff is hard,” he said. “We wanted to be clear how people could get involved and on what basis. Foundations sort this difficult governance stuff out – there are mechanisms to support community and clear processes around things like licensing that are already trusted by developers.”

Scott described the ‘ladder’ of involvement in the Wookie community – users; chatty users; contributers; committers – and explained that he sees his role as helping people to move up the ladder to contributing. He does this through encouragement, feedback, help, advice, documentation, evangelising and marketing. His major task is helping developers overcome barriers to contributing. This includes documenting and explaining the processes and actively reaching out to developers, especially where they might be reluctant to tackle IP and licensing issues, have a lack of understanding of workflows, or need to convince managers that the commitment will not take up vast swathes of their time.

From the project’s point of view this time spent encouraging contributions is worth it, said Scott, because external contributions help fix bugs, add features and identify user requirements. In addition, the more people involved, the greater the likelihood of a diversity of markets where the software can be applied and opportunities for new partnership.

The notion that community can be more important than code was explored further by Dr Ian Boston, chief technology officer for Caret at the University of Cambridge, chief architect for the Sakai Foundation, and a PMC member at Apache Sling and Apache Shindig. Ian became involved with Apache communities through his work with Sakai, a free and open source virtual learning and virtual research environment.

Ian described the learning curve Sakai developers have undergone since the first version of Sakai, in 2004, when they wrote “too much code” – 1.8m lines. This has implications for sustainability as each line of code generates a commitment. For version two, his team decided to write less and keep it simple: “in most cases someone else has probably already written what you need and by engaging with open source and looking for those libraries you can save yourself an inordinate amount of time,” he pointed out. “It is not so much the code itself as about having a good community around that code so if a bug comes up in three years time then can you get a fix?” Great code often equals bad community whereas bad code equals great community, he added, as it gives people lots of opportunities to get involved and fix things.

That was exactly what Mark Johnson did when he discovered a bug in the virtual learning environment Moodle. Mark is a recent web design and internet technology graduate currently working as an in-house web developer for Taunton’s college in Southampton. He’s interested in accessibility and usability so he created a text resizing and colour changing block for his college’s Moodle to ensure that all the users could see the website. It worked fine but, when he started porting his in-house code ready for the release of Moodle 2, he hit a problem with the stylesheet. He first assumed that the mistake was his – “you tend to trust the system more than you trust yourself when you’re new” – so he posted the problem up on the Moodle community forums asking for help. Within a day he had a response from a core developer saying that it sounded like a bug and that he should file an issue in the code tracker, which he did. However, Mark then went a step further: having uploaded his code, and had the potential bug pointed out to him, he went ahead and fixed it and submitted his patch with the fix.

The positive response to Mark’s patch amazed him. After thanks and congratulations from the community, he’s left with a “warm and fuzzy  feeling”, his institution has easier-to-maintain code in its system, and the Moodle community as a whole has gained a fix and a new, enthusiastic contributor (Mark has since submitted another patch and is about to start work on a debugging system).

Getting involved:  the rules of engagement

So how can other developers who are new to open source communities follow Mark’s example?

The most fundamental piece of advice offered by the speakers is reassuringly simple: be nice. As Scott put it: “being nice is a survival strategy in open source software”.

Lurk for a while in your chosen community to see how they operate, but don’t lurk for too long – most are extremely friendly and if not you’ve found the wrong community. In your first message say that you are a newbie and ask how to do something. Ask stupid questions and lots of them (but check first in case somebody else has asked the same question before) and then listen to the replies. Read and understand and be inclusive. Check that you have permission from the copyright holder (your employer) if need be, then patch and bug fix. Ian suggested that the best first patch to Linux Kernal was fixing a spelling mistake. It’s really appreciated and easy to apply. Be clear and concise when you respond to emails (“think of the committer if you are planning to write three pages rather than a line,” Ian pleaded) and take the time to read their email first, understand it and respond in a thoughtful way.

As you get more involved in the community, explain, educate, help, support others, joke, and show humility. “Don’t go in and say I wouldn’t do it like that because it’s ugly and stupid,” Ian advised, “but suggest a new way of doing it and ask if you should go and find out more.”

Finally, learn to move on. If you want to engage with a community then you will inevitably have arguments and disagree with others but the key is to agree to disagree and then move on.

Getting involved:  the rewards of engagement

The benefits of community engagement were emphasised again and again. From the developer’s perspective, the ‘feel good factor’ of contributing and having your contribution recognised by a peer group whose opinion you value can be highly motivating. As Mark pointed out, this is especially important for developers who are working without the support of a larger team.

He is the only developer on staff at his sixth form college and he explained: “I might write fantastic code but no one else in my college will understand what I’ve done. By releasing it to the community I get the kind of validation I would never get in my job. It makes me more motivated to do more and release more in the community.”

There are also opportunities to learn new skills. Scott mentioned that he is often surprised that external developers are not familiar with the tracker-based workflows and distributed development that are essential elements of community coding. “Once introduced to these core skills they often find that they are using them all the time,” he added.

Mark again: “Peer-reviewed code is better quality code. As the only developer in my institution nobody else is going to look at my code and offer suggestions for improvement but through the community I get that.”

For managers, having developers involved in this way raises the profile of the institution. It also adds value to the software – for free – and makes it much easier for the institution to migrate later on if, instead of having locally stored code that have to be manually updated, the code has been contributed back and is part of the central system. Using open source libraries also saves time and avoids duplication of effort and in the current economic climate that makes good financial sense.

For the community, engaged external developers stops project code becoming “a decaying pile of mess” as Scott puts it, and provides valuable code, information on user requirements and a diversity of markets.

Transforming tigers into pussycats

So were the participants in the workshop convinced? A selection of feedback given in response to the question “what will you take away from this workshop?” suggests so:

“I never considered open sourcing work before but now I have the how and the why and a business case for doing this and makes it more realistic and, in some cases, appropriate for our projects.”

“The main takeaway message for me is that some of the stuff that I’ve been doing in spare time should be pushed back into the open source community. They may shout at me but I won’t know until I try.”

“In the past I’ve been guilty of fixing bugs and not returning them to the community and I will change that.”

“I’ve learned how to join in the open source community rather than just using it.”

“Getting involved in an open source project is not as frightening as it first appears and I might give it a go”

To find out more about getting involved in open source communities…

OSS Watch has a guide to participating in an open source software community
and more can be found on their Communities link page

The  October OSS Watch Newsletter includes an article on “How to build an open source community” (pdf)

Scott’s slides
Ian’s slides (pdf)
Mark’s  slides