Image: Jack Wallen

Some time ago, I got into a rather heated exchange on Twitter about the state of open source bug reporting. The exchange looked something like this:

Me: Open source needs easier bug reporting tools.
X: But then everyone would use them.
Me: Exactly.
X: You don’t understand, if everyone used bug reporting tools, we’d get useless reports that didn’t help us solve problems.
Me: But you’d get users interacting and trying to help.
X: But it wouldn’t help.
Me: Isn’t that kind of an elitist attitude? One that has plagued Linux for years and prevented more new users from joining the platform?
X: ?????
Me: When you make users feel like their input isn’t of value, or what they have to offer doesn’t help your project, then you prevent yourself from expanding your user base.
X: This doesn’t count.
Me: What doesn’t count?
X: Bug reports.
Me: Why?
X: We need intelligent input.

And the conversation continued like that, in a circular fashion, for a few Twitter cycles. It was frustrating, to say the least.


I get that developers need specific information for bug reports, but in many cases, the extraction of that information is beyond the pay grade of the average user. Take, for instance, the backtrace. The backtrace command is a powerful tool that allows the user to start an application while gathering specific information about why a program might not be running properly. This is not a command built for the new user. I’ve been using Linux since the late 1990s and I have to remind myself how the tool is used (because I don’t use it often).

SEE: Telephone interview cheat sheet: Software developer (TechRepublic Premium)

Imagine how the new user would react when they are told to use backtrace to gather the necessary information. And then imagine their reaction when they are told to RTFM about backtrace.

You see how this goes?

There’s a solution for this: Easier bug reporting tools.

When a desktop program crashes on Linux, logs are usually generated. Those logs contain important information that can help developers solve problems. But it shouldn’t be on the end user to track down the necessary logs.

Take, for instance, what System76 does for troubleshooting in Pop!_OS. Their system isn’t perfect, but it’s miles ahead of what most other distributions are doing. If you reach out to their support team, one of the first things they’ll do is have you generate a new log report. To do this you click Activities and type Driver. You’ll see the System76 Driver tool appear with a button clearly marked Create Log Files (Figure A).

Figure A

Once the report is created, it’ll be found in the user’s Home directory, conveniently named system76-logs.tgz. You can then attach that file to an email or a support ticket and the team will take care of the rest.

System76 could take this one step further and have the tool automatically open the default email client compose window, with the log file attached, a proper subject added, and the necessary support email address filled in. All the user would have to do is fill out any additional optional information in the email and click Send.

The goal? Make it as simple on the end user as possible. And System76 gets that. But if one were to judge the Twitter conversation I had, the person I was speaking with wanted to focus all their effort on making it easier for the developer.

And that is part of the problem within the Linux community.

  1. Not every Linux user is a developer.
  2. The ease should always be on the end user.

Any company serious about growing their platform understands that idea. You make it harder on the end user and you will lose end users. I’ve watched it happen with so many projects over the years. Company X starts out with a brilliant idea, but the closer they get to release time, the more challenging their product becomes for the target audience. When the product finally reaches the end user, dissatisfaction is almost guaranteed.

To that end, Linux developers need to focus a good amount of energy making it easier for end users to report problems. Although I am long removed from my days as a developer, I have some bits of advice that might help this problem along. Here’s the bulleted list:

  • Use simplified language in the tools;

  • Don’t require users to work with any tool that’s not already on the desktop;

  • Create a Twitter account specifically for the purpose of reporting bugs;

  • Always give users the benefit of the doubt;

  • Follow up with users (if possible); and

  • Don’t expect users to “learn” how to write a good bug report.

That’s a short list, because this is a challenging issue.

The fine line

I understand that a bug report is only as good as the information it includes. That fine line between too little information and just the right amount is a tricky road to tow, but it is possible to get exactly what you need from users. In order to do so, the right tool must be created to collect the necessary information. This tool needs to be a desktop tool, built into the distribution itself. Slap a launcher on the desktop somewhere, such that when an application crashes the end user knows to launch that tool. The tool will then collect information from log files and attach it to the report. The only thing the end user would have to do is fill in any optional information and click Send.

Make it that easy and I guarantee you will get results. End users will happily report bugs if the doing is only a couple of clicks away. But the second you require them to answer a litany of questions like “How do you reproduce the bug?” those users will never bother to submit a single report.

Linux needs two things:

  • Ease of use

  • More users

The Linux desktop platform doesn’t need more complexity to scare away more users. This holds true for bug reporting. If developers want to improve their products, they need reports from users.

Make these reports as simple as sending a text or a tweet and the bug reporting will grow exponentially.