For anyone who has used some open source software, tool or platform, the thought of making one’s own contribution is nearly inevitable, as is the ensuing doubt that throws the potential value of that contribution into question. How can someone who is not a veteran of the project’s development, particularly in the cases of long development timelines, make a meaningful contribution?

Well there are at least two ways to offer a positive answer to this kind of question. The first surely lies in the logic of starting small: maybe you can’t contribute a whole other feature-rich package to an existing project, but you can likely help tidy up, and will learn a lot in the process. The original and continuing developers may have been experts in their fields, but they are human too, and none of us catch every issue nor have the time to fix everything. The second method, in a similar vein, derives from the reassuring (or perhaps disheartening if you’re a perfectionist!) reality that little is ever finished, and that every person brings something new to the table: a new skill, a new view, or possibly even just thoughtful encouragement. As with virtually every historical study: there is always room for another thought, another correction, or another perspective. For my part, I believe I can offer a couple of helpful skills to the Free and Open Source Software (FOSS) world:

• Attention to detail. It is no secret: when it comes to programming, the devil is in the details. Anyone who has programmed in C++ for a few minutes knows that a missing semi-colon or comma may yield a headache - and yes, chances are the developers tried their code out after additions or revisions - but in the cases of project sprawl, use of new libraries or language features, and optimizations, did they catch every single potential issue, particularly with back-compatibility? Unlikely. Time spent working as a paralegal taught me well that careful preparation and review up front will pay dividends later - and who doesn’t like dividends?
• Big picture perspective. When I am learning a new codebase I cherish any good resources I can get: a complete roadmap at best, but at least some helpful tips on where to start looking will serve as a start. Having nothing but a wall of code and some inline comments? Not as much fun. While the litany of sub-classes, inherited methods, and unreadable but well-optimized methods likely made sense to the developers, trying to decipher all of this can be incredibly frustrating to an outsider. Call me a visual thinker, or a hopeless idealist, but I believe explanation comes in layers, beginning with the big picture.
• An appreciation for the human readable and an ability to write. As one may imagine, I spent a fair amount of time writing in my time as a history student, and I continue to insist that I learned, above all, how to read and how to write. Thus while I, perhaps more than others, cringe at writing which says so little with so many words, I also cringe at some of the highly developer-speak documentation I come across. No one expects Shakespeare in the pre and post-conditions, but one doesn’t have to look far for human-readable and inspirational documentation: just type man man into your (UNIX / Linux) shell.

To touch on another more personal note, I should add where I might find myself applying these skills, and to what kind of work I am drawn:

• Anything cutting-edge. Lover of all things technological and computational? Guilty as charged. Growing up with VHS and dial-up, I find myself constantly amazed by the technology around us, and have long had a fascination with robotics. Open source projects in robotics and AI like Robot Operating System (ROS) and OpenCV? Count me in.
• Teaching. While I have always enjoyed a touch of teaching - even if leading history grad school seminars gave me the jitters - I never figured I would really see myself in the teacher role. Work as an undergraduate teaching assistant and tutor taught me otherwise. Everyone has been in the position of being saved when help was needed the most - be it by a teacher, a tutor, or perhaps even just a back-of-the-forum post that just happened to touch on the bug you’ve encountered! Being able to pay it forward feels good, and I can see myself doing the same in FOSS examples and tutorials.
• Music. It has unfortunately been a while since I have picked up a guitar, but I am still a lover of music. When I did record music with friends as a teenager and as I have run into audio editing tasks over the years, I have always turned to Audacity. As a free and feature rich audio editing tool, it has always been an obvious choice for me, but upon taking another look at Audacity I can happily note that it is also part of the FOSS world, licensed under the GNU General Public License, Version 2! You can learn more here.

Other Course-Related Activity:

• This week I went through the OpenStreetMap iD editor tutorial and made 4 contributions, adding businesses that were not identified on the map. Those contributions can be found on this blog’s Contributions page.