First-time Open Source Contributor? Here are 5 Valuable Lessons I Learned.

First-time Open Source Contributor? Here are 5 Valuable Lessons I Learned.

Table of contents

No heading

No headings in the article.

You have heard over and over again how open source contribution can exponentially improve your skills as someone who is trying to land a tech role. You might have also come across a YouTube video of someone that landed a remote role by contributing to open source, and you felt so inspired and decided to contribute to open source too. Yes, I felt the same too, yes exactly the way you are feeling right now. The dopamine released from having those green squares in your GitHub profile is so addicting.

Just like everyone else, I frantically went on a hunt for an open source project to contribute to in a bid to fulfill my green squares desire. Little did I know that finding an open source project to contribute to is one thing and doing it the right way is another thing.

Knowing how to solve an issue is great, but that is just one side of effectively contributing to open source. In this blog post, I will share with you 5 things I learned while trying to satisfy my craving for those green squares, and I hope it helps you too on your quest to become an open source ninja.

In no particular order

  1. Always look for these two files, README.md and CONTRIBUTING.md. MD stands for “Markdown Documentation”. These are formattable plain text files that can use particular inline symbols. (If you want me to write an article about some of these symbols, kindly comment below). The README.md and CONTRIBUTING.md files contain important information about the project, sometimes the use case of the project, and most importantly guidelines on how to contribute to the project. These rules have to be adhered to strictly, or else your contribution may not be merged or completely ignored in the worst-case scenario.

  2. Do not jump the gun. Always ask if an issue is still open or is already assigned to someone. Time is precious, you do not want to waste your time, and you also do not want to waste the time of the project maintainers. You do not want to build your dream home on a parcel of land another man owns, or else you will have the cops after you. This may also cause conflicts along the way.

  3. Do not be all over the place. Work on one thing at a time. You need to remember that open source projects have maintainers, and you are about to make the life of the maintainer a living hell if you do not stick to one thing at a time. When working on an issue, make sure you strictly work on that issue to its logical conclusion. If you find something else that you would like to work on that is not related to the issue you are working on, you can open an issue later and get it assigned to you.

  4. Keep the configuration of the project intact. We all have our preferred package managers and frameworks. I prefer using yarn as my package manager. Let me tell you a short story about keeping the project configuration intact. I was assigned a feature of implementing dark mode to a project. NPM was the package manager used for the project, remember earlier I said I preferred yarn to NPM. I implemented this feature, created a branch and pushed my changes to the branch on my forked repo, and waited excitedly for my PR to be merged. Guess what, I got a message from one of the maintainers asking me to please stick to the original package manager which was NPM as switching to yarn might cause problems in the future.

  5. Be polite and accept feedback. Do not be reactive. Yes, you might have worked hard to fix that issue or implement that feature, but you need to understand that no man is an island on his own. A tree does not make a forest. No one knows it all. So relax and look at the feedback from a positive point of view, there is something you can always pick from feedback.

Contributing to open source is a great way to improve your tech skills and show off your expertise. To maximize the value of open source contributions, it is important to follow critical guidelines, such as adhering to project guidelines, focusing on one issue at a time, and being open to feedback. In keeping these in mind, one could become an open source ninja and gain valuable experience in the field.