If you’ve considered getting involved in open source software development before but didn’t know where to start, keep reading.

Even before you get down to it, the first thing you must consider is what sort of task you would like to do. The second is contemplating your skillset. Do they match up? If not, you might have some learning to do.

If you aren’t a programmer and have no idea what else could possibly need to be done, here are a few ideas:

• Artists are needed for making themes and wallpapers for Linux distros and desktop environments like GNOME & KDE
• Make little tiny icons for programmers to put on the buttons in their programs
• Translating a program from English to whatever other language you speak
• Writing documentation (no project is too-well-documented)
• Tech support
• Testing is a great way for early adopters to help out
• Bug triaging
• Packaging software for a Linux distro

Most of these may sound straightforward at first, but they all have at least some learning curve. Once you’ve established what you’re interested in pursuing, the tough questions start.

If you’re an artist, what other things do you need to learn to contribute to open source? Well, do you know how to use Inkscape yet? Inkscape is a very popular vector graphics editor that’s great for making icons that scale well. Depending on the project you wish to contribute, you may also be expected to learn about icon standards for the project. For example, the Tango icon theme guidelines are a Free Desktop standard, so it’s a good idea to make yourself familiar with them. If you’re making wallpapers, both GIMP and MyPaint can be very useful as well.

Are you considering translations? Different projects handle this aspect very differently. Most open source projects use .po files to specify translations, but not all. You can create .po files directly with PoEdit. Projects hosted on Launchpad may use Launchpad’s Rosetta web application to accept translations (though these are still .po files in the backend). And then there’s Qt which uses .ts files instead of .po files, edited using Qt Linguist. Not all Qt programs use .ts files though. Some, like Quassel, have found ways to use .po files in spite of being Qt.

Have you considered updating the wikis? If you’re good at explaining things and want to write documentation, many projects have wiki pages that could use some updates. And don’t forget about help files! In many instances these usually need some love, too. Depending on the project, the tools you’ll need to know how to use will also vary. For GNOME, Mallard is the format used for help docs. For many others, it’s DocBook, an XML-based documentation format that can output PDFs, manpages, webpages, and others. Then again, maybe you want to give a bit more one-on-one help? If so, many projects have IRC channels on FreeNode or have messages boards where users come for help.

Have you considered being a tester? If you always liked to play with the newest bleeding edge code, even before its final release form, and you don’t mind when it breaks, why not try you hand at being a tester? Just keep playing with the latest code as you normally would, but make sure you report the bugs you find. Some projects will have nightly builds to make it easy for you to install the latest stuff. For the ones that don’t, you’ll have to learn to use a version control system (ex: bzr, cvs, git, hg, or svn) to check out the source code.

Whether you’re testing or triaging bugs, you need to learn to use the project’s bug tracker. Debian BTS is modified through email, but Debian has the command “reportbug” to make sure necessary information like package versions are included. Ubuntu’s equivalent is “ubuntu-bug” but it has a web interface on Launchpad. Lots of other projects use Launchpad as well. Bugzilla is probably the most common bug tracker you’ll find. GNOME, KDE, and Mozilla all use it, and it does a good job of asking the reporter relevant questions so that the report is useful.

What about bug triaging? Bug triaging means getting a bug report to the point that a developer can sit down and fix it without having to ask any more questions. At the most basic, you need version numbers and exact steps to reproduce the problem. If you can reproduce the bug, good! But then it gets more complicated. You’ll probably have to become a bit of an expert in whatever software you’re triaging bugs in order to identify what could be going wrong.

How about packaging? Packaging means taking a bundle of source code and turning it into something a user can install. For Windows this would be a .exe, for OSX a .dmg, and for Linux it could mean a .rpm or a .deb. It could also mean a Python Egg. Each of those will require learning a different method. After a while, you’ll learn “recipes” for how to package things. Programming experience is helpful to figure out if applying a patch is a good idea, but most patches integrated at the package level should be fairly small or coming from upstream (and thus already vetted). A bit of shell scripting and an understanding of the patch command are a minimum.

OK, so that covers many of the non-code things you can do, but what if you are a programmer? Well, many projects will have smaller tasks that need to be done that’ll help you become familiar with the code base. KDE calls these Junior Jobs. Ubuntu calls them Bitesize. Ask around in your project.

And some more tips:

• If you’re trying to find a project that needs help with your skills or want a bit of a search engine for small tasks to start out, you might want to join OpenHatch, a tool for matching up open source projects with contributors. It matches your profile and skillset to projects where those skills are needed. Very handy!
• By the way, if you’re a university student and can code, you might want to consider the Google Summer of Code. You get paid to design and complete an addition to an open source project, and you have a mentor within that project helping you along the way.

Ever thought about getting involved in open source software development? Do you have any tips to share? If you’ve thought about it but not done so, why not? Were there barriers you saw that you think need to be broken down?

Tags: open source