The no-excuses guide to introducing yourself to a new open source project

No readers like this yet.
How university open debates and discussions introduced me to open source

Opensource.com

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:

  1. Figure out where you want to introduce yourself
  2. 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

Introduce yourself

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:

  1. already in the middle of doing a specific helpful task
  2. 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.


User profile image.
Mel Chua is a contagiously enthusiastic hacker, writer, and educator with over a decade of teaching and curriculum development experience and a solid track record in leadership positions at Red Hat, One Laptop Per Child, Sugar Labs, Fedora, and other Free, Libre, and Open Source Software (FLOSS) communities.

4 Comments

Something else to look for is if the project has a dedicated contact point (such as a mentorship list) for people interested in getting started. While small projects won't have that, some of the bigger ones do (precisely because the central development lists for such projects can be an intimidating place!)

Good advices. When participating to open source projects, we get more experience in using tools and codes. Also getting more experience to deal with people and work in a group. You're really going to enjoy it

Great post, thanks for sharing Mel!

Might I add that a forum can be a good place also, to introduce yourself. Especially when there are helpful and active moderators around. They can be an excellent guide also. As a former moderator myself, I always tried to welcome new members, provide them with resources, guide them and by doing so help them introduce to the project I was active in.

Good advice. Really one must first clearly identify the area where one wants to contribute, then half of the work is already done.
and if you know the etiquettes to communicate on IRC then finding a mentor is an easy task.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.