A Year of Open Source: My Review

I just recently completed a whole year of working as an open source developer. I worked on various projects including Mozilla Firefox, EGit, JGit, SQLite, and NexJ Express. The following is a brief history of this process, followed by the lessons I have learned from it. Feel free to skip to the final section, because the rest is just about my personal experience.

Pre-History

I first flirted with the idea of ‘open source’ back in the good ol’ days of Windows XP with software like Azureus. I didn’t really understand what it was or meant, but just remember enjoying the fact that it came with no malware, or trial versions.

But it was in 2004 that I seriously started dabbling with open source software, when I started using Ubuntu. Ubuntu was new, cool and hip — Canonical has done an awesome job of making that the case. In this environment, I came face to face with terms like ‘contribute’, ‘report bugs’, ‘community’, and so on, on a daily basis. Eager to see what it all meant, I did some reading on Wikipedia and got on my way trying to contribute to some of the software that I used: Geany, Gnome, Rhythmbox. But I failed. I had no idea what a patch was, and I had no idea how to get started. The reason, as I discovered later, was because I was not using the right tools.

Summer at Red Hat

Them came last year, when I got an internship at Red Hat Canada. Here I was assigned to the Eclipse Team under which I got to work with some brilliant people. I started to work on the projects EGit and JGit, about which I have blogged before. Doing so, I got to learn some of the tools of the trade: irc, git, and github.

These three tools helped me immensely, I now had 24/7 tech support through irc, had loads of code available to read and follow through iterations, and had the freedom to experiment with code without the fear of breaking anything. These tools are very important to the functioning of an open source community, and I was finally beginning to see that.

DPS909

Then in September, with the resumption of school, I was naturally tempted when I saw a course available to me called ‘Topics in Open Source Development’ with Professor David Humphrey. This course turned out to be amazing. We spent the first few weeks in class discussing what ‘open source’ meant and how it stacked up to the competition. We watched and discussed Revolution OS, a documentary I recommend for all. We also read and discussed Eric Raymond’s seminal The Cathedral and the Bazaar.

I think the latter had a greater impact on me. While the documentary was great and gave you a good perspective of the history of the open source movement, The Cathedral and the Bazaar teaches you some of its fundamentals in an abstract way. I was extremely grateful for having read this.

At this time, we also read some common open source licenses, like MIT, BSD and GPL, and compared them to common proprietary licenses such as Microsoft’s EULA, or Apple’s various agreements. Most memorably, Dave recommended we listen to some of the more dramatic phrases in these licenses as read by master thespian Richard Dreyfuss.

More to the coding side of this course, we walked through some Mozilla Firefox code in class, adn had a talk with Mozilla co-founder Mike Shaver on how to get started as a MozDev. We read through a spec sheet Google had put out on the Mouse Lock API (now called Pointer Lock) and started to work on it. I personally wrote some Mochitests for it, but largely continued working on EGit and JGit from the summer.

DPS911

In the Winter semester, I continued with DPS911, the follow-up to DPS909, a more “project” oriented course. This semester, I made myself more familiar with Firefox code, and worked on three bugs for it.

Bug Blog # of patches 705234 Inconsistent use of “full screen” across Firefox code 3 620164 nsTheoraState::MaxKeyframeOffset doesn’t need to use MulOverflow 4 500784 Video/audio files over 2GBs in size are unseekable 1

I also continued working on EGit and JGit and released the following patches for these:

1. Egit — Work on CleanCommand — (5 tries, 2 abandons and counting as seen here)
2. Egit — CleanCommand Selector Dialog

Lessons
Anyway, this post is becoming much longer than I thought it would be, so I’ll bring it to a close with a few of the important lessons I have learned in this past year.

1. Use the tools available to you: git[hub], irc, twitter, blogs!
2. These are key! Being in an open source community means being in a virtual community. You have to make yourself heard and accessible in that space. If you simply release code with GPL stamped on it and tell no one, no one is going to use your code.
3. No Code Dumping
4. As an open source provider, do not work behind closed doors and then one day dump all your code outside and call it open source. Maybe you could get away with it if you are Google, maybe; but a big part of ‘open source’ is building a community. You can’t build a community with code dumping.
5. What is open source software worth?
6. In early 2011, the company I worked with was having a brain storming session to search for solutions to its telephony problems. While tossing out ideas, I mentioned an open source stack that could be used. The moment I did this, the person sitting next to me, a self-proclaimed “big business” type, turned to me and said.

• The problem with Open Source is that, with it you get what you pay for.

1. The implication was that since one acquires open source software for free, that it worth must also be nothing. I won’t go into details of the two meanings of the word ‘free’ in this context (Gratis and Libre), but I’ll simply point out that studies have shown that the Linux Kernel is worth over €1 billion. I have seen other sources cite that Fedora is worth over $10 billion. So no, free does not mean worthless.
2. The Open Source community does not owe you anything
3. I came across a beautiful quote on the Apache Jakarta project’s website which stated this quite eloquently:

• If you see something wrong [in an open source project] and do nothing about it, the opensource system hasnt failed you, *you* have failed the opensource system.

1. It is important to note that this does not only apply to developers, but also to bug-testers (ie users), writers, designers, etc. There are many types of open source contributors, not just programmers.

Anyway, I’ve been going on for a while so I’ll end this now, but on the whole, I am very grateful to Dave Humphrey and Red Hat for teaching me skills that I hold dear, and will help me as a programmer through out my career, I’m sure.