Damien Burks
- Apr 29, 2022
- 5 min read

Lessons Learned: Contributing to Open Source

Updated: Nov 29, 2022

So you want to contribute to open-source projects and don't know where or how to begin? Well, how about I share some of my experience and tips on how to get started contributing to open source.

To start, contributing to open source is extremely intimidating especially if you're new to software development or tech in general. For me, imposter syndrome tends to kick in when I am exploring new things and pushing myself out of my comfort zone. Although I've always yearned to contribute to open source, I've never had to confidence to push myself to make my first coding contribution until earlier this year.

It was definitely not easy, to say the least, but over the past few months of contributing, I've learned some valuable lessons that I'd like to share.

Lesson 0: Identify your passion

Before you begin to look for a project, you need to identify what your passion is. This will help you identify the kind of project that you would like to contribute to. For me, I am passionate about most things cyber security related, with an emphasis on CloudSec and DevSecOps tools and frameworks. This helped me hone in and find projects that align with my passion and current interests.

When you are looking for a open source project, ask yourself these questions:

What am I passionate about?
Do I use this currently (home or office), or will I use this in the future?

Once you have the answer to those two questions, you can start to do your own research and identify projects on Github you'd like to contribute to.

Lesson 1: Read about the history of the project

Before you start to make your first contribution, you need to understand the project. Read the documentation that is on the web page or the git repository, watch YouTube videos, and get to know who the founders are. This is vital information that will help you understand the mission so that you could be a better contributor, especially when it comes to introducing new ideas and workflows.

Lesson 2: Look at current PRs and merge history of the project

This is very (x10) important when looking for a project to contribute to. You want to ensure that pull requests (PRs) are getting reviewed and merged into the main branch of the project within a reasonable amount of time.

I have two examples that I'll discuss to show you the difference between an 'active' and 'dead' project.

Active Project

A great example of an 'active' project is... Open Policy Agent (OPA). If you'd like to read about this project, please refer to their Github repository: OPA

This project has great supporting documentation that will help someone make their first contribution.

Figure 1: Release and Commits

If you take a look at Figure 1, you'll see that their most recent commit and release was yesterday (4/28/2022). Another example of their commit history is listed below:

Figure 2: Commit History to 'main' branch

In Figure 2, you can see how recent the commit history is. In this case, it's almost every day which sets the expectation for a quick turnaround for PR reviewal and feedback. From a beginners standpoint, this is the kind of project that I would recommend to a mentee of mine or someone who is looking to make their first contribution to an open source project.

Dead Project

This was actually pretty disappointing for me to experience. Although I thought very highly of this tool, I'd have to say that Pacu is what I'll consider to be a 'dead' project. If you'd like to read about this project a little more, good luck finding documentation for it!

Just kidding!! Navigate to their Github repository for more information: RhinoSecurityLabs - Pacu

Figure 3: Pacu Commits and Release History

If you take a look at Figure 3, you'll see that the most recent release was May 4th, 2021. This is definitely not a great sign, but let's investigate this a bit more by looking at the commit history to the main branch.

Figure 4: Commit History of Pacu

If you take a look at Figure 4, you'll see a sizable gap into the commit history compared to OPA. Looking at this, you can see that if you were to raise a PR for contribution, it is safe to assume that you may not receive any feedback within a reasonable amount of time.

At this point, you can assume there isn't much activity going on here with this project. So no need to continue any further.

For situations as such, I'd recommend that you find another project to contribute to unless you really like the project. If you want to make a contribution to a project such as this, then by all means, feel free to contribute and raise that PR. It all counts in the end!

Lesson 3: You DO NOT have to write code.

There are several ways to contribute to open source. Based on my experience thus far, most of these open source projects need contributions to documentation. This includes updates or writing new docs for some new feature, which is a great way to learn about the project and it's core features.

If you're not a programmer or someone who may not feel confident with contributing code when you first check out the project, I would personally recommend filtering through the list of issues with a tag such as 'good first issue'. Depending on the project and its popularity, they'll have several kinds of 'good first issues'.

I'll use my favorite project to contribute to so far, Open Policy Agent (OPA), as an example.

Figure 5. Filtered 'Good First Issues'

Take a look at the image above (Figure 5). Each issue has its own tags that give the user an idea of what the project needs help with. In this case, you see a list of issues ranging from feature requests to documentation updates. So if you're not a savvy developer, you can own one of the documentation issues and make your first contribution!

Lesson 4: Read contributing documentation (if any)

I don't know who needs to hear this, but I will say it:

READ THE CONTRIBUTING DOCS!

They are there for a reason. They exist so that you can follow the standards that exist for the project. This documentation will show you how to commit your changes and tag your issues into your pull requests when you raise them in GitHub.

Most of these projects will have complex workflows and automated processes that'll check your code for issues such as linting and formatting. In most cases, information on how to eliminate failed builds and workflows are included in the contributing docs.

So I'll say it again...

READ THE CONTRIBUTING DOCS!

Lesson 5: Help is free - ask for it

The owners and developer advocates of the project absolutely LOVE it when you ask for help.

Do not be afraid to reach out when you're having an issue with the code.

Do not be afraid to ask for clarification.

Do not be afraid to pitch an idea on how to solve the existing problem.

They want you to succeed and make your contribution! Join their slack, discord, telegram, or whatever group they have available! This will help you make the most of our open-source experience.

So are you ready to make your first contribution someplace?

I hope so. Eventually, you'll be included in releases like this:

I hope you found this helpful. Thanks for reading, and I hope my lessons learned will help you make your first contribution(s) to an open source project of your choice.

Cheers!