Welcome to...

If you use open source or free software, you may feel that since you're getting all this software and support for nothing (or almost nothing) that you'd like to give something back in return. There are many ways to contribute, so let's take a look at a few of them.

Reporting Bugs

The first and most obvious way people can contribute, with little technical knowledge required, is to tell software developers about any problems found in their software. For example, if you find a particular piece of software difficult to use, that's a bug and can be reported as such.

Developers like nothing more than a well-crafted and well-researched bug report. The first step is to find the right place to report your bug: there may be a special bug-tracking system to which bugs can be posted; there may be a mailing list for bugs or the developer may prefer to receive direct e-mail about bugs. Read the website of the piece of software concerned to find out where bugs should be reported - if you choose the wrong place, your report may never be read.

The most important thing to do when reporting a bug is to include useful information. Generally you need to say what part of the software the bug applies to; what happens when the bug occurs; what you expected to happen if the bug hadn't occurred; and step-by-step instructions for how others can reproduce it. Developers will often ask you to provide more detailed information to help them track down the bug so you should be prepared to do this - if the process is complicated, they will often provide step-by-step instructions so you needn't worry about getting out-of-your-depth. Developers can often appear fearsome since they tend to get impatient with an endless stream of bug reports which consist of 'The widget is broken, what's wrong?' and no actual useful information, but if you provide good bug reports they'll do everything they can to help you and get the problem resolved.

Helping People

One of the main resources the community has is people: if you have a problem with getting something working or need some advice, there are plenty of people you can go to. There is of course the Micro Mart forum, where you'll find plenty of knowledgeable Linux users ready to help, newbie forums such as linuxquestions.org and of course your local Linux User Group (see lug.org.uk for a list) who will have a mailing list and probably regular meetings too. Once you start asking questions and start learning, you stop being a newbie and start accumulating knowledge which you can pass on to others. The eagerness of everyone to help each other out is what makes the community work as well as it does.

Writing Documentation

Documentation is something all developers hate doing because it takes time away from what they enjoy - programming. If you know how to use a piece of software, there's no reason you couldn't help out by writing documentation to tell others how to use it. Documentation doesn't have to be technical, it just has to be easy to follow for new users - if you're a new user yourself, you're likely to have a much better idea about what new users can follow than the software's developers.

Creating Artwork

If you have graphic design skills, there is a lot you could do to help the community (and yourself, too). It seems that programmers don't usually make great artists, so there can sometimes be a lack of nice icons and graphics within open source software. Creating icons or other graphics is a good way to contribute to the community and if you're a professional graphic designer, a good way to expand your portfolio.

Writing Code

If you're a programmer, you'll find no shortage of software projects that could use your help, no matter which languages you know. The best place to start is to choose a piece of software and look at the reported bugs. Choose one which sounds like it's a simple fix and have a go - you can always ask for help or advice if you need it. Once you start becoming more confident you can start contributing bigger bug fixes and maybe even new features. It is important to know how the developers like to receive code and where they like to receive it - some projects have tracking systems, some use a mailing list and some prefer direct e-mail. It's quite possible that some of your work will not be accepted by the developers - don't be afraid to ask why if they don't tell you at the time. Developers may be somewhat picky about what they'll accept and you may have to provide your code in a very specific form, but don't be discouraged by this.

Whatever you feel you can contribute, there's a whole community out there ready to jump in and help you get started. Some will give encouragement, some will help you learn and some will even give you money if you're contributing something especially useful. Everything you contribute can be of benefit to thousands of people around the world so even the little things can make a big difference.

How I Contributed To The Linux Kernel

At the heart of every operating system is a kernel - the part of the system which does the real work of supporting the hardware and allowing your applications to run. The Linux kernel was originally written by Linus Torvalds working alone on his 386. Today, there are many people who contribute to the various parts of the kernel and there's no reason that anyone with the ability to program in C cannot contribute as well - the whole idea is that it's an open process. The kernel is divided into different sections, each of which has someone designated as a maintainer. For example, the Serial ATA support within Linux is maintained by Jeff Garzik so if anyone wishes to contribute some source code which improves Serial ATA support, they would send it to Jeff who would decide whether to accept it or not depending on the quality of the code and whether he feels the changes it makes are useful. Above the maintainers is Linus, who has the final say about what goes in and what doesn't.

Last year I purchased a digital TV card and was somewhat dismayed to discover that there was no support for it within Linux, nor were there any indications that support would be added soon. As a pretty average C programmer and someone who definitely doesn't understand the low-level goings-on of a digital TV card, there was no chance that I would be able to write a driver myself.

The digital TV drivers in Linux are not managed by a single person, but by a group of developers who form the LinuxTV project. My first course of action was to search to see if anyone had attempted to add support for the card before, or if any others had requested support for it. I was rather lucky to find that someone had previously attempted to add support for the card and had sent a patch to the project's mailing list. The patch however had not been accepted due to there being some problems with it. A patch is a file which contains details of the differences between two files - in this case, the file contained the difference between a file which had support for similar cards to mine and the same file with support for my card added. All contributions to the kernel are made using patches, since it allows people to distribute new versions of files without sending the whole file around. I was able to apply the patch that I'd found, recompile my kernel and start using my card.

However, in the spirit of open development, I wanted to help get the patch included in the kernel since manually applying a patch and recompiling a kernel is not something ordinary users should be expected to do in order to use their hardware.

My first task was to generally clean up the file to which the support was to be added - this involved simply making sure the code was properly indented and well-formatted. Once I had done this, I was able to manually apply the old patch I had found, fix the minor problems which had previously been identified and generate a new patch which would apply to the latest version of the file concerned. This left me with two patches: one to clean up the file and one to add support for my card. These I e-mailed to the project's mailing list where they were accepted by the main man of Linux digital TV development - Johannes Stezenbach. After the patches had been around long enough to have been tested by others, he passed them to Andrew Morton who maintains a branch of the Linux kernel where new patches are added so that they can be tested before they are added to the main kernel distributed to users.

A while later, he passed my patches to Linus, who incorporated them into the current pre-release version of the kernel where they received further testing until that kernel version became a stable release, version 2.6.14. So if you have the same digital TV card as me, the new revision of the Nebula Electronics DigiTV PCI card, it should now be detected and configured by any Linux distribution with kernel version 2.6.14 or newer - you can find your kernel version by running 'uname -r' on the command line.

Getting something into the kernel is a long process, with various people involved and various checks in place to make sure nothing nasty can get in. Every person who handles a patch must add a line to the e-mail they send when they forward it on, known as a 'signed-off-by' line. This line is a declaration from the person concerned that the patch contains code that may be legally included in the kernel. Every contribution which is made to the kernel receives an entry in the CHANGELOG file for the version to which it applies - this allows all contributions to be tracked and recorded. My entries are as follows:

[PATCH] dvb: bt8xx: Nebula DigiTV mt352 support
Add support for Nebula DigiTV PCI cards with the MT352 frontend.

Signed-off-by: David Johnson
Signed-off-by: Johannes Stezenbach
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds

[PATCH] dvb: bt8xx: cleanup
Indentation fixes and remove unnecessary braces.

Signed-off-by: David Johnson
Signed-off-by: Johannes Stezenbach
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds

The first line is a descriptive title of the patch and following that is a description of what the patch does. Finally is the signed-off-by list with the name and e-mail address of everyone who has handled the patch. Despite me having little relevant knowledge and no experience with kernel development, the developers were only too happy to accept my albeit small contribution - nobody is excluded from getting involved.