Bring out your bugs

Society’s unhealthy preoccupation with money is reflected well by recent trends in corporate governance, which rate the investor – often only a short-term speculator – more highly than the customer.

So whilst Apple, Adobe, Microsoft and other software giants are subject to the accounting rigours of the Sarbanes-Oxley Act of 2002, ask any of them for an audited list of open bug reports and you will be told that such information is confidential. Investors must have complete confidence in corporate accounts, but customers are left to develop confidence in products by experience, our personally painful trial and error.

With complex software products like OS X, OS X Server, Adobe Creative Cloud, Office for Mac, even niche applications such as Smith Micro’s Poser, it is often desperately difficult to know when problems encountered by a user are actually bugs.

I had a schoolboy snigger over Poser 6’s handling of male genitals in combination with conforming trousers: enabling genitals seemed to result in indecent exposure, rather than a bulging crotch. One of the more entertaining software issues that I have encountered, I had to presume it was a bug; perhaps if I checked some box in an obscure dialog, Poser’s parts would be properly tucked away in his trousers.

Support forums, discussion areas, mailing lists, and more are devoted to users reporting problems, such as the more prosaic random disappearance of AFP sharepoints from some versions of OS X Server. More experienced users – saints with solutions – try to work out what is wrong and what to do about it, in that case recommending that you check your network cabling. What seemed at first to be a bug in the Server software, or a misconfiguration in Server Admin, may turn out to be a simple electrical mistake. But if no saint suggests a solution, you’re stuck wondering whether you have not understood how to do the task properly, or it is a bug, unless you can check through a list of known bugs.

In fairness, Apple is better than many vendors in this respect. Users can report bugs via product feedback pages such as this for OS X, or discuss them in the appropriate area here. If you’re registered (free) with an Apple developer programme, you can report bugs here and then track your own reports, but no others. There are other excellent but unofficial sources of information, such as MacInTouch, but each can only compile user experiences and opinions, and may not always get it right.

Just as government used to claim that the performance of hospitals and schools was far too sensitive to trust to the public, software vendors consider that bug lists are highly confidential. Amazingly, since the public has been let in on the secrets of performance of public services, the nation has not collapsed into anarchy, yet we still cannot be trusted to know officially whether a given software problem is a bug or not.

There are some exceptions, of course, with open source software generally having a huge advantage. Visit any project home page on SourceForge, for example, and you can access the complete list of reported bugs, check the status of each, and if you really want to, you can go into the source code and have a go at fixing some yourself.

So long as commercial competitors keep their bug lists a secret, it is tempting for everyone to follow suit. Maybe the time has come for a new approach, writing openness of support into the plan for corporate governance for the more progressive software corporations. Management and monitoring of bug lists could then be fair game for external and independent audit.

After all, software vendors should be able to take pride in the way in which they address bugs, not feel so ashamed that the information has to be kept quiet.

Updated from the original, which was first published in MacUser volume 22 issue 08, 2006. Needless to say, protection of investors has increased considerably since then, and secrecy over security vulnerabilities and bug lists has remained unfaltering.