The strength of Free and Open Source Software (FOSS) is its openness and transparency, and community support. Anyone can contribute, not just elite coders with lush geekbeards and ratty sandals. So what can a non-coder do?
Bug Hunt
One of the reasons Free Software is so high-quality is anyone can report bugs and submit patches. Even if you can’t fix bugs, reporting them is valuable. Every Linux distribution has a bug tracker, and so do most individual programs. Submitting a bug report usually means following a particular protocol, and using the appropriate bug-tracking tool.
There are wrong ways to report a bug:
- “ur proggie sux. crashed on me this morning while i was doin my homewrk.”
- “it doesn’t work. fix it.”
- Whine in all the wrong places, like IRC and unrelated forums
- Report your own error as a bug
The right way is to first find the approved mechanism for reporting a bug. Bugzilla is a popular bug-reporting and tracking tool, used by major FOSS projects like Mozilla, Red Hat Linux, KDE, Gnome, and the Linux kernel. Ubuntu uses Launchpad, which is their own proprietary bug-tracking/project-hosting/meeting planner tool. The bug-reporting component is called Malone. Whatever bug-tracking system is used, you’ll probably have to register a user account and log in.
Distributed Responsibility
A Linux distribution is comprised of thousands of programs developed independently, so it’s not always obvious who is responsible for a problem. All distributions modify programs to a degree, some more than others. So the first place to report a bug is to your distribution’s bug-reporting system. If you build your programs from sources, then use the programs’ own bug-trackers.
Bug Confirming
Before you actually file a bug report, do some homework first. First search mail lists and forums to see if anyone else is having the same problem. Chances are you’ll learn it’s not a bug, and you’ll learn how to fix the problem.
Then search the bug database to see if it’s already been reported. If it has, it doesn’t hurt to add a “metoo” addendum. Include all the information you would put in any bug report. A nice, though not necessary, thing to do is include any useful workarounds in your bug report.
The most important step is to make sure it’s a bug, and not some daft thing you’re doing. You should be able to replicate the bug. If you can’t, neither can the developers. This is a great opportunity to exercise those troubleshooting muscles. The majority of bug reports are not bugs, but user error.
What to Put in a Bug Report
See Resources for some Horrid Examples of how not to write bug reports. Gnome’s Bugzilla Helper includes forms to help you include the correct information. You should include:
- Operating system and version
- Program name and version
- Whatever behavior makes you think it’s a bug, and the steps you take to trigger it
- Any pertinent error messages
Sometimes that is all you need. If the developer needs more information they’ll ask. Or you may get a request to move the bug report somewhere else. You might be told that it’s not a bug, but the way the program was designed to operate. If that’s the case you can always visit the developer’s list for the program and nicely discuss your issue directly with the developers.
What if the Bug Doesn’t Get Fixed?
If your bug report is ignored, there may not be a lot you can do. The devs may be overworked, or don’t see it as serious enough to address, or are simply mean people who hate you. (This type of developer is a very tiny minority, but they do exist, and why they choose to support a product that is going to be used by other people is one of life’s little mysteries.) Give it a couple of weeks, then try a polite reminder. Posting a duplicate report upstream (directly on the program’s own bug-tracking system) might get quicker action.
Always be polite and factual. Most developers are polite and professional, but they are human and you will encounter the occasional dork. You’ll score big credibility points by taking the high road.
Wish Lists
Many FOSS projects have wish lists. These are the places to post your suggestions for features and improvements.
No Whining
It takes a bit of work and care to write good bug reports. If you start feeling abused, just remind yourself how much work and resources went into all that great software that you are enjoying for free. And while you’re at it, remember how unresponsive most commercial closed-source vendors are to bug reports, and how they are so encumbered with ridiculous EULAs and patents and DRM and NDAs that even if you have the resources to do so, you are prevented from fixing problems yourself. Rather like living in a house where you were not allowed to paint, or patch holes, or change lightbulbs, or remodel, or do anything except pay out money year after year to the builder just for the privilege of living there.
Share Tips and Howtos
A wonderful and easy way to support Free Software is to post tips and howtos somewheres. These don’t have to be your life’s work, but useful things you have discovered in your everyday work. For example, it might be that you figured out some advanced networking configuration options, or a quick OpenSSH tip, or learned some useful but little-known netcat options, or yet another way to filter Ethereal output to quickly home in on what you want to see. Put these on a blog, or post them in appropriate user forums, or anywhere Google can find them. Five minutes’ of work translates into help for thousands of users.
Send Lawyers, Guns and Money
Well, probably not guns. But money is often welcome, or donations of hardware. In this era of attacking with armies of lawyers instead of guns, good legal assistance for warding off the greedy barbarian hordes is a very nice thing.
Resources
These horrid examples of bug reports are brought to you courtesy of Akkana Peck:
- Bug 60632 – Bug is rapid
- Bug 73360 – crashed application
- Bug 133113 – My wish-list i compiled for the last 1 1/2 years i used gimp
Example of a good bug report with a semi-happy ending:
Thank you to Meredydd, Noirin, Akk, and the rest of the Linuxchix gang for their help in writing this article
