Part one of two articles focusing on getting potential new contributors involved in the free open source community.
I’ve been using open source software for about ten years now. Of all the time that I have been using it, for one reason or another I don’t recall ever thinking about contributing. I didn’t know anything about programming operating system kernels or device drivers; I wasn’t really equipped to help write compilers; and more than anything as the years went on — programming became a job. So for years I happily ran my favorite distro and used all the open source applications I needed and never gave anything back.
Well, I finally got a little bit of the open-source guilt a few months ago. I decided that I had enough experience and skill that I could and should finally give something back to the community that had produced so much for me and everyone else to use freely. The only problem was: where do I start? I wanted to abate my guilt and give something back but when I started thinking about how to do that, the task seemed enormous! There’s so much choice!
Eventually I just picked a small tool I wrote in an afternoon and rolled with it. I learned quite a bit along the way and I want to share it with other people interested in contributing for the first time. There’s a lot to digest and I hope to provide a gentle introduction to get them (you?) on their way. And don’t worry if you’re not a programmer! Many projects need help from people with other skills such as writing, design, and community management. So without further adieu…
I found this to be one of the hardest parts! Around 90% of the software I use today is free open source software (advanced readers beware that I’m skipping over the pedantic differentiations for now). How do you choose which project to contribute to? Which ones need your help and how do you tell? There are so many websites that try to index the plethora of software out there, but it’s the mass of information that is a hindrance! I found it to be too overwhelming.
Choosing an area of interest is the first logical step, but don’t expect it to be the only one. There is a plethora of software available and sometimes even the most niche topic can already have a handful of projects to choose from. This can make things a little frustrating for potential new contributors (it did frustrate me a little). It’s possible to spend hours browsing sites like Ohloh, Freshmeat, and the eponymous Sourceforge for just the right project to join. But try as you might, don’t expect to find, “that one” just by browsing.
The next logical step in choosing a project to work on once you’ve found an area of interest is to get a feel for which projects could use some help. Many of the indexing sites I mentioned above maintain links to the project home pages, issue managers, and source control systems. You’ll want to browse the issue managers to get an idea of what kinds of problems the project is facing and whether you have the skills to solve them. Web servers such as Apache are already well established and the kinds of issues you find there will probably require someone very skilled at tracking down obscure bugs or performance dilemmas. Whereas in a younger or fringe project you’ll find more feature requests to fulfill and chances to experiment with adding your own ideas.
So in choosing a project you’ll want to first settle on an area of interest. Then you’ll want to find out which kinds of issues a project has. Finally matching up your skills to the project that fits will help you narrow your choices down to one or two. The next step is to get in touch with one of the project members and get to work!
If you have a tough time choosing (as I did) then another option is to start your own project. Starting your own project is a little different than working on one. For one, you’ll have a little more responsibility and spend a little time wearing a few different hats than you’re probably used to. You might need to play the role of manager and juggle that with the role of marketer and software developer. Of course, it’s your project so you get to choose how much time (if any) to wear those hats, but that’s the beauty of it. Your choices are more dictatorial in nature!
However, starting your own project is another business entirely suited to its own article (which will be part two of two). In the meantime, the best way to start is to choose something you’ve already built that you find useful. Trying to think of something unique and starting from scratch can lead you down a never-ending rabbit hole in search of the perfect idea that no one else has thought of. Your best bet is to stick with something you like and take it from there. Free open source software is generally a labour of love, so you might as well do something you like.
Some people more than others will find this step a little tough. How do you approach the developers of a new project? What do you say? What if your contributions aren’t up to snuff? Rest your fears aside! Even the few curmudgeons within a community generally mean well in the end. We’re all here to build something great!
Once you have set your eyes on a project you want to contribute to, you should have a fairly good grasp of the issues in their issue manager. You might have even taken the extra step of checking out their source already and gave it a skim over (and hopefully didn’t cower in fear or roll your eyes in disgust). You might even have an idea of what issues you have your eyes on. But wait! You don’t have commit privileges! How will your patch get in?
Most projects have some sort of version of St. Peter standing at their pearly gates. This is usually the project maintainer/founder but in some larger projects may be a dedicated person whose job is simply to manage issues, mailing lists, and who gets the keys to the gate. While you may be eager to jump into the code or start adding sweet graphics, it’s generally a wise idea to at least remember to send this person an email. Just say hello, tell them you’re interested in their project, and even which issue you’ve decided to work on. Becoming friends with this person will make becoming part of the “group” much easier.
While there is no general rule, I find it’s most polite to start with tackling bugs and things first. You won’t get commit privileges to the project’s repository right away without showing first that you can work in a team and later that you have some skills. Even if you’re not the greatest programmer, artist, or writer to have walked the Earth; if you show you can get along well with others, there is generally someone that will help you along and get you involved. The free open source community is built on the inherited altruism we all share after all.
So once you have contacted the project maintainer or one of the team members, you can start submitting your patches. Different projects will do this in different ways and if you’ve met a very friendly and active maintainer, they may give a run down on how their process works. In general, most issue managers will let you attach files to a ticket which is what you should use to submit your contribution. You may get a response asking you to go back to the drawing board or improve it in some way first but that’s okay! Just follow the suggestions and submit again until you get it right. At some point your contribution will get accepted and you can sit back with a smile! You just became an open source contributor and did good for the world.
Keep contributing. Send patches. Create documentation. Share a little of your experiences along the way. Participate! Eventually someone might give you the keys to the gate and you can start accepting patches and submitting code directly to the project repository. Further down the road you might find yourself meeting your fellow developers at a conference or be lucky enough to be asked to do a presentation! The free open source “movement” is a big community and being a part of it is a huge advantage to both you and the world at large.
All the best!