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
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.
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 , however, one
should not become discouraged; it is unfortunate, but this extremely
important position tends to get ignored often.
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.
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.
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
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!
* See Jacob Moorman's "The Importance of Non-
Developer Supporters in Free Software" for more information on the
very important related topic.