10 May 2021
7 min read
For some time I wanted to contribute to Open Source but never actually took the steps to do it until I saw an initiative called 24 Pull Requests, which is about giving back to Open Source during the month of December.
During this virtual event in 2017, I made my first Open Source contribution by adding a job board website to a repository made of markdown files with resources for people looking for a job. My contribution is in pull request# 22 that I submitted for the fvcproductions/hire-me project.
Then, at the beginning of 2018, I started contributing to some projects as I was trying to apply to Google Summer Of Code (GSoC), making these two contributions:
I submitted pull request# 1986 to the opendatakit/collect project, where I picked up work from another contributor’s contribution and completed the issue. This involved changing a line of text on an Android application.
So I started with small steps. Then in April 2018, I got into Google Summer of Code with Systers Community where I was able to learn much more about Open Source.
While I was participating in the Google Summer of Code and trying to find ways to involve the community in the Mentorship System project I was working on, I remembered what was keeping me from contributing to Open Source initially. Then I created a short survey for newcomers of Systers Community so that I could understand what blocks other members had in contributing to Open Source.
So after looking into the common blocks gathered, I started thinking about if I could find a way to overcome them.
You can find Open Source communities that have a consistent organization and context among its projects and a community of contributors who can help you get started.
A good way to find these is through seeing accepted organizations at Google Summer Of Code. These organizations may projects ready for you to contribute to. I found communities such as Open Data Kit, Open Food Facts and Systers here.
Regarding finding projects, you can look into the projects you use frequently (e.g.: open source libraries, social impact projects, any piece of software you’ve use, etc…). You can look at issues labeled as “first-timers-only”, “good first issue” and “help wanted”, since these are usually used to indicate that the issues are beginner friendly.
There is an awesome guide on “How to Contribute to Open Source” by opensource.guide, that you can also take a look at.
As I said before, look out for issues labeled as “first timers only” and “good first issue” since these are specially targeted for new contributors. For example, whenever I can, I label issues like this for newcomers, at systers/mentorship-backend and systers/mentorship-android projects.
Although these labels can be helpful, don’t limit yourself to them, because some issues may not have these labels but are still doable for you. You can always propose new issues, and if they’re valid then contribute to them. This is exactly what I did with my contribution to the Systers.io website. I created an issue and then fixed it.
If you really don’t find issues that you feel you can solve for the project you’re looking into, try to look at other projects for you to begin with.
Confidence comes with time, and you don’t have to know everything. Being a software developer, I wanted to start contributing with actual code, but my first contribution consisted of editing markdown files. Even though this wasn’t a feature added to a project in the form of code, my contribution could help people looking into resources for a job hunt. I was super happy with this first step towards getting started with contributing to Open Source.
My next contribution involved changing text being used on an Android application. Even though this seemed like a small change, it was totally a valid contribution. So having said this, I think you can start small while building up your confidence while you start contributing. Even small changes are valid contributions to advance a project.
By the end of the GSoC program with the Systers community, I understood that as I moved forward I was feeling a bit more confident as I contributed to the community. Some Projects seem too Intimidating I totally understand this, there are projects in Open Source that I don’t feel prepared to look into, as much as I might have the curiosity to. I can think of Open Source programming languages or tools I use that have a large codebase.
Know that projects have documentation that can help you, so look out for that. Make sure you look into the project’s documentation that can be on the Wiki (e.g.: GitHub Wiki), in a documentation folder together with the code, in discussions on forums, or on the issues comments’ section.
Documentation can be scattered in multiple places. Also, it takes time to understand a project you’ve never worked on, so you may have to spend some time looking into the code and setting it up to understand the project (if you’re contributing with code). Besides looking into the available documentation, you can always reach out to the community and maintainers of the project if you really feel stuck so that they can provide you with resources to better understand the project.
Everyone has their own lives going on with their own commitments. You have to think about how much you want to be involved with Open Source, and the “why”. Is this worth your time contributing to a specific project? Is it to give back to a project you care about? How much time can you actually give for this? What are your motivations? After you understand these you’ll have to think about how to incorporate this into your schedule and how to prioritize it.
Why not start with baby steps, both on the time and the task you’ll work on? You can try to allocate a period of time, per week, to work on Open Source projects (1 to 2 hours on Sundays, 1 hour every day, etc.). You can also start working on low effort issues like I did for my first contribution. This can help you get acquainted with a usual Open Source workflow (e.g.: fork -> clone -> work -> submit pull request) and help you get into a habit.
For me, it really helps to contribute to something I care about and want to see grow. Also, I enjoy a lot maintaining a project and making it accessible to newcomers to Open Source (e.g.: by creating issues with “first timers only” label in mind). I also enjoy giving back to the community that I worked with during GSoC.
What if you commit to work on an issue and then you aren’t able to finish it, either because you lost interest for the issue, or aren’t able to finish it in the time you set yourself to do it, or its not appropriate for your current skill level? No matter the reason, this can happen.
If you’re getting initially stuck in the issue you’re trying to solve, it helps to ask questions to the community and read the documentation available to you.
If you really feel you have to give up on it, don’t just abandon it. Give notice to the project owners, maintainers, and the community that you won’t be working on it anymore, thus giving the opportunity to someone else to solve. You can let them know by leaving comments on the issue you committed to. This is totally OK! Also if you already have some work on it that can help the next contributor, share that.
By doing this, you’ll make the maintainer’s life easier, because they will know that another issue is available to be assigned to another contributor.
Hope you enjoyed this article and find getting started with Open Source a lot less intimidating!
To find more information about Open Source, I find the opensource.guide website to be a very good resource for all things related to Open Source.
See other articles by Isabel
Ground Floor, Verse Building, 18 Brunswick Place, London, N1 6DZ
108 E 16th Street, New York, NY 10003
Join over 111,000 others and get access to exclusive content, job opportunities and more!