Opening up to Open Source - Part 1

Tags

• open-source
• civicrm
• git
• github
• gsoc

What this series of blogs is about:

• My experience of volunteering for an open source organization;
• Things I wish I knew before I started my open source journey as a student;
• Tutorials about how to go about creating your first patch.

What this series of blogs is NOT about:

• A general introduction to the open source world. There already exist definitive and well-written guides out there on the internet concerning the same. If that is what you’re looking for, here is the link to GitHub’s guide on contributing to open source projects which I found to be particularly short, sweet and to the point;
• Unicorns.

The Beginning

The toughest part of contributing to open source projects is getting the ball rolling; it’s not easy for a newbie to build software from source and to get accustomed to large and abstracted codebases that accompany.

I remember how excited I was when I first downloaded the source code for Mozilla Firefox and also how frustrated I was after a couple of hours when I couldn’t even figure out where the code for a simple menu was located (yes I was naive and grepping for stuff was a foreign concept sigh).

Once you’ve found an organization that catches your interest, start off with joining their mailing lists and IRC channel. However, I’ve noticed that people (including me) have this tendency to try and not make a fool out of themselves on public fora and therefore just prowl IRC rather than ask newbie stuff on it. Moreover, it’s rather not uncommon for people to get replies some 12 hours after they initially posted their question because of timezone differences and not a lot of people stick around for that long.

I cannot stress on this point enough. You need someone to hold your hand in this initial phase. If you have any doubt on how to build the software, how to deal with an issue/bug, how to rebase the 2945 commits you accidentally inherited when you forgot to change your branch before making the PR, you email your mentor. If you’re lucky and the people running the organization are helpful, your life will be made extremely easy.

Google stuff, go through the organization Wikis, read their blogs and forums. Initiative is the key here. Your mentor will only assist if he/she finds your work and willingness to work to be up to his/her expectations.

Exploring the Code-base

I remember the first patch I made was a patch which fixed the comments for a couple of modules: stuff which did not involve heavy lifting and guaranteed no real harm to the working of the modules.

The beauty of starting with patches such as these is that:

a) you get used to the preferred coding style of your organization, and

b) you get to explore various classes/modules and their functionalities.

The added incentive being, you’re improving your organization’s documentation and protecting it from grammatical errors.

Head over to part 2 for writing your first real patch.