The Failure of Shrinkwrap Software
(c) 2003 David Stutz
This article, entitled "Since When is Integration 'Innovative'" reminded me of a discussion that I had with Doc Searls in July regarding the nature of software, consumer perceptions, and product liability. Mary Jo Foley's observation that licensing, deployment, and maintenance relationships are as important as the technical mechanisms used to integrate software systems is a great one, and fits well with Doc's worldview.
The software industry has a dearly held belief that installable applications can and should be treated as packaged product, to be sold to consumers at retail like a bottle of shampoo or a box of dried pasta. Over the years, billions of dollars have been spent creating this illusion. What began as a consumer phenomenon with things like Microsoft Word, RealPlayer, and now iMovie, has spread into the market for enterprise software. Vendors make claims about "integrated innovation" and "pre-tested distributions" and "end-user programmability," but what they are doing is propagating the myth that software can stand alone. Software companies are desperately defending a business model that has not stood the test of time.
Of course, alternative business models to software-as-shrinkwrap exist. Noise has been made by software companies about an impending wave of 'software as a service' (which in the boxed software business seems to be nothing more than a lucrative annuity to be added on top of revenues generated by licensing software updates). But the same companies have not yet cracked the business and technical problems associated with creating reliable consumer services that can be effectively tied to shrinkwrap. Notable failures include Microsoft's "Hailstorm" as well as Sun's several Java-based services. Convincing customers that such services possess value above and beyond the value of the underlying shrinkwrap product is problematic. In the face of such skepticism, software companies understandably drift back towards their status quo, which includes such desirable characteristics as very high profit margins, docile distribution channels, and advantaged legal positions with regard to issues such as product liability.
Despite the collective state of denial that exists in the industry, the mundane truth about software and software services continues to become more and more obvious: machines, driven by software, are an essential part of the fabric of our day-to-day lives, and the software that drives these machines is nothing more than a commodity building material. In the mind of those depending upon the software, whether they be an IT shop, a PC user, or a person calling 911 on their cellphone, the combination of hardware, software, and service is completely amalgamated. Software does not stand alone, nor do services. The open source movement reflects this realization, and its structure presages the future of the commercial software sector. Open source software does not reflect a "new world order," but rather a first approximation at the way that businesses will incorporate software into their operations in the 21st century.
Seeing software for what it really is
All computing devices depend upon the successful integration of components from many sources. Even devices that might seem to stand alone, communicating with the world through nothing more than the human senses, use software and hardware that have been cobbled together internally. Such standalone units, of course, are now becoming rare, as computing devices are increasingly likely to be integrated into larger networks of software and services. A huge range of integration techniques exist, from the low-level mechanisms used to bind software components together when building computer programs to standards that can be used to author web pages, to send documents to printers, or to beam GPS signals earthward.
Just like structures that are joined together from component parts in the physical world, things built using hardware, software, and service components degrade in the face of change. Because of this, they also demand constant attention. The craft of making software-driven machines is defined by a process of constant rejiggering. Until tools and software systems become far more advanced, the old dream of mass-marketable, self-healing products will not survive the harsh environment created by hostile hackers, governments, corporate competitors, and demanding consumers. Stand-alone PCs are susceptible to viruses, cellphones are susceptible to changing infrastructure, and even things as simple as appliances are susceptible to changes in the environment that surrounds them. The right way to view software is as pliable building material, rather than as finished product.
Because of this, Doc's metaphor of the software industry as the construction industry is nearly perfect: those who build and maintain software are like the millions of architects, builders, and contractors who help us maintain and preserve our homes, businesses, and public places in the face of dryrot, hurricanes, vandals, changing family sizes, and all of the other forces that conspire to ruin them. The guild of craftsmen who join software to service, software to device, and software to other software are not factory workers cranking out uniform widgets. They are journeyman integrators who create vernacular items matched to quotidian requirements. Of course there is a mass market, but mass market software, like any other prefab item, is destined to be far less than perfect.
In my experience, people understand the approximate nature of real-world construction projects. The delays and unforeseen contingencies are frustrating, but also explicable. If the software industry were to present a similar face, people would be much more likely to understand the presence of spam, viruses, bugs, intermittent connectivity, incompatible systems, or any of the other plagues that assail the innocent victims of software/hardware/service amalgams. They would also be much more likely to participate in the solution of these problems through the application of social mechanisms.
By adopting Doc's metaphor in place of the shrinkwrap fallacy, society could begin to seek the conventions, legal theories, and marketplaces that will inevitably emerge to correct current abusive practices, ownership disputes, and liability issues. If hardware, software, and services were commodities to be spliced together, it would be easy to understand how to fit them into our existing framework. If those who make software were to be held responsible for what they build, why wouldn't there be the equivalent of zoning laws, professional organizations, bureaucrats responsible for public safety, and all of the other individual roles and social mores that combine to make buildings and bridges much safer than they were at one time? It will come to pass, but slowly.
Unfortunately, there is no easy path to this outcome. Despite the isolation and lack of empathy that will result, proprietary approaches to software construction are likely to remain the favored approach espoused by software companies. Corporate inertia and the advantages associated with the status quo are both too compelling to be rationally dismissed; current business models work so well that only catastrophic changes in market dynamics could spawn radically different ways of doing business. Microsoft and the other companies who have built their marketplace positions by cleverly leveraging control of software integration standards have an interesting choice to make. Will the upcoming wave of network integration standards such as Indigo reflect a desire to make the life of the journeyman integrator safer and more productive? Or will they point toward yet another wave of sub-standard prefab systems, rich in features, but difficult to maintain and even more difficult to combine? Only time will tell, but I am very skeptical that any substantial change will occur.
Of course, the market forces associated with commodification will continue to put pressure on the less socially efficient approach represented by proprietary software integration mechanisms. Practical people everywhere will continue to recognize and adopt alternative approaches to building software systems. Ultimately, the friction between software-as-shrinkwrap and software-as-commodity will lead to shrill and contentious posturing in courtrooms and halls of government, which will undoubtedly be both unpleasant and counter-productive. (Imagine a scenario similar to the circus that currently exists around music file sharing; no one wins in this kind of spectacle.) There is certainly opportunity in this bleak future, but journeyman beware!