Why and how to contribute to open source projects

Feelings after two months contributing with two different open source projects.

Edigleysson Silva
7 min readDec 13, 2021


Think of a group of developers working on a product. These developers are distributed around the world, the product they are working on is a really big piece of code, all these developers are volunteers and finally, the resulting product is free to use, share and modify.

The above description refers to Open Source Projects. You have probably used open source software to some degree in your life. Either by using a product that was built using an open source programming language like Elixir, Rust, etc, or even using the entire end product like Android OS and Linux OS.

The open source projects mentioned here are very large and impact many companies around the world. Think about it, there are a lot of developers working on a product, these developers don’t know each other, they don’t have meetings every day or every week, nevertheless, they provide high-quality software.

There are a lot of interesting things to talk about open source, but for today we will talk about the benefits of contributing to this type of project. So stay with me and let's talk about these benefits.

NOTE: There are different ways of contributing. In this article, we'll focus on contributing by Pull Requests.

Reason 1: You will help to make something great

There are a lot of open-source projects at GitHub, it doesn't need to be a big product like an Operating System or even a complete software product. We can have small components like libraries which are often used in our days. In each area, we have a lot of libraries.

In Flutter, for example, we have libraries for making HTTP calls, handling animations, and so on. The same happens in other ecosystems, we have very libraries to work with Python, Rust, Elixir, and so on.

I mentioned big projects in the introduction (like an Operating System), but keep in mind that even the largest software product in the world is composed of very small components.

By contributing with these small components you'll also be doing something great! You'll make a difference. Have you found a bug in the date/time library you are using? Consider solving it and everyone who uses this library will be happy and grateful for your effort.

We'll see how to do this later in this post. Keep going.

Reason 2: Skills improvement

By contributing to open source projects you will have the opportunity to receive reviews from one or more developers that could be more experient than you, even if they are not, you’ll at least get to know, through reviews, different styles of programming and troubleshooting software.

You’ll be working in a different context with different needs, this means you'll be completely out of your comfort zone this will make you grow as a software developer.

I have learned many Vue concepts from contributing with Buefy. I have learned a lot of new things I didn't know about events, component lifecycle, mixins, and so on.

This is an excellent experience to have. You'll naturally become more critical of your own work and more careful about your craft.

Reason 3: It will contribute to your portfolio

To explain what we mean by portfolio, let’s look at the following quote.

We like to think of all the fact programmers know about computing, the application domains they work in, and all their experience as their knowledge portfolio.

This quote is taken from The Pragmatic Programmer’s book by Dave Thomas and Andrew Hunt. I agree with this description. Personally, I like to call it the developer’s toolbox.

By contributing to open source projects, you will increase your toolbox. Depending on the project you are working on, you may not only learn new programming techniques, but also learn about new libraries, or even a new programming language.

In addition to all the mentioned experience gains, you'll be better seen by headhunters and potential contractors. Imagine yourself in an interview saying that you contributed to a library (or something else cool). It’s cool and even a little impressive, those are two sensations you might want to instill in your interviewers.

How to contribute with open source projects

I have contributed more periodically with two open source projects which are Buefy (https://github.com/buefy/buefy) and Punchclock (https://github.com/Codeminer42/Punchclock/). The first one is a Vue library and the second one is a kind of timesheet written in Ruby.

I've learned a lot of things, for example, before Punchclock I had never done anything using Ruby, I actually chose Punchclock to learn and practice Ruby and Rails.

As I did, you can also do. Starting in the next section I'll share with you how I started to make these contributions. Keep going.

Find a cool project

Think about a library you're using today. Supposing you're working with ReactJS you maybe have been using Axios to handle HTTP Requests.

You can find the Axios source code on Github check it out https://github.com/axios/axios. You can also find the ReactJS source code at https://github.com/facebook/react.

As you have seen, you can find many projects on GitHub. Think of a library/product you would like to contribute, it will most likely be on GitHub then go and find something cool to work on.

Where to start?

What can I solve/improve in the project? You can do literally everything to help. You can report a bug by creating an ISSUE, you can fix a reported bug, increase the test coverage, redesign some part of the application to make it clearer, and so on.

Reporting a bug is the easy part and we should do it as we find them. If you can, solve it. Solving reported bugs is a great way to start to contribute because in most cases these bugs are well described and a good context is given, then you can perform tests, fix the bug, and validate based on the given context.

As you get comfortable with the project you're working on you'll find other things to improve.

The Github flow

First of all, you need to create a fork. A fork is like a clone of the project by creating a fork Github will create a repository, like the one you've forked from, in your account.

In my account, I have the repository https://github.com/geeksilva97/buefy. If you open this link you'll see something as shown below.

Image 1 — Buefy fork

Note the forked from buefy/buefy. To fork a repository on GitHub you only need to click on the Fork button in the right corner.

Once you've forked the project you can now start working on it. All your work should be made in your fork following these simple steps:

  1. Create a new branch from main;
  2. Make your changes;
  3. Submit a PULL REQUEST.

Some projects may have variations on these steps. Make sure you read the files README.md, CONTRIBUTING.md, and CODE_OF_CONDUCT.md to know how to contribute.

NOTE: These files aren't mandatory, but are very common.

The complete flow is almost the same across repositories. To get more details and see what commands you can use check the CONTRIBUTING.md of Punchclock at https://github.com/Codeminer42/Punchclock/blob/master/CONTRIBUTING.md.

The process in practice

In this section, we'll see how is the process of submitting a Pull Request and getting it merged, or not, sometimes we lose. Actually, it's not a loss, even not merged Pull Requests can teach us interesting things.

A bit about software projects

Keep in mind that there is no democracy in software projects. Despite the product/library being built by many people around the world, there will be a small group that will guarantee the integrity of the repository and will decide what should be merged or not. Accept this as an axiom and don’t let it hurt your ego.

The big game here is to convince the owners of the project that your proposed changes deserve to be merged into the main code.

Opening the Pull Request

Once you made your changes it's time to open the Pull Request. By opening the PR you should follow the requested practices of the repository you're submitting on. In the Buefy we should indicate if our code solves a specific ISSUE and describe the proposed changes. The good practice is to give as much context as you can.

In the following image, we can see a Pull Request opened for Buefy.

Image 2 — Pull Request example

This is a merged PR, but it is sufficient to illustrate the practices we mentioned. This PR was a refactoring of two components and the context was given using images also.

Get review (convince the owners)

Once the PR is opened you just need to wait. Wait and the game will begin.

Image 3 — PR conversation

At least one person will review your code and check if that makes sense. Reviewers will request changes and suggest improvements when they deem it necessary.

Be polite, explain your decisions, and follow the suggestions when that makes sense. Sometimes the reviewer's suggestion doesn't make sense, it is quite common when a new feature is being introduced.

In Buefy is very common to see owners asking the following question "Why do you need it?" with this question the owners aim to understand what needs your PR solves. The owners are not omniscient, so they should ask to get to know about the users' needs.


Making open source contributions will help you to grow up as a developer. Again, don't let questions and code suggestions hurt your ego, be open mind and learn.

As you get more confident you'll start to review the code of the other developers and this is also a good thing to do.

If you liked this content, please consider clapping this post 👏🏽 and share it with your friends.

That’s all. See ya!