Overview
From time to time I am asked how somebody can get involved in open-source software. Eventually I decided to write something down. At present this is pretty unpolished, and it is based on my specific experiences, which are not universal.
Suggestions
I it's important to understand that "How can I select the right open-source project for me and successfully join up?" doesn't have a closed-form answer. Other questions that also don't have closed-form answers include "How can I get hired into a job I will like?" or "How can I find a lifelong spouse?".
Inventory what you use
In many ways, contributing to some open-source project is unlikely to work without being an enthusiastic and expert user of that project first. So a good first step is to inventory the open-source code you are currently a consistent/heavy/proficient user of... if that list is very short, changing that might be important.
The Cathedral and the Bazaar
If you haven't read Eric S. Raymond's essay The Cathedral and the Bazaar, that's probably a good step to take. The author is somewhat controversial, and over the years people have criticized various parts of the essay, but if you haven't yet read through an organized explanation of how open-source projects work and why, it's arguably good to read this. Not everybody agrees with it, but a large fraction of people in open source leadership have read it, understand the ideas, and have opinions formed at least a little bit from it.
Humility
A massively-important ingredient is humility:
Except for a giant commercially-relevant project (e.g., Lustre), everybody working on an open-source project is a volunteer: users, testers, document maintainers, build-system maintainers, UI designers, release engineers, bug triagers, reviewers, committers... the people who write the code, sure, but everybody.
When you arrive, by definition you won't know: why the build system is the way it is, what the procedures (testing, review, release) are, why the procedures are the way they are, etc., so showing up and explaining that the project is doing X wrong and that you know the right way to do X isn't going to work at all.
Read
I suggest you start by reading a lot. Read the online mailing lists or forums –- without posting –- for a good while, like two weeks or a month. If your first post is a request for help or guidance, aim for your request to be the best one that has been posted in the previous two weeks (most clear, most detailed, most carefully checked, etc.). Otherwise, a good first post would be helping somebody else solve a problem that you 100% know the answer to.
Read documentation like mad: official documentation like user guides, but also the FAQ on the web site. Reading some code is good too.
Languages/tools
Make sure you're good at whichever language(s) the project is written in. If not, maybe improve your grasp of a language by finding a solid book about it and reading the whole book. For example:
- C
- The C Programming Language by K & R, and/or A C Reference Manual by Harbison & Steele.
- Java
- Effective Java by Josh Bloch
- JavaScript
- Eloquent JavaScript by Marijn Haverbeke
Experience
Figure out how to build the project from source. This may take some time!
Arguably figure out how to run it in a debugger (this may not be easy).
If relevant, buy a spare piece of hardware for running a debug (non-production) version of the software. If relevant, maybe buy hardware tools that assist debugging.
Doing something
When possible, pick something to work on that:
- is already on the project's issue tracker,
- is marked as being somewhat of a priority,
- is not in a mission-critical component, and
- has sat around for a while.
Subject to that, pick something that is as small as possible.
Blend in
Proposed code should blend in seamlessly with existing code. Resist any urges to improve the way the code looks. Absolutely resist any urge toward whitespace rampages, "fixing" variable names, etc. Comments should be clear (but not dramatically more verbose than what's there), variable names should be carefully chosen, etc.
Pull requests
Be prepared to spend vast amounts of time when submitting a pull request, so that that a volunteer reviewer (who is busier than you can imagine) can quickly review it. Squash your commits in accordance with local practice; be prepared to rebase in accordance with the project's release schedule, etc. Study the format the core developers use for commit-log entries. Getting code in doesn't require just good code; it requires solid testing, and making the reviewer's job easy.
Be prepared to wait weeks while the busy volunteer reviewer is too busy to review the pull request. Absolutely do not agitate before two months have passed. It might even happen that a pull request waits multiple years to get reviewed and merged (example). In general, contributing to open-source projects is not a recipe for instant fame and fortune. Some people do achieve one or the other, but often it's people who have been working at it for a long time.
Expect your first pull request to be rejected (this is 95% likely).
Overall, submitting a pull request is more likely to be a marathon than a sprint, at least the first time.
Conclusion
Good luck! Write great code!
