I've been using various Open Source Software (OSS) packages (both personally and professionally) for many years now. Today, for the first time, I contributed back to the community. Recently, I've been using a very handy program called RESTClient for testing web services. I wanted to use the command line version of this tool to run some tests, only I found that the latest version had a bug that prevented my from using the JUnit "fail()" method.
Instead of giving up and looking for another tool, or deciding to just not use the JUnit call, I figured that "well, it must be an easy bug to find and fix" so I gave it a shot. I grabbed a copy of the source from the public Subversion repository, got it all to compile, and in short order I found and fixed the bug.
Being the lazy sort (not wanting to maintain my own private build forever), I filed a bug and submitted a patch, along with a simple test case that showed it worked. The project owner got backed to me today and told me my change had been accepted, and is in the latest build. Cool stuff!
Although the fix itself was trivial (I had to change one line), what isn't trivial is overcoming inertia. Most developers (myself included) are too busy/reluctant/lazy to go through the effort of something like this. I overcame my own inertia and discovered that (A) it isn't all that hard and (B) and I enjoyed doing it.
You see, I think what most of us miss the point that Open Source software, is well, open. If you see a problem and it gets in your way find it and fix it. This simply isn't possible with proprietary, closed source software. Oh, sure, we all know the arguments for OSS, but we rarely take these to heart. Heck, I best most folks don't even bother to download the source just to learn from it, much less try and fix a problem in it.
Contributing back bug fixes (even trivial ones) like this goes beyond helping the maintainers or other users of OSS - it helps you as a developer, too - perhaps even more so. It gets you out of your own software ecosystem: You may have to use a source code control system you're unfamiliar with. You'll have to get a build working. You'll have to figure out new code. You'll have to debug and fix unfamiliar code.
All these things are good. They promote learning - and in software development, learning is not optional.
Besides, it feels good to know you made an improvement in something other folks use (even if it seems like a trivial change).
Subscribe to:
Post Comments (Atom)
Great post Jerry!
ReplyDelete