A distribution occupies a very specific niche in the free software ecosystem. Among other things, we need to accept some responsibility for ALL the software defects (“bugs”) that users actually experience across the entire stack. Most users don’t install their apps from upstream source tarballs, they install them from the packages provided by their distribution. So when they experience a bug, they don’t know if it’s a bug introduced by that distribution, or a bug in the underlying upstream code. They don’t know, they don’t care, and they shouldn’t have to. More often than not they will report the issue to their distribution, and the way we respond to it is important, because it represents an opportunity to make the whole ecosystem more robust.
I had a lecturer who was very opposed to the use of the term “bugs”. He said that the term “bug” was a cute-sification for “nasty biting insect”, and similarly, software defects have potentially serious consequences, so we shouldn’t treat them lightly. Bug work is serious work, and it’s one of the most important forms of contribution to the digital commons that Ubuntu can make, so I’d like to salute the extraordinary efforts of the Ubuntu Quality Assurance Team and Bug Squad. Initiatives like five-a-day are already making a huge difference to our users. As Henrik Omma says, effective bug reporting requires a diligent and professional approach, and I’ve noticed a real improvement in our community. Hopefully, we can bring the benefits of that competence to the broader free software ecosystem.
Ubuntu gets as many bugs reported against it as OpenOffice, Mozilla, Gnome, and KDE combined.The vast majority of those bugs are issues that exist in upstream tarball releases, or in Debian. Our primary goals should be to ensure that fixes we produce, and information we generate in the QA process, make their way upstream where they will benefit the broadest cross-section of the community. Separately, we want to ensure that each Ubuntu release ships without major issues, regardless of where those issues originated. We are responsible for the user experience of every line of code, even though we don’t produce every line of code.
In the month of April 2008, I found the following bug counts for large FLOSS projects:
With hindsight, April was possibly a bad choice, because it was an Ubuntu release month so there’s usually a small spike in the number of bugs filed. It would be interesting to see the stats for other distributions, and projects, over a full year. But the general picture is clear – within our family of distributions, Ubuntu carries the brunt of the load w.r.t. bug tracking, triage and patch management – not only for our users, but for a broad cross-section of the open source stack.
When I delved into the data to see how we do with pushing bugs upstream, I found a somewhat mixed picture. In many cases, we do very well indeed. We have a very good relationship with GNOME, for example, with a very high percentage of bugs appropriately forwarded to the relevant upstream bug tracker. In other projects, it’s harder to make a definitive statement. The percentage varies based on whether the Ubuntu team members have good relationships upstream, or whether there’s a person acting as an ambassador from Ubuntu to upstream (this is a great way to make a difference if you care about a specific application in Ubuntu!) or whether upstream themselves have taken an interest.
We need to improve the tools that support these kinds of cross-project conversations. Launchpad does currently allow us to track the status of a bug in many different bug trackers, and there are quite a few distributions and upstreams that are now either using Launchpad directly or exchanging data efficiently. We’ll keep working to improve the quality of exchange across the whole ecosystem, including those projects that don’t use Launchpad themselves