Safe as Milk

Community management

September 15, 2008 5:54 pm Dave Neary community, freesoftware, maemo, work

On Thursday I’ll be participating in a panel at OSIM World – “Effectively Building and Maintaining an Open Source Community”. It was a happy coincidence when I saw Matt Asay writing about the issue on Friday, and again today – it gives me a chance to think a bit more about the issues involved, and provides a data point which is very close to the experience that I have repeatedly seen when companies decide to use free software, be it peripherally or strategically.

On several occasions I have seen a lone developer decide to use a free software library to do some job for him. It doesn’t quite fit his needs, but he hacks up the extra feature or two in a couple of days, finds a few bugs that he fixes along the way to make things work as he needs them to, and ships it to a client as part of a larger solution.

At this point, one of two things will happen. The external project either stays as-is in the SCM of the company, awaiting a future upgrade request from the client, or the developer (usually because he is “the Linux guy” in the company and knows about these things) bundles up a couple of patches, heads along to the bug database for the project, signs up for Yet Another Bugzilla Account, and creates three or four bug entries with bug fixes attached, and another one for the new feature he hacked up. All told, he spends maybe half a day cooking up patches, navigating account creation, and submitting his work.

Usually, the patches will sit there for weeks or months before being reviewed. In most projects, if you don’t go onto a mailing list or IRC channel and ask the right guy to take the time to look at them, you can expect to wait. He has a backlog, gets lots of bugzilla nag mail already, and anyway, he’s working on a new feature he wants to get done this weekend between playing with the kids and doing the grocery shopping.

When they do get reviewed, the code base is likely to have shifted, so the patches don’t apply cleanly. Perhaps they don’t conform accurately to the coding conventions of the project. The feature, while useful, was done quickly (since it was only a minor part of a larger project), wasn’t accompanied by unit tests, and has a couple of issues that need resolving.

Of the four or five bug reports that our hacker created, one gets marked INVALID, another one is a DUPLICATE, and one patch gets applied and the bug fixed. The feature request status gets set to NEEDINFO, since there are some open issues to be addressed, but our hacker is now 6 months away from the code, 3 projects down the line, and has less time to write unit tests, review and resubmit the code.

Maybe he’ll do it anyway – and maybe he won’t.

In fact, I would say that the vast majority of the features people code up for free software projects  never make it into an upstream bugzilla – developers are perfectly happy shipping a 10 year old version of GNU Kermit with hairy patches sticking out all over the place. And of those patches that do make it into an email or bugzilla, a small percentage ever make it into the upstream code base.

I would argue that when a project is strategic to a company product (as Lucene is to Alfresco), then the company has every interest in having someone who is regularly contributing to the project, who knows the key people in the community, and who is a trusted member of the community themselves. This ensures that your code is getting the care and attention it deserves when submitted upstream, and helps contribute to reducing your maintenance cost long run (as well as giving you influence over a project you depend on).

All this is to say that reducing the argument to “throw code over wall bad, participate good” is slightly over-simplifying – in the case where the project is a core part of your business, I agree wholeheartedly. If you’re using free software libraries as product, and merely tweaking to your needs, then the cost of participating outweighs the benefits in most cases. Reducing that cost by lowering the barrier of entry to participating is key to developing a vibrant community. But increased availability and a very low barrier to entry also incurs a cost on the community. Like most community-related issues, the balancing act is not an easy one to get right.