Kyle Smith

I’ve been running into a fun bug with Firefox on Linux, Windows, and Mac OS X. Opening a new tab while another one is actively loading content causes the browser to crash.

As a good open source citizen, I was going to go report the bug, but then I saw the Firefox bug submission page. To summarize:

1. Use the latest nightly build of Firefox and create a new default profile
2. Determine which Firefox component is causing the bug
3. Verify that the bug has not already been reported
4. Read the bug writing guidelines

While I’m willing to do some extra steps, like capturing a backtrace, I’m not about to go jump through a bunch of hoops to report a bug that will probably sit there untouched in Bugzilla. So I didn’t bother to report the bug.

When opening bugs the onus should not be on the end user. If you want me to report bugs in your software, you need to make it take only a few clicks. I don’t mind installing debug packages as long as the heavy lifting is done for me (and I refuse to install software that cannot be managed by apt or whatever package management system is used).

There are a number of solutions that people have come up for the easy submission of bugs. Apple and Windows have built-in crash reporters. Netscape had Talkback (which is now unsupported). GNOME has Bug Buddy, and Google has released Airbag (now Breakpad).

Sadly each of these have potential drawbacks. Bug Buddy reports the stack trace, which isn’t useful if debug symbols aren’t available (you can’t tell where the various threads were when the program terminated). Breakpad and the Windows crash reporter send memory dumps, which causes me to worry about what private information is going along with it.

I’m sure others will eventually come up with a good solution to this problem, but the important thing for developers to remember right now is this: your end users have only decided to use your software; they have not agreed to be developers or your guinea pigs. Do not treat them as such, even if the bugs they submit are vague, unreproducible, or not helpful. If you upset your users, they won’t remain so for long! If it’s open source they don’t have a financial incentive to see through like commercial software licensees do.

Update: I think I should issue an apology to the Firefox team. As pointed out in a comment, the page I referenced are suggestions for bug writing. And much of my frustration lies not with Firefox, but with the usability of Bugzilla itself (and not just the Mozilla instance of it). And to be perfectly clear, it was not the Firefox project treating users like guinea pigs. Thanks to Gavin Sharp for taking the time to comment.

Jacob asks why software and hardware vendors insist on restricting their products (such as Apple’s iPod and iPhone or Microsoft’s Zune) so that customers cannot easily modify or add to the product.Having worked for an Internet Service Provider as well as a fairly large software and hardware company for a number of years, the answer that first came to mind was related to another response I wrote to him: the cost of support.

Most consumers that purchase a product want to be able to call up the manufacturer when things go wrong and expect them to be able to fix it.  Anyone that’s done technical support knows how difficult troubleshooting can be when dealing with a complex system.

An iPhone is complex you say?  Well yes, actually, when you allow consumers to arbitrarily modify or hack the software that’s loaded onto the phone.  Tracing problems to the root cause are difficult enough without having to worry about third party apps.  Maybe that one little tweak it made just caused something as subtle as a timing issue in the system, maybe it just mangled the encoding for some essential property, or maybe it just caused some unexpected memory contention the system wasn’t designed to handle (particularly with embedded systems where resources are usually limited).

Another potential issue is that hacks could run afoul of legal agreements that the vendor has made with others.  Apple had to convince the music industry that it could protect their product and wouldn’t allow unauthorized copies.  Not only could individuals circumventing the copy protection be liable, but perhaps Apple could be as well.  At the very least the industry could revoke Apple’s ability to sell or distribute its music.

And in the case of the iPhone, one serious issue I was recently made aware of is that cell phones are often designed so that apps are isolated and cannot take over the transmitter and wreck havoc on the (largely unprotected) cellular networks.

While I as a technology-savvy consumer would love to be able to hack my gadgets, I can certainly understand why manufacturers might be afraid of openness.  It’s our duty as the enlightened to help assuage their fears and to help design the appropriate solutions to ensure that the FUD doesn’t become reality.