Another opinionated article on how to start contributing to a large open source software repository

Open source software is like an endless gallery slash painting studio for software developers. You can start painting your own picture from scratch, or you can contribute to a large group of developers already painting a really cool picture.

Maybe you already hang this picture up in your house, and you want to give back to the community that provided you with this beauty you see every day. Or maybe you just want to contribute and be a part of something bigger than yourself.

Ok ok… enough with the painting metaphor. Probably not a good one anyway, but you get the point.

One of the greatest feelings in the open source world is to wake up one morning and say to yourself “I’m going to start helping out”. Then you go to the software’s GitHub repository, and… O_O ←(your reaction). That’s a normal reaction. Do not think that you aren’t capable of contributing to this project. Everybody feels that way initially. I can guarantee you that. Anybody that says otherwise isn’t familiar with the difficulty and complexity of software development, not to mention a large codebase and many developers. It’s hard. And it’s ok to feel like you have to climb a computer mountain.

Many people recommend contributing documentation to an existing open source project, and that’s great if you want to get a social introduction to the collaborators and get your name out there. Documentation is also no doubt one of the deciding factors for the future success of an open source project. But contributing to documentation doesn’t do much to introduce you to the codebase itself. If you have interest to contribute code to a project, the barrier exists even with a successful documentation pull request.

Bugs, bugs… bugs everywhere

The only software without bugs is the one that has zero users. It’s simply the reality of the software development. Take your favorite open source software project. It no doubt has a list (usually a long one) of current unresolved bugs.

My recommendation to start contributing code to a large open source software repository is to concentrate on resolving bugs initially.

There are a few advantages to this:

1. The amount of code to fix a bug is typically (but not always) small. It’s not uncommon to have a bug fix that is a single line of code. This is good because the code review process on your first code PR isn’t as stressful (provided you have actually fixed the bug).
2. The project contributors will be genuinely thankful for fixing a bug. I don’t think there exists a maintainer of an OSS project that wouldn’t be thrilled you stepped in to fix one of the many bugs. I can tell you from first-hand experience that the daily amount of continuous small/medium bugs that arise cause a lot of context switching. From the maintainer’s perspective, the bug itself not only takes time away from current development, but the sole fact that you need to context switch from what you’re currently doing to read a bug report is tough.
3. You will get a great understanding of the development workflow, the codebase itself, and how to debug this particular software. This is the big one, in my opinion. Trying to do feature/greenfield development on a codebase that you aren’t familiar with is anything from stressful, to the upper spectrum of risky. You simply don’t have the time in the codebase yet to fully understand how it all works together. Fixing bugs is a great way to familiarize yourself not only how the machine works, but also with the particulars on contributing code to the project. At this stage of the game, understanding the project is just as important as your code commits. Not to mention, debugging (as we all know) is a skill that isn’t just necessary for fixing bugs, but also new development. Becoming comfortable with debugging this OSS product is a huge win.

Take it a step further

I really wish I could remember who I first heard this from, but this advice is worth its weight in gold when you think about it: when you run into a bug [or in this case, are repro’ing and fixing a bug] create a test that uncovers the failure. This has a few advantages to you, as the bug fix developer, as well as the project as a whole…

• You have reproducible and automated proof of the bug (unit test, integration test, whatever you can code that fits into the testing suite of the software that shows the bug)
• When you make the fix to the bug, you show that this test goes from red to green
• When there are future code changes (i.e. all the time), your test is now solid proof that the future code won’t cause a regression of this bug

Summary

It is no doubt daunting to start contributing code to a large open source project. Focus on a bug. Fix it. Get it merged in. Do that a few times, and I think you’ll find your comfort level with the code gets exponentially greater with each pull request.

Enjoy, and happy open sourcing!