I’ve talked to a number of people about what they think are some of the best ways to get experience working as a software engineer, and something I’ve heard mentioned often is contributing to open source projects. I finally did and in honor of Hacktoberfest, I’m going to talk about my experience and what I learned in this blog post.
First I’ll talk a little bit about what open source projects are. When a project is open source, that means anybody is free to use, study, modify, and distribute the project for any purpose. These permissions are enforced through an open source license. Anyone can use a license to make their project open source, and one of the big reasons to do this is to promote collaboration with other developers. Most open source communities are all about collaborating with anyone who wants to help their project, including old-timers and brand new programmers.
For my first foray inter open source, I decided to look into how to contribute after I’d heard about open source from a few people. When looking for a good place to begin, I found a page on Github called awesome-for-beginners. It has a list of open source projects that welcome first-timers organized by programming language. When you click on any of the links, they take you to the project’s issue page and shows the issues with labels like first-timers-only, good first issue, or beginner.
But even with this page designed for beginners, it was very daunting for me to try to work on an issue. But, thankfully, there was an event that was going to start around the time I was looking into open source: Ruby for Good. This an annual event that usually take place in the DC-metro area, but it was online this year because of COVID-19. Ruby for Good works on open source Ruby projects designed to help non-profit organizations. During the event, all of the participants spend the weekend working together on any of the projects that have been decided on for the event.
For the event, I worked on the Diaper project. It is an inventory management system that is built to address the needs of Diaper Banks anywhere in the country. The project was started in 2016, and is now being used by a number of people across the country. Thankfully, Ruby for Good is all about pair coding, and I got to work with some people who have been working in the tech industry for 10+ years. They walked me through making my first pull requests to open source projects, and I’m going to talk about what I learned.
From what I understand, the way you contribute to open source is by finding an open source project, getting the project running on your local machine, and going to the issues page to find an issue to help with. To get the project running on your computer, there should be detailed instructions for how to install and run it in the README file of the project. Don’t forget to fork the project so you don’t end up messing up the main project.
You can get to the issues page by clicking the tab at the top of a page for a Github repo. Each of the issues has a name that describes what what the problem is, which could be anything from a bug, fixing the way something looks, or changing some functionality. Here is an example page from the project I worked on:
The number after the circled Issues is for the number of issues waiting to be resolved. And you can see something that I mentioned before: labels. People who create the issues will sometimes add labels to give some information about the issue that you can see at a glance. You can also filter by labels, which is helpful if a project uses things like the first-timers-only label.
When you click on an issue, there should be a more detailed description of what is going wrong and how to find it/cause the problem, sometimes with screenshots and an example of how this piece of the project should work once it is fixed. If it is an issue you want to try your hand at, you can comment in the issue that you would like to take it, or if you are part of the organization that the project is in you can assign the issue to yourself.
After you’ve taken an issue, it’s up to you and your coding knowledge how to solve it, but here are some things to keep in mind. You will probably have to take some time reading through the code to understand a new code base that you’ve never worked with before. The issues I solved seemed to take as much time finding where in the code the problem was, as actually solving it. Also, any good open source project will have rigorous testing, so make sure to run the tests after you’ve changed things, and if the change you made was big enough, you should write tests to address it.
Once you’ve finished working on the issue, it’s time to make a pull request. Once you push your changes to your forked copy of the project there should be a handy bar towards the top of the repo that looks something like this:
Once you click on Pull request, circled in the picture above, Github will show you the changes made, and if the branches can be merged. Then you can click on Create pull request and you are given a place to describe what you changed and what issue the changes addressed. From there, it’s up to someone else to either merge your changes or give you feedback for more changes or fixes to what you did. If you do need to make changes after you’ve made the pull request, just push the changes to your branch on Github, and the new commits will show up in your pull request.
And that is most everything I learned about contributing to open source projects. Ultimately, I’m glad I attended the Ruby for Good event, because it allowed me to get an introduction to open source projects while working with people more experienced than me. I now feel comfortable enough to work on issues and make pull requests on my own, which is what I am doing this month for Hacktoberfest. It also gives me a chance to interact with more people in the programming community, and work on projects that are being used by real people.