Getting started in an unfamiliar open source project seems intimidating because it is intimidating; plunging into the unknown usually is. Navigating new territory is a lot easier with a guide—which is why I recently taught a seminar at Hacker School on "getting started contributing to open source" that mostly amounted to "first, find a mentor." The basic steps are:
- Figure out where you want to introduce yourself
- Introduce yourself
There are more detailed walkthroughs of how to evaluate an open source project in other places, but this one is designed to get you to a live person as soon as possible.
Figure out where to introduce yourself
Start by searching the Internet for "a topic that you're interested in" + "open source" or "free software".
Once you've identified a few potential projects, ask yourself:
- Is this project alive? Are code commits recent?
- Are mailing list messages recent and responded to in a timely, helpful manner?
- Are people using this software? (Do you want to use this software? Can you figure out how?)
- Is this a community I want to be part of? (Do they treat each other well?)
The community of people are more important than the code; they’re the ones who make the code, and with release cycles that average 6 months, the code moves so fast that your relationships are what will really orient you.
- Where do they hang out and do their work? (What chatroom—usually in IRC—do they use? Do they have a bugtracker or some other giant shared to-do list for the project?)
Once you find out where you can overhear things, you can figure out who you’re overhearing, and then start contacting them directly: "I’ve seen you answering questions on X; can you help me navigate X?"
Most projects have communication methods for code and not-code, and for asynchronous and synchronous work. Try to figure out all four.
- Synchronous Code: git commits (announced by a bot in chat, sent to a feed, etc)
- Synchronous not-code: chat (typically IRC)
- Asynchronous Code: issue/ticket/bug tracker
- Asynchronous not-code: mailing lists or forum, AND wiki
One of the most efficient ways to introduce yourself to an open source project is to send an email to the developers mailing list, then reference that email (find the URL of your message in the mailing list archives) during initial chat conversations with people.
A collegue of mine, Maggie, suggests submitting a pull request as your intro letter, which I think is a great idea. What this means is that your introduction email should explain how you are:
- already in the middle of doing a specific helpful task
- and what you’re asking for is help doing that specific helpful task.
This may sound daunting until you realize that something useful to help can be very, very small. For example, a few collegues had these experiences:
Rebecca emailed tent saying that she’d been working through their documentation and had ideas for how to improve the clarity of the particular docs at a certain URL (specific helpful task!) and was wondering where to submit her changes (help me do it!).
Jade emailed GIMP offering to test patches (specific helpful task!) and asked which branch and patches would be most helpful to verify (help me do it!).
None of these tasks involve deep knowledge of the code; that comes later. They involved writing in English and compiling C—which is not an impossible thing to learn, especially when you’re surrounded by programmers eager to teach. It's also helpful to pair with someone and peer-pressure (positively!) each other to ship your intro emails.
Hacker School is a three-month, full-time school in New York for becoming a better programmer. It is free as in beer, and provides space, a little structure, time to focus, and a friendly community of smart builders dedicated to self-improvement.
Adapted from Mel Chua's blog. Reposted using Creative Commons.