Greg Kochanski

Sed quis custodiet ipsos software development?

(Who watches the software development?)

(This article appeared in Oxford Magazine Number 247, Second Week Hilary Term (Late-January) 2006. OSIRIS is Oxford University's new financial management software.)

Over coffee, the OSIRIS users in our group occasionally tell me of their software and financial adventures. Many are negative, some are positive, and some are offered as wry comments on human society and institutions. Always, though, they are spoken as if OSIRIS is a vast, implacable force of nature. We speak of ourselves as white rats, placed within some arbitrary experiment that we cannot alter.

Over time, it has become apparent that something is missing: a list of bug reports and permission to report bugs.

In industry, and elsewhere, every serious software project has a system where people can enter and track bug reports. Bugs have a life cycle: they are found by users, then entered onto a list. Someone decides which should be fixed and which first. Fixes are tested against the bug reports, and the reports are (hopefully) eventually marked as "closed" and filed away. Presumably OSIRIS has such a system.

It has one internally, but little of that is exposed to the users and other members of the University.

In industry, of course, one never showed the lists of bugs to the users. The users were "them" and we were "us", and we didn't want to advertise the fact that we even had bugs. We didn't want competitors to know the weaknesses of our products and what we considered important. One never let users enter bugs onto the list: that was considered too important for them. Their job was to pay for the software; our job was to design the next version.

None of those reasons really apply to OSIRIS at Oxford. The users are Oxford, and the people maintaining OSIRIS are also Oxford. Everyone knows that OSIRIS is imperfect so there is no point in hiding the fact, and the OSIRIS developers don't have to worry about their customers switching to another software package. Moreover, we should encourage user input into the design and evolution of the software: a major goal must be to make financial management easier and simpler for the hundreds of people who administer departments and groups.

Since the 1990s, the rise of free software on the Internet has shown a different model, one that has been proven to work very well, and one that ought to fit Oxford perfectly. That model of software development is centered around a open list of bugs.

Any user can enter a bug on the list. Everyone can see the list. People can chime in and say that "I have that problem too!" or "Here is a temporary solution." or "That's not a bug and here's why."

There are over 10000 software projects using this model hosted at http://www.sourceforge.org. Go look at their bugs; they are not hiding anything. Major bits of software that the University depends upon such as the web server for http://www.ox.ac.uk are developed that way. You can go to http://www.apache.org and look at the known bugs in the University's web server, or go to other places and see the known bugs in the Linux operating system it runs upon. If you find a problem, you can report it by yourself, without requiring anyone's approval (though whether and when it gets fixed will depend on others).

This mode of operation has many advantages.

• First, there are practical advantages: the developers of the software get the clearest possible view of what needs to be fixed. Users are invariably willing to improve software that they depend upon. A more surprising lesson that has been learned from open-source software is that users can be surprisingly sophisticated. Valid and valuable bug reports are not drowned in a sea of dumb suggestions.
• Second, it provides the development organization with a bit of bragging space. Every repaired bug is up on public display, proving to the world that they are earning their salaries. This bragging helps the users, too. For instance, our administrator has ways of working around some bugs she knows about; some are slow and cumbersome. Absent any bragging by the OSIRIS organization, she will probably continue to use them forever, wasting time, even if the problems are fixed. She would love to get an e-mail one day saying "We fixed bug 534 that you reported on 10/10/2005."
• Third, and especially important at Oxford which remains a reasonably democratic institution, it lets everyone know what is going on. For software that is critical to the entire University like OSIRIS and admissions software, transparency is important. Congregation needs to know what is going on, as does the University administration as a whole. In a very real sense, those who write the software are becoming the executive branch of the University. To an increasing extent, the rules written into major applications control what one can and cannot do. Consequently, knowledge and control of that software development process needs to be spread as widely as possible, from Congregation to the Vice Chancellor's office.
• Fourth, making the development process more transparent makes problems visible early, while they are still relatively easy and inexpensive to correct. Had OSIRIS had an open bug list, trouble would have been obvious early on it might have been fixed earlier. Instead, the University has suffered and grumbled.
• Fifth, it will save the University money and time. Some users will find solutions without needing the help desk, and the software will work better, sooner, leading to smoother operations.

This approach is not confied to OSIRIS, of course. It can applied to the other software the University does and will depend upon. In a sense, it is just an outgrowth of a suggestion box, but it enforces a certain attitude: hiding problems is not an option.