If you’re anything like me, then you’ve been using open source projects for years. You love them, you know them, and you want to help them. But you aren’t the fastest programmer, or the smartest, and you’ve finally gotten to a point in your life where you’re okay that someone, somewhere, is going to be better than you at everything you do.
To this I say congratulations, because now—at last—you’re ready to start contributing to open source projects. To help you out, here are a few of the things that I’ve noticed that have been immensely helpful for me as I’ve started to make the transition from power user to contributor.
Start with the bugs
Contributors to open source projects are like Tom Hanks in the movie Cast Away. No matter how much help you get from the mailing list or the chat room, you’re still ultimately going to have to figure stuff out for yourself. This is a challenge, to be sure, but the good news is that you don’t have to work it all out on your own—it is an open source and collaborative project, after all, right?
So, very often, the best ways to start contributing is by sending bug fixes in as patches, the smaller the better. I think my first bug fix to an open source project was like 3 lines, and all my first contributions to subsequent projects have been that size or smaller. Surf to the issue tracker and cruise over to all the bugs in your down time, read them and work through the process of reproduce, fix, and test. Lather, rinse, and repeat until you have a patch to contribute.
Atomicity helps here, which is to say you should be certain to contribute one patch per bug fix. (Don’t send a single patch that fixes 10 unrelated bugs. That can be extremely difficult for a project maintainer to review.) Sure, bug fixing isn’t a glamorous contribution, but you’d be amazed how appreciated it is. Seriously, nobody likes bugs, so you can easily become an unsung hero for one of the core developers if all you do is ruthlessly cull the bug list.
Speak with results, not with possibilities
There are lots of times when it pays to discuss things on a mailing list before you go and lay down code for them. However, if you’re just getting started contributing to a project and your changes are relatively small and simple, you’re much better off just implementing them and sending in a patch. Once you have code to explain what you mean to do, then discussing it with the project at large can get you places.
There are a few reasons for this, but the primary one that’s impacted me is easier communication: many people use the same words to mean different things, and this makes communication about code in a human language (typically over a mailing list with hundreds of people living in countries all over the world) really hard. In comparison, (most) computers will treat your code in the same exact way. This means it’s much easier to talk to the community using the project’s own code than it is likely to be for you to get all the terminology correct in a mailing list message or a chat room.
Do things their way, not your way
This should be obvious, but I often see other people making this mistake so I’ll mention it anyway. When you contribute to a project, you really, really, really should pay attention not just to what the project is doing, but also how they’re doing it. This does actually require a bit more observation on your part than you might think at first, but it’s still not that hard.
If the open source project were a planet, then when you start contributing, you’re still an insect in its world. (That’s why you’re starting with the bugs, remember?) Quite simply, match the coding style of the project. Figure out what the preferred way to report bugs and to send patches are. For goodness sake, RTFM (no, really, read it—twice if you have to).
In many cases the project’s developers will have already spent hours trying to make all of this information available to you somehow, so it can be really demoralizing for them (and ultimately for you, too) if you don’t take advantage of it. Now admittedly, many projects don’t do this very well, but they have tried. In fact, if you think you can make the information more easily available, perhaps by fixing the grammar, correcting typos, reorganizing a wiki page, or whatever, then contribute!
Leave your ego on your side of the screen
Y’know office politics? Well, sometimes, open source politics can make office politics look like child’s play. It’s kind of a tragedy, actually, but it’s true. And all the poison stems from people’s egos. The maintainers of all the best-run projects remove negative emotion and ego from their mailing list messages, and are quick to defuse ego-filled situations.
As a contributor, this means you should do your best to do the same. Do not—do not—lobby for the inclusion of a particular piece of code, bug fix, feature, extensions, plugin, whatever, just because you wrote it. Seriously. Do not do this. In open source projects, your only currency is your reputation, and you’ll be doing yourself a lot more harm with your ego than you’ll do good with your code.
If you feel really strongly about something, you can always just fork the code base and do your own thing anyway. However, even better than that, try to avoid fragmenting the community and just maintain your own branch locally, and then freely share your patches amongst the people who care about it. (And if you’re not yet using a distributed version control tool, this is a major reason to learn one, like git.)
Acknowledge your strengths and your weaknesses
For a long time I completely shied away from areas in a project where I knew my skill was subpar. This was actually really stupid because it cut off one of the best opportunities I had to improve said subpar skill. I stopped doing this when I started looking at bugs in areas of code bases I was unfamiliar with and, guess what, I got better!
When you’re working in areas in which you are not an expert, it’s easy to become defensive about your lack of skill when you know you’re going to be reviewed by people who know more than you. It’s intimidating, and stressful, yes, but it’s also an amazing learning opportunity. That being said, you can’t just expect to jump into open source projects as a way to lazily get an education. If anything, I contend that learning with this method is way, way more reliant on your own initiative and effort than formal schooling is because, again, no one’s going to (nor should they) hold your hand.
It’s also exceptionally difficult because, since it’s open source, you’re essentially making your lack of expertise public knowledge. It’s not easy to admit having flaws in some areas, and it’s naturally even harder to do so in public. But again, when you can do this well, then you’ll also be able to garner the immense benefits that come with coding (and screwing up) in public, including greater creativity, better experimental branches, and a faster learning curve. (Once again, I think Git is a fantastic tool for this.)
Conclusion: treat others the way you would like to be treated
As I look over much of what I’ve written here, what strikes me more than anything else is that nothing here is specific to open source software development, except the terminology. All of this is, in fact, much more relevant to the every day living of one’s life. So, as you should do in code, do in your life: identify the problems, focus on results, hone your communication, and make bettering your own process an integral part of your process.
After all this, well, I guess I should should get back to work now. :)