OSS Watch team blog

How do you get people to work on your code without them knowing it?

At OSS Watch we are building an RDF based project catalogue, called Simal, the initial work was based on some work I did, with David Reid, over at Apache for their project catalogue. My contributions to this work built on Apache Forrest, although the Apache projects site eventually opted to use a perl based transformation system so we now only share XSL stylesheets.

As part of the Simal project I have had to make significant improvements to Forrest, of course all this work has been donated back to Forrest and is now available to other Forrest users. But this post is not about the outward benefit, it is about the inward benefit Simal has from engagement with open communities.

Much of this improvement work has been to add plugin support for a new alpha feature in Forrest called the dispatcher. The dispatcher has been around in Forrest for some time and is just now starting to realise its full potential. Simal uses dispatcher in ways it has never been used before, for example, it has Simal now includes features such as an Ajax browser based on Exhibit from MIT and an RSS feed reader using the Google AJAX Feed API.

Because most of these projects (Google AJAX Feed API excepted) are open source I’ve been able to produce a reasonably functional catalogue in very little active developer time, OSS Watch is devoting a mere half a day a week to this project.

But what happens when you hit a bug in another projects code? Simple, fix it and apply a patch. But what if you can’t fix it, what if your knowledge of the project is insufficient?

Well that is exactly what happened recently. I hit a weird bug that prevented my Ajax features from working correctly in certain circumstances. I was lost, I did not know what the problem was, or even where to start looking. After narrowing down the problem as tightly as I could I posted a mail to the Forrest dev list asking for pointers. I tried to describe the problem in as much detail as I could. Around 45 minutes later Thorsten Scherler announced he was going to take a look at it for me.

Here we see the true benefit of an open, community led project. Others are willing to help, often with pointers and ideas, sometimes with actual development effort.

Why did Thorsten want to expend his energy on my problem? I can only guess at his personal reasons, but my first guess would be that because he is the original author of the majority of the dispatcher code and he recognises that I am a power user of his code, he considers me a valuable user. By supporting me, he will ensure that I continue to work with his code, to help identify and iron out bugs and to continue to enhance it when I hit its limits.

Furthermore, and most importantly, by telling me what the problem is and trusting me to review his commits in working on the problem I will learn about how the deep innards of the dispatcher work. This then means that in the future I can assist other users who hit problems with it. More satisfied users means a more sustainable project.
Around one hour later he reported that he had reproduced the problem and identified two potential locations where it may be routed. One was code I am not familiar with, the other was in code I know well. Since this news came at the end of the day I decided not to debug, but to go to bed.

The next day I found another community member had made a suggestion that would help narrow the problem, so now there were three people working on it. I debugged the code I knew and found it was not the source of the problem. Since I was due to go on holiday I notified the community of my findings and went off to enjoy a long sunny weekend in a field listening to music.

When I returned Thorsten had committed what he thought was a fix. Fantastic, people solving my problems while I’m on holiday. People, that is, who are not in my team and are not directly related to Simal.

Unfortunately, the bug was still present, but Thorsten had indicated the area he thought the problem was in his patch. This information enabled me to perform further debugging work. Whilst I didn’t get to the root of the problem I was able to define and document a workaround in the Forrest issue tracker. Now following users can work around the problem until a fix is put in place.

I suspect the information in our discussions and the provision of my workaround will be enough for Thorsten to find the real cause of the problem and so the next release of Forrest will have one bug less.

This is an example of community development at its best. My thanks go out to all the wonderfully talented people working on Simal, even though most of them don’t even know they are contributing. At a rough count there are about fifteen of them, not a bad return on an investment of half a day week.