I’ve been a software engineer for almost 15 years now, and although I didn't realize it at the time, I’ve been working with open source software from the get-go. From basic GNU command line utilities to C compilers, open source was there from the start.
Even though my professional focus has changed over the years, in one form or another I’ve been living in a open source ecosystem—be it the operating system I used, the libraries I worked with, or even the integrated development environment (IDE) I used on a daily basis. Despite that, it never occurred to me to contribute to open source software until I joined Red Hat three years ago and began working on oVirt, an open source data center virtualization project.
It took me a while to buy in to the development process, which was completely different than anything I experienced beforehand—submitting a feature page for comments, submitting patches for review, collaborating with contributers from different countries and companies. It was all new and different to me, but it eventually made sense. Collaborating in an open fashion was simply a better way to produce high-quality software.
And yet, despite contributing a few nifty features and a large handful of code improvements, I’m not sure I really understood open source until recently. I was browsing StackOverflow, as I often do during my commute to work, and encountered a question about closing a file in java-libpst. Even though I’d never used java-libpst before, I thought I’d give it a crack. A quick skim over the javadoc showed me there was indeed no way to do so, except release the object and wait for the garbage collector to dispose of it. I wrote this down as an answer and was about to hit the submit button when the first stage of my open source realization hit me—we all know that documentation isn’t always perfect. It’s all too easy for a developer to forget (which is a polite way of really saying 'to neglect') to document his code. And even if the developer isn't at fault, the online documentation is all to often outdated and out of sync with the code. If only there were a way to verify my answer…
Oh wait, there is! A quick git clone later I was going over the code, and I could confirm that there was indeed no way to explicitly close the opened file handle. I noted this in my answer, hit submit, and moved on with my day.
I was halfway through my morning emails when the second part of my open source realization hit me. It’s open source. I’ve just cloned the source code and examined it. If the fix is really that trivial, why not put my money where my mouth is and just do it? A couple of minutes later I had a pull request submitted, and a couple of days later it was accepted and merged by the project’s maintainer, Richard Johnson.
For me, this is the true meaning of open source: software that, when you find it to be lacking, you don’t have to wait for some faceless distributor to fix your bug report or fill your request for enhancement. You can go ahead and do it yourself. And often times a helpful stranger will come along and help you out for no reason other than wanting to make the world a better place, one line of code at a time.
1 Comment