Overcoming blocks about contributing to Open Source

Contributing to Open Source can be super intimidating. Back in 2016 I already knew about the idea of contributing Open Source software. But never actually got started until November 2017. This is when I did my first contribution. Even though I started then, it was after getting accepted into Google Summer Of Code 2018’s edition, that I learned a lot about contributing to Open Source.

My first Open Source contributions

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 did my first Open Source contribution by adding a job board website to a repository with resources for people looking for a job, made of markdown files. My contribution is in the pull request #22 that I submitted for 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 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.
I created issue #167 reporting an improvement to systers.io website and then submitted pull request #168, changing the text for Slack community on the “Contact Us” page.

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.

Blocks to contribute to Open Source

So while I was participating on Google Summer of Code and trying to find ways to involve the community on the Mentorship System project I was working on, I remembered about 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 was some blockers from other members on contributing to Open Source.

After reading the answers given and blockers from my personal experience I gathered these blockers:

How and where to start contributing;
Not seeing many beginner issues;
Not being confident with my skills;
Some projects seem too intimidating;
Lack of time to contribute to open source;
What if I can’t finish something I committed myself to.

Overcoming Blocks on contributing

So after looking into the common blockers gathered, I started thinking about them, and if I could find a way to overcome them. So here is my perspective on these blockers.

How and where to start contributing

You can start with some initiatives just like I did with 24 Pull Requests. Some other examples are Google Summer of Code, Outreachy, and Hacktoberfest.

You can find Open Source communities that can 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 have well set up 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 library, social impact project, any piece of software you 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. You can also check Up For Grabs, which has a list of projects targetted for new contributors, and also CodeTriage.

There is an awesome guide on “How to Contribute to Open Source” by opensource.guide, that you can also take a look at.

Not seeing many beginner issues

As I said before, look out for issues labeled as “first timers only” and “good first issue” since these are specially targetted 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 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.

Not being confident with your skills

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 Systers community, I understood that thought my journey 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 looked into the project’s documentation, that can be on the Wiki (e.g.: GitHub Wiki), on a documentation folder together with the code, 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 never worked on, 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 from the project, if you really feel stuck, so that they can provide resources to better understand the project.

Lack of time to contribute

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 this.

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 per week (e.g.: 1 to 2 hours on Sundays, 1 hour every day, …). 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 can’t finish something you committed yourself to

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 projects owners, maintainers and the community, that you won’t be working on it anymore, thus giving the opportunity to someone else to solve it. 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.