Some points:

The number of bug reports is proportional to the number of users, not to the number of actual bugs. A large and active bug tracker is a sign of large and active user base, and the ratio of open-to-closed bugs tells you nothing at all about the software’s health or stability.

Similarly, the ratio of unhelpful reports to helpful ones is not in itself relevant. You’d have to look at how much effort each kind costs; in general, unhelpful reports can be dispatched with very quickly — often by other users, rather than by the developers — and most developers spend most of their time dealing with substantive reports that could actually lead to a fix. Just because all that information is available doesn’t mean people can’t choose where to focus their attention!

You also can’t know the frequency of “bugs not filed”: that is, the number of times someone was about to file a bug, but then saw (thanks to the open tracker) that someone else had already filed it. Launchpad.net’s “this bug affects me too” button at least gives us a way to estimate the relative prevalence of bugs; again, this is entirely dependent on the open nature of the tracker, which gives people a way to follow a bugfix’s progress without having to enter into any relationship with the tracker or the tracking organization. (Just try engaging with a closed shop that way.)

Finally, it’s very difficult to compare an open bug tracker like Ubuntu’s with a closed bug tracker like, say, Microsoft’s, because by definition you don’t have access to the data in the closed tracker. For all we know, Microsoft has a zillion times more bug reports, but we just don’t see them. They could be of worse quality too, and we’d never know. One thing we do know, however, is that Microsoft is unable to enlist its users in helping to remove duplicate and invalid bug reports: instead, its own employees have to shoulder all of that burden.

I think this article would have needed to gather a LOT more real data, and think about the problem much more thoroughly… but then it would have been a very different article. You can’t just say “Look at all those Ubuntu bug reports — there must be a problem here!” That’s not how it works.

However, the suggestion that people “should also be required to provide backtraces before they submit reports” is also misguided. I’ve worked for Canonical for four years and reported hundreds of bugs, many of which have been fixed, but I don’t know how to generate a backtrace.

By the way, anyone can report linux kernel errors, too. Should the kernel also go behind doors ??????

First, looking at the front page of launchpad — or any page of launchpad for that matter — there are tabs for Overview, Code, Bugs, Blueprints, Translations, and Answers. Bugs only make up part of the system. I have a little more faith that the majority of users will be able to read the screen.

Second, if your bug isn’t actually a bug and is a question, the Bugs page has an option for that. If you’re a fairly new or basic user and don’t really know what a bug is, you’re more likely to click on the big blue “Ask a question” button instead of the big read “Report a bug” button. Besides, if you’re a basic user and you get into the “Report a bug” section when you should have asked a question, before long, the process itself will imply that you might not be in the right place.

Third, whenever a bug is filed — or whenever I’ve filed a bug there — an automated return comes up requesting other necessary information with instructions on how to provide it. Most people who are clever enough to realize something is a bug and then find there way to launchpad will be able to run those simple codes and attach the necessary files. If the problem was already addressed someplace, it’s never very long before either a developer or the community tells you that it’s been addressed

That is, if the system doesn’t catch it first and make a few suggestions. Once someone describes their bug in a title, you get a big page that says “Is the bug you’re reporting one of these?” and it shows you a slew of options. That’s automated; there isn’t a developer wasting time fielding all those requests, finding the other possible options and then returning those options to the end user. So it’s not taking up developer time.

Fourth, how is it a flaw to have launchpad as a middleman between the user and the larger upstream ecosystem? If you have a problem with an application, but don’t know that your problem is actually with a library or some component that’s maintained upstream, launchpad seems to be a very effective way of getting that information to the upstream developers.

Besides, if you didn’t know it was a problem with some smaller component, how would you ever go out on the web and find the bug system for that unknown component in the first place? You can’t find the right tool for a problem if you don’t know what the problem is. In cases like this, launchpad exists as a knowledgeable system that can identify such issues and pass them on, effectively creating and maintaining some needed communication where it might have never existed.

I’ve read a lot of critical articles in this blog; I wish more of them were actually constructive. I think ten minutes reflection on your launchpad complaints (and maybe a visit to the page) would have changed the tenor of this piece and its responses.

a) not all bugs reports that could have been filed get filed (registration and other annoyances)
b) users don’t help users sort out problems
c) patch writers can’t just come by a report and write a fix.