Many people understand the development model used by Free Software development groups and GNU/Linux distributions, but few understand how to properly get involved. This problem has perplexed many and reduces the number of individuals who are able to become involved in Free Software development and testing.
The first step before starting on any project is making contact with the existing maintainer. Communication is the key to reducing redundant efforts, ensuring that work isn't done twice and maximizing the value of the work of individuals. This step may yield the discovery of a dormant project which needs help. It may also bring to your attention that you can join an effort another person has started. Be sure to evaluate the skills needed for any undertaking and decide how to help based on those skills. Nearly any undertaking will be a learning experience.
The most fundamental job a novice may perform for a Free Software project is to test and review or audit the released software and documentation. It is most helpful to the maintainers of the projects to have a third party review their work. Reporting the results of such tests and submitting changes to documentation according to the project's problem reporting mechanism can help ensure a higher quality release. Project maintainers may not respond or acknowledge the work appropriately as they should , but you should not become discouraged; it's unfortunate, but this extremely important position is often ignored.
The next level of support you can lend to a project relates to documentation. There are literally thousands of Free Software programs and projects in existence. There is consistently a lack of high-quality documentation available for these projects. Documentation comes in many forms; the most common are: manual pages (or man pages), Linux Documentation Project (LDP) HOWTOs, user manuals, and guides. Documentation should be written in a consistent format which is useful to its target audience. Keep in mind that documentation meant to be read by technically-oriented individuals may also be of use to a more wide-scale audience and should be written in such a way that all can understand. Feel free to refer the reader to outside sources of information.
Creating proper documentation takes a lot of time and skill. Remember all the processes learned in English Class and put them to use. Get a reference book and put it to good use. Keep in mind that documentation may be translated to other languages or read by people whose native tongue is not English. Clarity is of the utmost importance.
It is good practice to submit updates to documentation when you find mistakes, bad grammar, or old information (broken URLs, incorrect company contact information, etc.). It is also a good time to review the documentation thoroughly when you are reading it.
Write on topics close to the heart (write what you know). Good documentation takes a lot of time to write. When you are intimately involved with the subject matter, you are more apt to pay attention to detail. It is not only important to list how to do something, but also why it works and what the command does. Making an end user more informed is the point of the document, so no issue should be left untouched. Start the document by describing what the program does and document the command line arguments used by the program. This first document is the most crucial part of program documentation; it is the start of a full fledged user manual. A quick start guide is another good starting point for a manual. It tends to save the reader a lot of time and get to the point. Rome wasn't built in a day and a useful user manual won't be, either.
There are many tasks which may be performed by a novice programmer. Most of these projects involve a minimal set of programming skills and basic documentation skills. You must first get the latest developmental version of a piece of software. Next, use the software and review its visual appeal and error messages. Document the issues and make a list of what could be made to look better or reworded to make more sense. Consider possible ways to remedy the issues and attempt to fix them. Although you may not be able to solve all the issues you documented, you can post a patch along with a listing of the issues resolved and a list of issues which remain to be solved.
Adding additional error output and debugging code can be of great use to a project, big or small. Such additions don't tend to take a lot of time but are more likely to be ignored by the program's maintainer. Good software provides consistent, easy-to-read messages which are both of practical benefit to the end-user and useful to the developer during the troubleshooting process. Submit changes in the form of a patch to the author, and she will usually be happy to accept them.
Skilled developers have their work cut out for them. As you might expect, the majority of work needed in Free Software development is coding. Grab the latest developmental code, take a peek at the wishlist or TODO list, and hack away. Submit patches to the project maintainer and watch the project become the program that all the world uses for years to come.
Those who are Webmonkeys can help create a better looking Web site for a project. Most project maintainers do not have time to spend writing PHP or HTML to make a good Web page, but a Web presence tends to be your first look at a project and thus is a way for it to gain outside interest. Get out a copy of the GIMP and a favorite text editor, and hack up a Web presence for the project. Don't forget to make it easy for the project maintainers to update the site with new information.
Lastly, whenever getting involved in a project, join its mailing lists and newsgroups. Post messages when an update is made with a URL to the patch or documentation. Be alive and active in the project and get noticed. Free Software does not grow on trees and needs your help. No longer can you say, "But I don't know how to get involved." Select an appropriate starting point and get to work!
* See Jacob Moorman's "The Importance of Non-Developer Supporters in Free Software" for more information on the very important related topic.
David Burley is a Core Developer for the Marble Horse Free Software Group. He actively engages in documentation, coding, and advocacy of Free Software projects. David is also a second year Computer Engineering major at the University of Cincinnati.