Recently, Karl Fogel wrote about bugs and “technical debt” – as a response to a mailing list thread about the future of Subversion in 2010. This resonates with me as I recently found myself struggling with bugs in Ubuntu to find that they would not be fixed (in my case, it was the lack of embedded ROM code for a USB-serial adapter – normally included with the Linux kernel).
Karl’s article was then reported on by Joe Brockmeier of OStatic.
Much of this reporting makes me think of TeX, the typesetting system created by Donald Knuth, one of computing’s “founding fathers” (so to speak… despite coming on the scene later on.). TeX has remained unchanged except for bug fixes for several decades, and shows no sign of slowing down or dying, in contrast to what the articles report.
I also think of Ubuntu distributions contrasted with the Ubuntu LTS (“Long Term Support”) distributions – which mirrors the difference between Fedora and Red Hat Enterprise Linux. It is possible to have a system without bugs – or at least, with few bugs. Fixing the bugs in a rapid and constant fashion will improve the user experience, as well as build up the “Good Will” value of your name rather than being known for bugs that aren’t fixed.
A complaint often heard from users is that the “fix” for a problem a user of a commercial product has is to “upgrade to the new version” (normally with a substantial cost). This should not be the way things are done.
Bug removal should be primary, and solid reliable program operation number one. As a user – and a enterprise user – reliability is primary. A product which proves through history that bugs are second to upgrades and new features will not last long. This is the very reason that products like Ubuntu LTS and Red Hat Enterprise Linux exist.
I agree with several premises in Joe’s article on OStatic – that bug removal should not be the only focus, or that an increase in bug reports is not all bad. More bugs means more users are using the product, and provides a way to make the software more reliable. Users would much rather apply patches and update to a more reliable version than upgrade to something entirely new and with newly introduced bugs not yet fixed.