The Failure of ShrinkWrap Software?

The first problem I had with Dave's essay is that he never explains why shrink wrap software has failed but instead seems to take it as an article of faith. Specifcally I look at his opening paragraph

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...What began as a consumer phenomenon with things like Microsoft Word, RealPlayer...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.

and notice that he never backs up his claims which is unfortunate because I agree with some of his points but don't think he made very convincing arguments. Before going into the meat of his article there is one part of the introduction that stirred my inner nitpick gene.

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'...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.

From where I sit, the core idea behind Hailstorm was not to tie consumer services to shrinkwrap software. The core idea was enabling a new set of applications by creating shared schemas for common forms of content and vendors expose this content to various information aggregators. In fact there are a number of similarities between RSS, news aggregators and the Hailstorm vision. From the few demos and papers I read the main problems with Hailstorm were that there was little incentive I could see for vendors to expose such important information to others and the service was centralized.

The interesting thing is that RSS is slowly reinventing the Hailstorm in a decentralized manner. There is a common schema for news items (RSS 2.0) and software that aggregates information the user is interested in from disparate sources both client-side or server-side (news aggregators). People are slowly realizing the power of this and already there is sometalk of shared schemas for calendar events. I don't doubt that in the next year or two the information aggregation space will end up looking a lot like a decentralized form of Hailstorm. In fact, there already have been moves toward some degree of centralization in ways that users will request more and more.

I suspect this connection between information aggregators and the most hyped XML Web Services vision is why you find XML Web Services gurus from various vendors such as Don Box (Microsoft), Mark Nottingham (BEA), and Sam Ruby (IBM) taking such an interest in RSS and the like. I doubt that there is some sort of conspiracy but there is probably the recognition that RSS and the like have basically done what the original XML Web Services hype claimed it would do.

Anyway, back to the subject at hand.

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.

I agree with the basic premise that software has to keep evolving to deal with changing landscapes from malicious hackers to competitive marketplaces. Figuring out exactly how this evolution occurs is the tough part. Automatic updates can only go so far but they seem to be the best way we've come up with to deal with the kind of problems Dave points out (hcrackers, changing network environments, etc). I am unsure of how viewing software as a building block of a larger system as opposed to a finished product helps this vision but I'll soldier on through the article.

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.

...

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 I understand his metaphor correctly, instead of buying a copy of Microsoft Word from the store a person or company instead hires someone tp put together a text editor with the features they want (e.g. basic text editor + spellcheck + XML output mode) and can hire others to maintain and update this core package as needed. What surprises me about his metaphor is that this is basically what happened in the past where folks had to write their own apps or hire contractors/consultants/etc to get the applications they required and eventually this lead to the shrinkwrap market. Customers (both individuals and companies) prefer to deal with one vendor and standardized packages than micromanaging the software procurement process. Hiring consultants is a last resort and I doubt that many people want to move to a world where doing so is the first step. Of course, this may also mean that businesses have programmers on staff the way they now have IT departments which I think is a step backward because we should be trying to figure out how to eliminate IT departments not make them bigger.

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.

As Don Box pointed out Indigo is the code name of Microsoft's implementation of network standards not the standards themselves. The network standards in question used to be called GXA (short for Global XML Web Services Architecture) although I'm not sure what they are called now. As for whether XML Web Services really will allow for better intergration, this has less to do with the technology and more to do with the vendors. Just as I mentioned earlier about vendors needing incentive to expose valuable information about their customers or products via Hailstorm this is the same with XML Web Services. The fact that web sites can syndicate their content as RSS and thus benefit their readers who use news aggregators does not automatically translate to the fact that all sites will provide RSS feeds full of metadata. The same is true of XML Web Services, it will make it easier to interop but whether interop actually happens depends on various vendors supporting the technology. Another example, the fact that XML is more open than binary file formats hasn't made all vendors switch to using XML (although various office product suites such as Microsoft Office and Open Office have) file formats. However there is market pressure for the software industry to do a better job of interoperating in diverse environments which makes me confident that once the dust around XML Web Services standards settles there will definitely be an interoperability gain.

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,

I'm not sure what he means by commodification. When I think of software as a commodity, I think of the lowering of the initial cost of software caused by movements like Free Software and Open Source. However Dave's article is mainly about building modular software that enables extensibility than it is about giving out the source to your application and allowing redistribution of [modified versions of] said source. I guess one could argue that to maintain software one needs source code but using Dave's analogy does my plumber need the blueprints to the house to fix a stoppage? Closer to home, do anti-virus and firewall programs need the source code to Windows to do their job?

All in all, an interesting but unconvincingly argued essay from Dave Stutz.

#

Clark for President

I see Howard Dean is pissed Wesley Clark is getting support from members of the Democratic Party, well I'm glad as hell about it. Howard Dean was definitely too much of a leftist to win enough mindshare to oust Bush but Clark on the other hand looks like he'll get the support of the average Joe. This is great, for a while I was worried that the chances of 4 more years of invade-countries-over-bullshit-reasons-while-turning-the-USA-into-a-police-state where a 100%, now it looks like there is a fighting chance to change that.

All I can say is Clark for President, biyatch.

#

Are We Hot Or What?

Tim Bray was recently interviewed by C|Net and he had nice things to say about the XML stuff we're doing here at B0rg Central. Specifically

The XML standard is partly meant to set the grounds for the free interchange of data. Are you concerned about companies piling proprietary stuff on top of the standard?

...

To the extent that I've looked the (XML) formats for Office 2003--I can deal with them. They're not simple, but then, Word isn't a simple product. But if need be, I could write a script to process a Word XML file and extract the text of all paragraphs with certain references--which would have been a very daunting task with previous editions of Word.

So, yeah, there's room for concern. As an industry, we have to be vigilant to preserve open access to our own data. But we are moving in the right direction.

You've made some comments about XML being too hard for developers. Does that still hold true?

...

Having said that, in terms of interoperability and openness and attractiveness in the marketplace, it's more than worthwhile. The answer is better software, and we're getting that. In particular, the XML handling class in .Net is a substantial step forward from what's been available before in terms of the amount of work required to get the job done.

...

It's good to see our efforts getting credit every once in a while. Thanks Tim.

#


--
Get yourself a News Aggregator and subscribe to my RSSfeed

Disclaimer: The above comments do not represent the thoughts, intentions, plans or strategies of my employer. They are solely my opinion.