Here’s a beginner’s guide to making open source contributions.
‘Open source software’ is a term we come across fairly often in our daily lives, but have a faint idea of what it entails. I remember my first questions about it.
“Is it code? Like huge files with complicated functions that I have no clue about?”
The answer to that is, it’s not. Not all open source software (OSS) comprise code bases that can cover the surface of the pyramids. And hardly any of it is as esoteric as hieroglyphics. In fact, most open source software comprises easily understood code maintained by diverse people ranging from 12-year-old school kids in Russia to 80-year-old Nobel laureates in Antarctica, and everyone in between. Most open source enthusiasts take it up as a hobby or pastime, while contributing to the ‘greater good’.
“Alright, but I can’t code!”
Open source contributions are not just about writing code. In fact, OSS would have died out a long time ago if it hadn’t been for those ‘non-coders’ who helped the community out by adding documentation for the code.
Equally important are the people who contributed their time to answering questions regarding these projects and others that contributed towards adding examples to the project in order to make it easier for beginners to understand use-cases for the software. There are people who have curated the mailing lists for the project, in turn learning much more about it than they had originally expected. Life surprises you and so does OSS, it would seem.
If none of this appeals to you, there are still others who contribute by organising meet-ups or video conferences for a particular OSS project or even just a fun get-together! Everyone is an open source contributor as long as one is helping others out in whatever capacity one can. It can be an extremely rewarding process, as you will eventually find out!
“So it’s probably stuff I can do. But why should I do it?”
There are a number of reasons that can motivate you to take up open source contribution, ranging from community welfare to personal gain:
1. It results in quality code being accessible to developers who rely on it for their work, thus avoiding having to rewrite functions from scratch since they have free access to open source software.
2. The sense of accomplishment after submitting your contributions, which could be used internationally, is simply fantastic! Imagine someone in a remote cabin in Alaska reading your solution, and sending up prayers of thanks to God for your help in resolving an issue with his installation.
3. The badge you wear with respect to your track record is for all to see. Regular contributors are valued for their skills as well as respected in the open source community. Who knows when a recruiter might come across it and recognise your efforts…
4. Developing people skills and engaging with like-minded others — it is essential to interact with a lot of really friendly and often erudite people while contributing to OSS. This can be a really enlightening as well as an entertaining experience, while helping you expand your network.
“Okay, I’m sold! Now how do I get started?”
There’s a very well-documented and easy series of steps on how to get started with open source contributions. I looked back at my first time and came up with what’s shown in Figure 1.
It turns out that the first time I contributed to some open source project, it wasn’t really software that I was adding to. It was a JetBrains list of university website domains for student email verification!
So let’s go over some basic concepts here. In order to manage any set of data that is being modified by hundreds of contributors, there needs to be a system which can:
1. Manage all the different copies of the data,
2. Allow the editing of the same data by multiple people, and…
3. Concatenate all of it into a single chunk when completed.
Thus, we have a ‘version control system’ that, as the name states, offers to control the multiple versions of data that may concurrently exist, given that hundreds of people edit the same code. GitHub is one of the sites that offers such a system, providing free hosting to open source software, files or data.
On GitHub, software is stored in different repositories which are essentially like separate folders (or workspaces) for each project that you may want to host. Each repository has its own set of issues, bugs, code, documentation, and so on. We will look at how to start with contributing using the JetBrains repository as our example (Figure 2).
As you can see, it consists of a number of files and can be overwhelming to understand. Hence, we have the README file that is supposed to contain information about the project and help a newcomer understand what it is all about. Take a look at the JetBrains README.md file (Figure 3).
In order to create our own version of this repository (project), we will have to create a GitHub account and then ‘fork’ a copy of this project to our repository. Forking is basically creating a separate copy of a project for your use.
Often when software is being edited, the ‘master’ branch remains untouched while the changes are tested on a ‘forked’ copy (the ‘development’ branch) of the project. Once it is verified that the ‘development’ branch passes all tests, it is ‘merged’ back into the ‘master’ branch.
Figure 4 illustrates how you can ‘fork’ a copy of the ‘master’ branch, thus creating your branch(es), and how you ‘merge’ your branch(es) back into the ‘master’ branch when you’re done editing your branch(es) of the project.
Assuming that you have created your GitHub account, log in and visit the JetBrains repository. Click the ‘Fork’ button on the top right side of the screen and select your repository as the option (if you have multiple organisations as options, don’t worry; just select your personal page). If it doesn’t show your personal page, you probably already have a copy of it forked on your page (Figure 5).
Now, visit your copy of the repository and make the changes in the code as per the instructions in the README.md file. Add your institution domain name as per the folder structure described. Use the UI to create a new file with the name of your institution.
For instance, I’ve added mine as lib/domains/in/edu/djsce.txt since my college email address is www.djsce.edu.in. It contains the name of my institution (Figure 6).
Once you’re done, it is time to merge this updated code back into the master branch! Go to the ‘Pull Requests’ section. Now, since we have forked the code, the procedure to merge it back is known as creating a ‘pull request’. Essentially, we request the master branch to ‘pull’ our changes back into it. It will ask you to add a description and name for the edit or ‘commit’ that you’re providing. Once you have created one, it will show up on the JetBrains repository like the other edits/commits there (Figure 8).
Now, since you don’t own the JetBrains repository, you need to wait for the admins to approve your pull request. Once it’s been merged, it will appear to be something like what’s shown in Figure 9.
And that’s it. Congratulations, you are now an open source contributor!
Because of you, every student at your institute can now request a JetBrains student discount using their university’s email address. You may now feel awesome for helping generations of students at your institute with just ten minutes worth of effort; keep at it!
You can also contribute towards addressing the ‘Issues’ on various repositories. Most of them have issues reserved for beginners or those labelled ‘first-timers only’. There are also websites like MunGell’s list of Awesome Beginner Projects and Up For Grabs that will help you get started on submitting your first pull request.
