Articles / Inroads to Free Software De…

Inroads to Free Software Development

In today's editorial, David Burley of the Marble Horse Free Software Group offers suggestions for anyone wondering how to get started helping with Free Software. This editorial was inspired by a comment from Waldo L. Jaquith to Jacob Moorman's "The Importance of Non-Developer Supporters in Free Software". It simply describes a few ways to get involved in projects and is aimed to be as general as possible so as to be applicable to all projects.

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.

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 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 [1], but you should not become discouraged; it's unfortunate, but this extremely important position is often ignored.

Documentation

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.

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. 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.

Public Image

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!

Footnote

*[1] 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.


T-Shirts and Fame!

We're eager to find people interested in writing editorials on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an editorial gets a freshmeat t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let jeff.covey@freshmeat.net know what you'd like to write about.

Recent comments

25 Jun 2000 22:40 Avatar jsinger

...and for KDE beta testing
Oh, and if you're interested in beta testing, the second KDE 2 beta release (Kleopatra) is available for download as source or binary. See http://www.kde.org/announcements/announce-1.91.html for more information. It's already quite stable and functional and almost all apps have a bug reporting dialog that makes it extremely easy to give feedback.

25 Jun 2000 17:28 Avatar jsinger

KDE documentation and translation
And, for the obligatory "Yeah, what about KDE?" comment, the KDE translation and documentation site is at http://i18n.kde.org/ and has information on getting started, what needs to be done and who to contact. With KDE 2.0 coming out in a couple of months, there's a tremendous amount to be done and an opportunity to contribute to a major project in a way that will have a huge impact.

25 Jun 2000 13:47 Avatar cypherpunks

Great place for doc writers right now
is the Gnome Documentation Project at http://www.gnome.org/gdp/ who have a wide
variety of work that needs doing. Read their "Getting Started" page and visit them on IRC at
irc.gnome.org, channel #docs

Screenshot

Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.

Screenshot

Project Spotlight

Kid3

An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.