Reno, NV    +1 (800)0 621-0871

Go back

Development

Contributing to Open Source

  |  August 22, 2012

Here at Aelogica, we love open source. All of us have, one way or another, created an open source project or contributed to it. Contributing to open source is very fulfilling – people contribute to each other’s work and it is a great way to learn new things. I’ll talk about this in detail in a little while so hold on to your seats. Most of my points may have already been said before but hopefully, if you haven’t contributed or created any open source projects yet, this post might make you think about doing so.

Creating an Open Source Project There are a lot of posts (and even books) about creating/maintaining open source projects so I’ll only state what I think and have experienced about it. FIrst, being forked (for the non-technical, basically someone copies your code to modify or use for his own purposes) in Github gives me the feeling of importance and that my work was valued. It gives you that sense of accomplishment comparable to seeing people use a phrase or word you just invented (or a fad you started – not that I have started any fads). Most of us have created open source projects and I’ll use this opportunity to showcase some of them:

Contributing

For me, contributing to open source is very fulfilling. It gives me almost the same feeling as creating an open source project that was forked. You don’t have to be a really bad ass programmer just to contribute. Contributing can come in many forms: creating issues (bugs that you encountered and don’t know how to fix), participating in a discussion on how to move forward with a project (some individuals that have a huge amount of followers usually consult with their users through a mailing list – asking for suggestions on how to tackle a problem), and even correcting spelling/grammar mistakes that might lead to confusion. Pointing out bugs (don’t forget to also show how to reproduce it!) helps developers greatly since most of the time, they don’t have the means to QA everything their apps/tools do. That means it is up to the community to help with spotting (and fixing, if possible) the bugs that appear.

Interacting with our Heroes

I am easily starstruck by my own heroes and idols. I’m pretty sure a lot of people are too and that’s also a great motivation to working with their projects. A couple of my heroes are Aslak Hellesøy (creator of Cucumber) and Chris Eppstein (creator of Compass and core team member of SASS). I pretty much use their creations everyday so when the time came when I wanted to give something back, I helped out as much as I could. They are also VERY active in their respective mailing lists – almost replying to each of the emails there – making sure that the community is active and that newcomers feel welcome.

Back when Aslak requested people to come into the cucumber chat room to help out with merging all the Cucumber Textmate Bundle forks into one (and making it officially under cucumber’s repo), the best I could do was to join in and look at the logs to see which ones were good or not. I knew NOTHING about Textmate bundles, and the only reason I was there was because I USED Textmate (before) and I loved Cucumber. Even if Aslak and the others did the coding and stuff, they made me feel like I was still of help even by just checking the commits of each one.

Another time I helped my hero was when Aslak requested someone to create a script to mass message all the forkers of the Cucumber Textmate Bundle. I did that script during my free time and that knowing he used it (he even helped me test it!) made my day. It’s like helping Spiderman or Batman by throwing a rock at an enemy he’s fighting with – you know they can beat that guy up even without your rock, but you also know that somehow, you made their fight much easier.

Contributing: Learning New Things

Contributing to open source also makes you learn things – things that you would otherwise not care about given other circumstances. Case in point: I suggested to YADR (this is the current dotfile package most of us use now) that vimrc.afters should be in /vim/after, not in root – to minimize the files in root and so everything will be in your yadr folder. To be honest, I was expecting them to actually fix it, since I knew nothing about customizing Vim. The reply: “Please do implement and pull request :)” made me stop in my tracks. It was very polite of Yan (the owner) to say “if you really like it, do it”. Having no experience whatsoever with Vim plugins (I relied on other people/plugins to customize my Vim), I didn’t know if I should just leave it until someone else does it (someone actually agreed with my suggestion).

Instead, I thought of it as a challenge so off I went and experimented – besides, it was just a simple path fix, what could go wrong? Sure enough, that simple fix took me longer than expected. I perused the Vim help files and looked at the definitions for filereadable, expand, and the filename expansions for Vim. It was indeed a challenge (for me) so in the end, I had to concede and assume that the file was in ~/.yadr/vim/after instead of ~/. My original solution was to direct relatively so even if yadr was installed elsewhere it would have been okay. In any case, I still learned something new in the process of contributing, so in the end, it was still a good experience (not to mention it was merged to master a few minutes after the push!).

I hope that a lot more people will start their own projects and contribute to projects they love and use. It just makes the (software) world a better place to live code in.