Searching for Substance: The Road to Safe Software
Date: Sep 3, 2004
It never seemed to matter how the software we used was made. It didn't seem to matter much who made it either. We just grabbed it unquestioningly. That's changing. Today's software can definitely be bad for you, whether it's due to viruses, spyware, dialers, bugs, or merely baroque license agreements. Today you can hardly tell whether a particular piece of software is going to be good for you—or not.
Consumer Purchase the Hard Way
Once upon a time, most of the consumer software you could feasibly acquire was produced by a commercial engineering business, such as Microsoft or Apple. That simple product-distribution model used a wholesale/retail chain like that used for cans of soup. You bought steak from the butcher and bread from the baker.
Now there are many ways to get software. You don't have to go to a corporation or even to a shop. You can download products like Linux, Mozilla, and the Adobe Reader for nothing. You can copy from a friend, or put software together yourself from a pile of source files. You can buy a CD from a flea market hobbyist, or bundled with a magazine. Software comes in our refrigerators, freezers, microwaves, and cars. There's also a viable black market, whether it's the gift culture or Kazaa. If you do acquire a piece of software, more might arrive without you really having much say about it—perhaps a series of patches or a flock of viruses. You don't have the luxury of a stable supply channel anymore.
Once you've got that software, you still can't be sure that it's any good. The people operating the distribution point where you got the software can't tell whether it's any good either. Even the developers who produced the software have at best a fuzzy idea, although their conclusions might be more informed—or anguished—than yours.
There's a complete lack of information about the quality of software for consumers. Instead we have featurism and massive disclaimers in the conditions of sale: "No implied merchantability or fitness for use for any purpose." That can't be right. Overall it's a horribly uncertain experience, a kind of consumer information paralysis, even without the further burden of learning how to use the software.
Modern Savages
As I write this, I'm too busy to wonder whether the word processing software I'm using is bad for me. If you read this online, perhaps using a web browser, no doubt you wonder the same thing. If my software is sending private information across the Internet, or damaging my computer, or dumbing down the saleable skills I've struggled to acquire, or addicting me to some destructive Pavlovian behavior, there's little I can do about it at this second. I would have to break out of my current income-earning tasks to address the problem. If I wanted a systematic solution, my only recourse might be to buy one of those career-change books featuring parachutes. At least my last downloaded game failed to install—a minor reprieve from an occasional bad habit—but hardly a quality software experience.
I wish I could be sure that the software I use is good for me, but I have enough experience with the programming problem not to crucify the poor programmer for failing to fulfill that wish. Quality software development is a hideously difficult task, with fundamental obstacles such as the intractability of correctness proofs and other hopeful rocks that one would like to cling to. Separately, there's the engineering arm-wrestling over territory that comes from sitting next to another programmer whose ideas you don't like. As far as I know, there's no big lever you can pull that will elevate a programmer to the status of a mind reader and a god—at least, not with respect to the code they write. At Microsoft, it has been two years since Bill Gates took all programming staff offline for a "code scrub" designed to increase security. Nevertheless, the list of cleverly successful viruses, Trojans, and worms aimed at Windows seems to have continued unabated. Have mercy on programmers.
Programming is process-oriented, though, and that's where hope lies for better software. Open source software development practices provide that hope.
What's the Problem with Software?
Software sits at the top of an information pyramid. When a software problem or opportunity is first conceived—for example, the need for a spreadsheet tool—there is no software. Instead, unlabeled in our subjective experience lie all the matters we personally apprehend about the world, like the desire for a roof over our heads. Unlabeled in another bucket, which we'll call the objective world, lie all the matters that constrain us without our permission, like the need to cross roads carefully. Through research, whether academic, commercial, marketing, personal, or entrepreneurial, some of these matters are brought into the foreground. From such matters come ideas, from ideas come plans, and from plans come lines of code that make up software products. Before too long you have a VisiCalc spreadsheet program, then a Lotus 1-2-3 spreadsheet program, then Microsoft Excel, then OpenOffice.org. The software, built as a solution to the problem of which we were originally mindful, goes to market; those of us with enough interest acquire it for use. But somewhere in this process of distilling vague ideas into concrete software, things are less than perfect.
The software development process is engineering of sorts, and the way wrong turns are identified in software engineering is to burden them with the label defect. Defects are software features that aren't wanted, but that crept in anyway. It's a bit narrow to think of software solely in terms of "defect density," but that's the stick that gets waved about.
In the information pyramid, it's very interesting to note that defects can creep in at every stage of the software deployment process—from blue-sky research to consumer adoption. The two that we're most anxious about these days are defects in execution, commonly called bugs, and defects in intent, which are hostile features. Both are "put into" software—to use the engineering parlance—by technologists or programmers. Both are put in during the software build part of the process.
The best defense against a high defect density is review. Two heads are better than one, and review provides fresh perspective that can locate flaws that are otherwise ignored. The best kind of review is independent peer review, because then there's no collusion or ignorance to hide behind. Independent peer review is a widespread process tool. Lawmakers use it. The medical profession uses it. Science uses it. Accountancy uses it. Independent peer review is a standard instrument used to test the probity and transparency of any process that depends on human factors.
It's interesting to note that independent review already occurs at many points in the software information pyramid. Academic review of papers, black-box testing of software, and market acceptance of final product are all examples of peer review with some degree of independence. There is a very weak link in the chain of review checks and balances, however. While software is being built—after the academia is over and before market acceptance is tested—frequently we have weaker review. This is a hole in the process through which defects can climb in. This is also a significant reason why software has such a bad reputation.
Review Without Peer
This software peer review hole is not universal, but it is very common. Commercial corporations sometimes do independent peer review. Sun's Java community is a vigorous example. It's in commercial corporations that independent peer review is least used, though. The lack of aggressive and unfriendly scrutiny of the crown jewels increases the number of "defects in execution" that are missed. The lack of political will and the profit motive guarantee that many "defects in intent" will remain. A feature that brings money to a vendor is a defect of intent from the consumer perspective. It's a commonsense idea: If everything else is equal, consumers would rather have software that doesn't lock them into future spending. Consumers would rather have software that just does what they want it to do. They'd rather not pay vast sums for inkjet cartridges, to draw a parallel example from consumer electronics.
On the other hand, most open source projects that are of any meaningful size have excellent peer-review processes for "defects in execution." The slow-but-steady forward pace of many such projects and their high availability and security of mature projects is ample evidence. Good examples include the Linux kernel, GCC compilers, and the Apache web server. Open source projects are not perfect—a certain critical mass of effort is required—but overall the transparency of the software encourages and supports peer review.
The argument between software products such as Microsoft Windows and Linux has lately been bitterly fought on the field of stability and security. When you examine software production from a process perspective rather than a feature perspective, it's clear that closed commercial software can't ever hope to be free of "defects of intent." Furthermore, closed commercial software can only match open source software on "defects of execution" if the investment made is large enough to compensate for the weaker review processes that closed source projects use.
Bad Alternatives to Peer Review
The value of peer review in open source is very discomforting for commercial companies. It's no wonder that vendors such as Computer Associates are starting to release their in-house products into the open source world in the hope that they'll survive. In CA's case, the recent news is of Ingres. Informix was released some time ago. Berkeley DB, mSQL, MySQL, and Postgres/PostgreSQL have all been open source for some time. Only Sybase, Oracle, SQL Server, and DB/2 remain closed among the main database vendors. At the moment, this opening of some closed source vendors has some of the spirit of the early phase of the open source movement. Don't expect that feeling to continue forever. Expect to see some vendors throwing a cloak of rhetoric over the value of open peer review. After all, from a marketing point of view, peer review is a desirable attribute for a software product. Everyone likes the idea of approval. If you can't get or can't survive genuine but potentially hostile independent peer review and the consequential public fallout, you'll have to manufacture something that seems as good. That something is a rubber stamp, and rubber stamps threaten to ruin the improved consumer outcomes that open source processes offer.
Rubber stamps appear in many forms: patents, digital rights, and intellectual property are fairly weak examples. A stronger example is legislation that tasks software development with hurdle requirements: "Jump this hurdle and we'll give you this rubber stamp that lets you vend your product." The costly process of jumping through due diligence hoops is a barrier to entry for new players, regardless of the industry. Because open source products are relatively new compared with established players such as Microsoft, Oracle, IBM, and SAP, any such playing field is deeply tilted in favor of the incumbents. Dealing with the bureaucracy of multiple national stamp-providing bodies is nearly impossible for a loose collection of programmers distributed around the world.
Imagine a scenario in which a software developer must demonstrate that his open source software is free of security infringements, or even just that due diligence has been shown in auditing the software against a laundry list of existing best practices. Given the proliferation of security special cases, many of them obscure or baroque, that's a huge amount of work. It's a ridiculous imposition to apply to many open source projects, where daily releases are the norm. Security is important, but it shouldn't stifle innovation. It merely requires correct labeling. In an environment where desktops, web browsers, databases, and office tools are rapidly maturing, such a rubber stamp is a perfect way for a commercial organization to protect market share. If only the government can be persuaded that such legislation is a good idea, market share can be preserved, and closed source software can be ennobled with a quality that substitutes for independent peer review. Stupider things have been supported in legislation before, and such stupid things are in the works now, in a government near you.
Rubber stamps are not all bad, however. Some rubber stamps are worth having—safety standards, for example, or even just compliance with public standards. Even in open source, some ratification of current defect levels is probably a good idea. The problem is that rubber stamping is a process wide open to abuse by the powerful. If such stamps are legislated and bureaucratic, lobbyists and other special interests will make the stamp a brand mark that open source projects or other competitors can't acquire. That approach works directly against consumer interests, and against competition policy.
Preserving Our Peer Processes
If consumers are to have measures of software quality to inform their acquisition choices, that information must come in some recognizable form. Rubber stamps, however, are exactly the wrong kind of packaging. If consumers are to continue to benefit from the strong independent peer-review process that open source exemplifies, the equivalent of a rubber stamp needs to be independently peer-reviewed as well. End-to-end transparency is the only possible solution, with no exceptions.
Like the stock market, the health system, the economy, and the environment, the information we need as software consumers is a set of technical indicators, not a set of rubber stamps. It's easy to produce indicators of software size, complexity, or quality. David A. Wheeler's website, for example, lists a number of independent statistics that reflect the quality of open source products according to a number of different definitions for "quality." There is no single, sanctified definition.
We need academics to argue what the leading indicators for software defects should be, and we need them to resist the special-interest arguments of those that would distort or avoid the statistics. We need independent bodies providing regimes, audits, and tests that can be used to produce indicators of anyone's software. We need the results transparently reported, and we need a graduated system that creates absolutely no barriers to entry, so that innovation is not stifled. After all, many people are happy to use software that's "Yet to be adequately completed: quality still low." That's the basis of many open source and commercial beta programs. Labels to that effect are surely overdue for many software products.
Such quality indicators are all rather awkward if you're a vendor that doesn't want to show anyone your source code, littered as it may be with the defects of intent that you put into it on purpose. They are a must for consumers, though. Alas, we know more about the contents of a jam jar than we do about the software we use.