In-Roads to Free Software Development

Inspired by a comment from Waldo L. Jaquith to Jacob Moorman's "The Importance of Non- Developer Supporters in Free Software". This document simply describes a few ways to get involved in projects. It is aimed to be as general as possible so as to be applicable to all projects.

Copyright © 2000 David Burley, All Rights Reserved

Many understand the developmental model used by free software development groups and GNU/Linux distributions. However, 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 in on any project is making contact with the existing maintainer of the project. 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 one's attention that they can join an effort another person has started. Be sure to evaluate the skills needed for any undertaking and decide on how to help based upon those skills. Nearly any undertaking will be a learning experience.

Testing

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 back the results of such tests, and submitting changes to documentation according to the projects problem reporting mechanism, can help ensure a higher quality release. Project maintainers may not respond or acknowledge the work appropriately as they should [1], however, one should not become discouraged; it is unfortunate, but this extremely important position tends to get ignored often.

Documentation

The next level of support one can lend to a project is 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 written may be translated to other languages or read by persons 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 one is reading it.

Write on topics close to the heart (write what you know). Good documentation takes a lot of time to write. When one is intimately involved with the subject matter, they 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 and thus 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. They tend to save the reader a lot of time and get to the point. Rome wasn't built in a day and neither will a useful user manual.

Programming

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. One must first get ahold of 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 remediate the issues and attempt to fix them. Although one may not be able to solve all the issues they documented, they 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 adept 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 they will usually be happy to accept them.

Skilled developers have their work cut out for them. As to be expected, 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 back to the project maintainer and watch the project become the program that all in the world use for years to come.

Public Image

Those who are webmonkey's can help create a better looking website for a project. Most project maintainers do not have time to spend writing PHP or HTML to make a good web page. However, a web presence tends to be one's first look at a project and thus is a way for it to gain outside interest. Get out a copy of The Gimp, 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 one say, "but I don't know how to get involved." Select an appropriate starting point and get to work!

*[1] See Jacob Moorman's "The Importance of Non- Developer Supporters in Free Software" for more information on the very important related topic.