I've wanted to contribute to Open Source Software (OSS) for a while now but always had excuses. What if they don't like my changes? How can I get started if I don't know the code base? What if I'm not good enough? This is also known as Imposter Syndrome and happens to a lot of people. I am not the only one going through this, and you're not either.
However, I just conquered my fears. This past week, I contributed to Open Source Software (OSS) for the first time. I enjoyed it so much that I contributed to a second project only a couple days later. You read that right. I went from being too worried to contribute at all to contributing to two big projects: The open source version of Facebook's Parse, and Microsoft's Visual Studio Code.
Here's what I learned from this experience and how I did it.
Finding the Right Project
Finding the right project is key to having a pleasant and fun experience. I wanted to make sure I contributed to a project I love and use daily. I wrote down a list of some of the Open Source software and tools I often use and the first names on my list were Parse and Visual Studio Code.
Picking an Issue
With that in mind, I decided to take a look at Parse's issues and filtered them by the Good First Task label. Personally, I wanted to start by fixing a bug instead of writing a new feature as I believe it's the best path to a first contribution.
The first bug I decided to grab was just recently submitted and no one had claimed it yet, so I commented on the issue that I'll be looking into it. This is important as you do not want to work on an issue someone else is already looking into, and vice-versa. Make sure to always comment on the issues you are looking into so that the other developers are aware.
Once you're ready to contribute, you should always read the project's Contributing Guide. This is a guideline of what the maintainers expect when you submit a Pull Request. This varies for each project so make sure to always read it.
Getting Started
The first step in fixing a bug, in my opinion, is to be able to reproduce it. It's extremely harder to assert that you fixed an issue when you cannot even reproduce it in the first place. Therefore, after you pick an issue to work on, you need to clone the project and run it locally in order to reproduce the bug. Also take some time for familiarize yourself with the codebase, the project's structure, etc. A great starting point is the project's documentation and Wiki.
Working on the Issue
Once you can reproduce the bug, you can get started on writing a fix for it. Here's what you need to keep in mind when working on an issue:
- Create a new branch for your changes.
- Make sure to always test thoroughly and write automated tests. This improves the chances of having your Pull Request merged and will always be appreciated by the maintainers.
- Make sure your code respects the project's code style and syntax. Most projects will have linters (e.g. eslint), so ensure that your code respects the linter's rules.
- When creating a PR, make sure to write a good description of what the issue was and how it's fixed. This can be in the form of a
before / afterdescription. - Be ready to answer questions on your PR. The maintainers may have some questions regarding your code, which is totally normal. Do not feel offended by it but take it as an opportunity to learn and improve. They will not criticize or make fun of you. They are there to help you succeed, as it's also in their best interest if you continue to contribute to their project. Always keep in mind that they want to help you.
My Second Contribution
After my first contribution, I was hooked. I loved the feeling of seeing my work merged in Parse, and wanted to contribute more. I started looking at Visual Studio Code's beginner issues and found an issue I wanted to work on. I went through the same process as described above (claiming the issue, reading the Contribution Guide, etc.) and my PR got merged on the same day!
Update: VS Code's March release that contains my PR: https://code.visualstudio.com/updates/v1_11#_thank-you
Conclusion
It's an honour and a great feeling to contribute to such awesome projects. I will continue looking for different ways to contribute to these two projects, and possibly many more in the near future. I am also looking forward to writing a new feature for an Open Source project.
I hope this article helps you get over your fears of contributing to OSS. I am very curious to learn about your future contributions or issues you faced while trying to contribute to, so please feel free to let me know in the comments below.
