Contributing to Open Source

When I first encountered open source years ago the idea of contributing really excited me. Unfortunately, I found little success in my attempts to help out. I have always wondered why that was, and now I think I know. I first ran into Biopython when I started working in the Botany Department at U of T. Perl is the language of (no) choice for bioinformatic projects simply because the BioPerl modules are so mature. Perl had always left a bad taste in my mouth though, so I found myself looking for alternatives. When I investigated Python, I found a Biopython project had already started and was playing catch up to BioPerl. The problem was of course that Biopython was still quite a bit behind its older brother. I decided to bite the bullet and use it in my work anyway. As time progressed, I realized that I was often circumventing Biopython due to its incompleteness. In one case, I found the Biopython architecture for calling external applications essentially unusable. The problem being that there was no way to find out the applications return code. I ended up calling the application myself, and then tricking Biopython into using the data as if I had used the framework. Eventually I began to think my solution was unmaintainable and set out to fix the problem in Biopython. Turns out the solution was actually a lot simpler than I thought and a heck of a lot easier than maintaining my current hack. A few posts to the Biopython list later, and my 10 line patch to provide this functionality had been entered into CVS. What was most interesting to me about the process is that it was so easy. My previous attempts to contribute to open source generally ended with me reading Slashdot. No doubt this was partly because I had set my sights a little high, but I think it was also because I did not have a problem that I really needed to solve. In this case, I had to figure out my applications return code, and I did. So if someone asked me now "How do I get involved in open source?", I might suggest that working on problems in the software you use daily is a better use of time than checking Sourceforge's help wanted list.