Update 2: I should point out that the subject of this post has been resolved. I’ll mark it down to a misunderstanding. The patches I submitted were accepted several days after being sent and rejected, once the purpose of the patch was clarified with the developers. I will leave the rest of the post here, for posterity sake, and because I think that there is some merit to the points I made, even if they were misguided in their target.
Today is going to be a very blog-ful day. I just seem to have a lot to rant about. I’ll be blaming it on the spider and a lack of sleep.
One of the things that thrills me about Open Source software is the ability for anyone to make contributions (above and beyond the ability to share and understand the source code) – and I was ecstatic when I discovered the java based Picard project, an open source set of libraries for working with SAM/BAM files. I’ve been slowly reading through the code, as I’d like to use it in my project for reading/writing SAM format files – which nearly all of the aligners available are moving towards.
One of those wonderful tools that I use for my own development is called Enerjy. It’s an Eclipse plug-in designed to help you write better java code by making suggestions about things that can be improved. A lot of it’s suggestions are simple: re-order imports to make them alphabetical (and more readable), fill in missing javadoc flags, etc. They’re not key pieces, but they are important to maintain your code’s good health. It does also point the way to things that will likely cause bugs as well (such as doing string comparisons with the “==” operator).
While reading through the Picard libraries and code, Enerjy threw more than 1600 warnings. It’s not in bad shape, but it’s got a lot of little “problems” that could easily be fixed. Mainly a lot of missing javadoc, un-cast generic types, arrays being passed between classes and the like. As part of my efforts to read through and understand the code, which I want to do before using it, I figured I’d fix these details. As I ramped up into the more complex warnings, I wanted to start small while still making a contribution. Open source at it’s best, right?
The sad part of the tale is that open source only works when the community’s contributions are welcome. Apparently, with Picard, code cleaning and maintenance isn’t. My first set of patches (dealing mainly with the trivial warnings) were rejected. With that reception, I’m not going to waste my time submitting the second set of changes I made. That’s kind of sad, in my opinion. I expressly told them that these patches were just a small start and that I’d begin making larger code contributions as my familiarity with the code improves – and at this rate, my familiarity with the code is definitely not going to mature as quickly, since I have much less motivation to clean up their warnings if they themselves aren’t interested in fixing them.
At any rate, perhaps I should have known. Open source in science usually means people have agendas about what they’d like to accomplish with the software – and including contributions may mean including someone on a publication downstream if and when it does become published. I don’t know if that was the case here: it was well within the project leader’s rights to reject my patches on any grounds they like, but I can’t say it makes me happy. I still don’t enjoy staring at 1600+ warnings every time I open Eclipse.
The only lesson I take away from this is that next time I see “Open Source” software, I’ll remember that just because it’s open source, it doesn’t mean all contributions are welcome – I should have confirmed with the developers before touching the code that they are open to small changes, and not just bug fixes. In the future, I suppose I’ll be tempering my excitement for open source science software projects.
update: A friend of mine pointed me to a link that’s highly related. Anyone with an open source project (or interested in getting started in one) should check out this blog post titled Teaching people to fish.