My first contribution to open source: Making a decision

A new open source contributor documents a series of five mistakes she made starting out in open source.
92 readers like this.
4 hot skills for Linux pros in 2017

Internet Archive Book Images. Modified by CC BY-SA 4.0

Previously, I put a lot of blame on impostor syndrome for delaying my first open source contribution. But there was another factor that I can’t ignore: I can’t make a decision to save my life. And with millions of open source projects to choose from, choosing one to contribute to is overwhelming. So overwhelming that I would often end up closing my laptop, thinking, "Maybe I’ll just do this another day."

Mistake number two was letting my fear of making a decision get in the way of making my first contribution. In an ideal world, perhaps I would have come into my open source journey with a specific project in mind that I genuinely cared about and wanted to work on, but all I had was a vague goal of contributing to open source somehow. For those of you in the same position, here are strategies that helped me pick out the right project (or at least a good one) for my contribution.

Tools that I used frequently

At first, I did not think it would be necessary to limit myself to tools or projects with which I was already familiar. There were projects that I had never used before but seemed like appealing candidates because of their active community, or the interesting problems that they solved.

However, given that I had a limited amount of time to devote to this project, I decided to stick with a tool that I already knew. To understand what a tool needs, you need to be familiar with how it is supposed to work. If you want to contribute to a project that you are unfamiliar with, you need to complete an additional step of getting to know the functionality and goals of the code. This extra load can be fun and rewarding, but it can also double your work time. Since my goal was primarily to contribute, sticking to what I knew was a helpful way to narrow things down. It is also rewarding to give back to a project that you have found useful.

An active and friendly community

When choosing my project, I wanted to feel confident that someone would be there to review the code that I wrote. And, of course, I wanted the person who reviewed my code to be a nice person. Putting your work out there for public scrutiny is scary, after all. While I was open to constructive feedback, there were toxic corners of the developer community that I hoped to avoid.

To evaluate the community that I would be joining, I checked out the issues sections of the repos that I was considering. I looked to see if someone from the core team responded regularly. More importantly, I tried to make sure that no one was talking down to each other in the comments (which is surprisingly common in issues discussions). I also looked out for projects that had a code of conduct, outlining what was appropriate vs. inappropriate behavior for online interaction.

Clear contribution guidelines

Because this was my first time contributing to open source, I had a lot of questions around the process. Some project communities are excellent about documenting the procedures for choosing an issue and making a pull request. Although I did not select them at the time because I had never worked with the product before, Gatsby is an exemplar of this practice.

This type of clear documentation helped ease some of my insecurity about not knowing what to do. It also gave me hope that the project was open to new contributors and would take the time to look at my work. In addition to contribution guidelines, I looked in the issues section to see if the project was making use of the "good first issue" flag. This is another indication that the project is open to beginners (and helps you discover what to work on).


If you don’t already have a project in mind, choosing the right place to make your first open source contribution can be overwhelming. Coming up with a list of standards helped me narrow down my choices and find a great project for my first pull request.

What to read next
User profile image.
Galen is a Senior Software Engineer at Simple Health in NYC. She loves writing (for computers and humans), lifting, and cats. @galenemco


There is a lot of help that comes from a mail list. First of all, you can get to see the range of people who ask or answer questions on the list, but perhaps more importantly, how supportive they are to inexperienced users. When someone answers a legitimate question rudely, does someone else call them out about it, asking them to be more kind? Are legitimate questions ignored? Sometimes what looks like you're being ignored is that a question is not framed well, so some persistence is necessary. Any persistent question should receive some answer eventually.
If you don't feel you can relate to the mail list, maybe you're not going to relate well to the project's community either.

Nice article! There is some great advice in here!

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.