How to start contributing to Open Source

If you are transitioning careers or just graduated, you are probably looking for that mythical first opportunity. But there is one thing in common in almost 99.9999% of job postings: you have to have experience.

How do I get experience if I can't get my foot through the door? Well, one thing you are going to hear a lot is: start collaborating with open source!

Ok, great. Then you start to look into it: Do I need GitHub/GitLab/Bitbucket? Which project do I pick? How do I even find a project? What is an issue? Do they have issues for beginners? Can I even contribute? What if I make a mistake? Will I need help? Will anyone help me? Will they answer me? Will I make a fool of myself? What even is open source? etc etc etc

Disclaimer #1

Before we go ahead: I'm a junior developer, who recently started contributing. I'm by no means an expert in any of this. But I thought it could be helpful for other juniors to get the perspective from someone in their shoes.

First things first: what is open source?

For the purpose of this article, I don't want to go into what is open source (though you should read up on it and learn why it's important). Here is the gist of it:

Open source software (OSS) is software that's freely available to use, redistribute, and modify, typically shared via a public code repository hosting service.
Projects that are open source encourage a transparent process that is advanced through distributed peer review. Open source projects can be updated quickly and as needed, and offer reliable and flexible software that is not built on locked proprietary systems.
https://www.digitalocean.com/community/tutorials/what-is-open-source

Where to begin?

GIT: If you know zero GIT I would recommend starting there. You don't need anything too fancy, just the basics will be fine.
GitHub: You can use other services, but GitHub is the most popular one. So it makes sense to start there. I'll be honest, I find their interface messy and confusing, it took me a while to get used to it. So if you too find it confusing at first, don't sweat it, with time you'll be more familiarized with it.
Personal Projects: All that said, before diving into open source you should try working on some personal projects to get familiar with GIT and GitHub.

Disclaimer #2

Make sure when you decide to contribute to open source, that you are actually able to do so. Open source is a great way to learn, but these are people's real projects, and we are there to help.

Also, you don't have to be a programmer to help. For example, you can write documentation, or maybe help with design, different projects have different needs.

Looking for a project

So you know the basics and are ready to help. The next step: finding a project! There are a million projects out there, how do I even find one?

There are some resources that can help (I listed some and the end of this article). But you will have to do the leg work. Pick the language, technology, framework you want to work on and research.

What I did: I decided that for a week I would look around and research. By the end of that week I would pick 3 projects. To look for projects I used CodeTriage and Ruby for good.

The three projects I picked: Rubocop, CASA and openfoodnetwork. Why those three?

Rubocop is a ruby gem that I use quite a bit. I wanted to pick a bigger project to follow, even if it might take a while to actually be able to contribute. And I wanted to pick something that I used somewhat frequently.

However I thought it was more realistic to pick smaller, less complex projects. So how/why did I choose those other two?

First and foremost, I actually liked what the projects where about. Then I looked at other things:

Do their issues seem like something I could tackle?
Do they have a lot of stale issues?
How is the activity in the repo?
Do they have a slack?
How is the activity there?
Do they seem open to newbies?
Are things well explained, organized and documented?

You found your projects, now what?

It might be easier to start by focusing on one. Out of those three, pick one. If they have a slack, join it, and introduce yourself. Take your time going through their README. Most projects will have a really detailed README explaining how to contribute, install, etc. Follow their instructions, and install the project in your local environment.

I decided to start with CASA. They have pair programming sessions that they do every week (office hours), I thought that sounded great. Besides, they seemed really welcoming to newbies like me.
I started installing the project locally, had some issues, fixed them, but the office hours came, and everything wasn't properly installed yet.

Since they said they could help with installation issues, I decided to hop on the call anyway and check it out. It was great! They helped me finish the installation, and even went through a really simple first issue with me.

Pick an issue, make a branch, push and PR

After you installed everything, you should pick an issue, and try to solve it! There really isn't a secret to this, it's leg work, you are going to need to go through their issues:

Is anyone working on this?
Was this done already?
Do I understand this issue?
Can I tackle this?

If you have questions, you can leave a comment in the issue. Even if you don't work on it, it might help other contributors. If the project has a slack, you can ask over there. Since you already got familiarized with this project, by now you should have a feel for how they work, and their preferred methods of communication. As a rule of thumb, try to always communicate in public. If you have a question, other people might have it too.

Now that you picked an issue, check if your main is up to date and make a new branch, name it something that is easy to identify. I like to add the issue number and a descriptive name, this way I can type the number and tab to autocomplete the rest.

Now that you got your branch, you can work on it, make tests, push, ask more questions, work on it again etc. While working on your feature, bug, chore, whatever it may be, don't forget to keep your main and branch up to date.

When it's done, it's time to make your PR (pull request): be descriptive, what does this change and why. Images or short videos can help, add those if needed. When you are done, publish it and wait for it to be reviewed.

The maintainers will probably have some suggestions, some questions, maybe ask for some changes, that is ok! This is a learning opportunity, listen to them, make new questions, and update your code accordingly.

Hopefully your PR will be approved and merged, when it is, celebrate! You got your first PR merged!

Disclaimer #3

Well, sometimes people might not even look at your PR. That can be super frustrating. Keep in mind that people are busy, and everyone has their own problems and priorities. If the project has a active slack you can always try to ask if a maintainer could review it, or why no one has. Obviously be polite and mindful of people's time. Remember, you are there to help.

Outreachy and other programs

After you dipped your toes into this open source thing and decided that this might be for you. You might want to take a look at some open source "internship" programs like: Outreachy, Google Summer of Code and MLH Fellowship.

They used to be for university students but are now accepting non-students. All of them last about three months, are fully remote, and pay a small stipend. It might be a good way to learn, get some experience and do some networking, so check them out.

What if I make a fool of myself and make a mistake?

Honestly, yeah you will. I have many times, and that is fine. You are learning. No-one expects you to be perfect. You won't be able to merge on main on your own, so any crazy thing you do on your branch is fine. The repo won't explode or anything like that.

You try new things, ask questions, make mistakes, fix them and move on. If you went trough the project's community and liked what you saw, they probably won't have any problems with you making mistakes.

To wrap this up

Contributing to open source can be scary, and it isn't easy. But dividing everything into smaller steps, taking your time and being kind to yourself will take you a long way.

Getting that first PR merged, even if it is a silly small issue is super cool, and knowing that you are helping a project you like is super rewarding. You can do it!