Contributing to open source software is a difficult and rewarding process. Contrary to popular belief, it does not require a lot of programming skill, but rather patience, creativity, and diligence. In this post I will explain some crucial steps and skills which even experienced contributors sometimes forget. This is not a magic formula, and contributions will require focus and work, but in the end I believe the feeling that you are part of a community and that you have contributed to something greater than yourself is personally fulfilling. It is also an accomplishment employers like to see and even many non-technical people will respect.
The Open Source community is has a reputation of being hard on newbies. I think this reputation is generally ill-deserved. Sure, some of the big names get a bad rap, but in my experience people who have small projects will be ecstatic about your contributions. And I mean Exclamation Points! and merging code before you think it's even ready. However, there is a rotten apple in every bunch, so don't be afraid to stop, close your pull request, take a breather, and try again somewhere else. Sometimes I've realized I'm in over my head, but in retrospect those failures to have been my most valuable learning experiences.
Maybe you already have a project in mind. That's great! Skip to the next part, but you may find the project isn't everything it seems at first, so don't be afraid to come back here.
Is this project worth my time? Here are some quick ways to find out.
NOTE: Include pictures and links.
- When was the last commit made? If nobody has touched it in a month or so, it's probably abandoned.
- How many pull requests are open? If there are 100 PRs open there is no hope that they will all get merged, and it's best to spend your time somewhere else.
- How many forks does it have? Too many forks may mean that the project isn't really maintained.
- When was the last time a PR got merged by someone who isn't part of the core team.
That's a lot of questions, but GitHub's tools make them easy to answer.
A lot of people think that the most valuable open source contribution is code. They have been mislead. Most projects lack the most basic documentation. Other projects are in need of a good logo, so if you're a photoshop wizard it might be cool to bounce a neat design off the author. A good way to see if you want to contribute to a project is to read the README and set everything up. Usually the directions are vague, inaccurate, or specific to a certain operating system or package manager. If you run into problems reread everything. If you find something to fix and improve, go ahead and submit something, even a one line change which says something like:
If you're running Ubuntu, install the libxml2 package:
`$ sudo apt-get install libxml2`
Always remember to run a spell checker on your work. It makes it much more professional-looking.
Look for bugs labled "help wanted", "easy", "low priority", etc. Hop on IRC and ask the owners! Ask the owners what they want fixed. Grep for TODOs or FIXMEs, they are sometimes one line changes, or things like "fix this regex, it matches too much".
You're comitted now. If it's a little change, get in, get out, make the change a little as possible. Don't touch things other than the bare minimum which needs to be fixed. Play the game "what is the smallest number of lines I need to change to fix the bug". It's like golf.
If it's a big project it's time to spend an hour with the debugger. Don't be afraid, it will all pay off. Once you've fixed one bug and understand how the project is laid out the second and third will come much easier.