In recent years, Linux distributions have successfully made the transition from being the exclusive domain of technical users to being suitable for even brand new computer users. However, unlike with proprietary software and operating systems, GNU/Linux is built mainly on the efforts of users who volunteer their time and expertise to write programs. The result is that the success of free and open source software (FOSS) depends on feedback and contributions from its users. New users, or users without programming skills, may not understand how to contribute, or even see the need for contributions. But non-programmers can contribute a great deal to FOSS projects, benefiting not only other users but also themselves in the process. Even you can help.
First, a little background for new users: the Linux kernel, the GNU software forming the core of the operating system, and the vast majority of software drivers and applications that make up modern distributions are free software as defined by the Free Software Foundation (FSF). The FSF definition states:
Free software is a matter of the users' freedom to run, copy, distribute, study, change and improve the software. More precisely, it refers to four kinds of freedom, for the users of the software:
- The freedom to run the program, for any purpose (freedom 0).
- The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
- The freedom to redistribute copies so you can help your neighbor (freedom 2).
- The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.
The point is that Linux and Linux applications are (by and large) built on four essential software freedoms. Two of the four freedoms emphasize being able to modify and release software, and the legacy of free software is a collaborative development model that encourages users to be developers who modify, improve, and redistribute software. The power of collaboration and open source development is why Linux distros and other FOSS applications are polished, powerful, and strong rivals to proprietary software.
Over time, and with a lot of effort, the FOSS development model has resulted in Linux distributions and applications that are exceptionally easy to use, which in turn has attracted a large number of new users. However, users not familiar with FOSS development often have different expectations regarding software usability, maturity, and the completeness of software features. User reactions to the release of KDE 4.0 is a good example of how users' expectations can conflict with developers'. And KDE is typical of FOSS projects; it relies on contributions from users to improve.
"That's great," you say, "but I don't know how to write patches or fix bugs. What can I do to help?" There are a number of ways for non-programmers to participate meaningfully in FOSS software development. The two easiest ways to get involved also have the biggest benefits for users themselves: participating in user forums and contacting developers directly.
Participating in user forums
At some point, everyone runs into a problem using Linux (or any other computer operating system, for that matter). A search through the help files or an Internet search usually leads people to the Web support forums for their particular distro or application. But there are good ways and bad ways to use Web forums. The bad way is to post a vague question, either get a helpful answer or not, and never follow up. The good way requires a little more work, but has much greater benefits for both the user asking the question and the community as a whole.
Not too long ago, people would go to mailing lists or Usenet newsgroups for the same sort of help. During the Usenet era, questions on how to do something or solve certain problems were often answers with "RTFM" -- read the friendly manual. That is good advice even in today's world of beginner-friendly distributions and Web forums. Try to do a little research before posting a question on a forum so your question will be more informative. Compare these two examples:
"Help! My wireless card doesn't work with Ubuntu."
"Help! My D-Link WNA-2330 wireless adapter isn't working with Ubuntu 7.10. A Web search indicates that I need a MadWifi driver. How do I get it, and how do I configure it?"
The second question provides a lot more information and makes it much easier for people to help.
Be prepared to follow up after posting a question. A common response to questions about networking is to ask the person posting the question to post his or her output from commands like
lsmod. Posting additional information helps more experienced users diagnose the problem and suggest the correct answer.
The most important part comes after you fix your problem. Follow up in the same thread with, at the very least, a thank you for the people who helped you. Far more helpful is to post a thank you followed by a detailed summary of what you did to follow the advice you got, and what happened afterward. This kind of after-action report has two major benefits. The first is that you have a record of how you solved a problem specific to your hardware and software. Save or print it so you can solve it the same way in the future. The second benefit is that other users like you will probably find your posts via a Web search and benefit directly from your experiences.
A little bit of followup goes a long way. You have solved your initial problem, potentially learned some valuable troubleshooting skills, and benefited the whole community with just a little extra work. In time, you could become one of the people offering helpful suggestions yourself.
Providing direct feedback
Another way to help is by offering direct feedback to a project. Developers like good, useful feedback. They really want to know how their software is being used, what sort of problems people are encountering, and what features people want. Open discussion of bugs and features is a cornerstone of FOSS development and one of the areas where non-programmers can have the greatest impact.
Depending on the size of the project, bug tracking can be a simple matter of sending the program's author an email or forum message. Larger projects use bug tracking software like Bugzilla. Do a quick Web search for bugs in the program that may be causing you trouble. You will likely get to the site of the bug tracker. For example, Web pages for filing bug reports for KDE, GNOME, Ubuntu, and Scribus are easy to find. It is important to search the existing bug database to see whether somebody else has already filed the same bug that you found. Your search may reveal that the bug you are experiencing has already been fixed and a patch is available. The larger and more heavily used projects generally have more bug reports.
If your search reveals that nobody has posted your bug, read the community guidelines and file a bug report. The guidelines for submitting bugs to Mozilla, for example, say:
Effective bug reports are the most likely to be fixed. These guidelines explain how to write such reports:
- Be precise
- Be clear -- explain it so others can reproduce the bug
- One bug per report
- No bug is too trivial to report -- small bugs may hide big bugs
- Clearly separate fact from speculation
After reporting a bug, you may be asked to do some followup work to reproduce the problem or test a patch. Take advantage of that opportunity if you can. You'll learn a lot about troubleshooting, testing patches, and fixing problems. Like participating in user forums, filing bug reports is a great way to flatten your learning curve while providing a meaningful benefit to other users.
The more you learn about Linux, the more you will be able to contribute. If you become very familiar with an application, consider contributing to its wiki or writing a how-to article. There is always a need for well-written documentation, especially documentation written from a user's perspective. If your favorite application or distro offers downloads for testing, download them and actively seek out bugs. Finally, consider learning a little bit about programming and scripting. Even non-programmers can learn enough to recognize functions and variables -- knowledge that can lead to more informative forum posts and bug reports.
FOSS software development depends on contributions from developers and users. As Linux continues to become easier to use and more popular, it is more important than ever for regular users to participate in online communities and help the developers of the software they use.