Faulty Premises... Insightful Conclusions

I have been following a discussion on Cato-Unbound, the Cato Institutes' Online Journal. The discussion this month Centers around an article by Jaron Lanier, entitled "The Gory Antigora" centering around the different paradigms of "digital meeting arena[s]." He creates a distinction between Agoras, which are open, Antigoras, which are closed, and semigoras, which are in-between. To clarify what type of open-ness and closed-ness, his examples were Microsoft, Ebay/Amazon, and Linux. These paradigms are interesting, and I think important ones, but the surrounding text is so strangely constructed, it is difficult to get to the point Lanier wants to make about the different paradigms. While it is easy to be a critic, and much harder to be insightful, as Lanier has been in many fields, I still feel that the structure he built in this essay would be better if stripped down, and focused more on his new models of these digital arenas.

Firstly, it seems that the entire concept as he uses it of digital lock-in is an incorrect one¹, founded upon, as Eric S. Raymond put it "mistaking a contingent property of Microsoft Windows for an essential property of software." To begin, I think it is instructive to look at the conclusions he draws, in order to better understand how exactly he gets to that point. He concludes, near the end of his article, that as the complexity of the hardware software hybrid system grows, what is built upon it must be more cultural rather than technological.

The conclusion, however strange it seems in isolation, is built upon a logical structure, one that, to understand it correctly, must be broken down into several components. The first of these components is the difference between so-called flexible and inflexible systems. Mr. Lanier claims that there is a difference between biology and computer programs is that changes in the input in biology have a gentler, less chaotic relationship on the output than in computer science. Without us examining this yet, he then proceeds to say that this is what leads to vendor/technological lock-in, that is to say, since software in inherently brittle, once a solution is being used, the costs to more are so high that it becomes impractical. Additionally, this leads to problems such as: the inhumanity and discrete nature of computer systems, a loss of ambiguity, and the failure of Virtual Reality, not to mention the breakdown of traditional law due to the impossibility of ambiguity in the system. A rather gloomy vision, all due to the nature of digital software.

But is it actually there nature? Starting at the beginning, it seems that we are stating a fact: computer based systems are more brittle than biological ones. The example Jaron gave was the difference between a change in a computer program versus a change in the human genome. Without falling back to Eric Raymond's description of this as "a factual howler," I still think that it is an invalid analogy, that slipperiest logical device. You see, the nature of biological organisms is one that, as we understand it, evolved to evolve. It was created in it's form as a organism of chance. Despite this, slight changes in something like the chemical structure of it's air, kill it almost immediately (carbon dioxide vs. carbon monoxide, for instance, something that would not break a computer.) Computers, however, are not intended to be this way regarding their structure. Random changes in program code are not part of the normal design process of typical computers, and when they are, such as in the case of evolutionary coding, they seem to work. Random changes in input, however, are dealt with pretty well. It seems that depending on what exactly we are discussing, computers may not be so brittle after all.

Of course, it is easy to pick flaws in analogies, and not altogether fair - maybe his points about the brittleness of software are true. Maybe software cannot be made so that it adapts well to changes. A "point mutation" in a piece of Perl code, for instance, is certainly disastrous to the usefulness of the code, and certainly does not produce a subtle change in the output. More to the point, computers crash. They lose data, they freeze, they simply stop turning on. This is a typical experience with modern computers. As the joke has it, if cars were made by IBM, they would go 5000 Miles an hour, get a hundred thousand miles to the gallon, and explode once a week, killing everybody in a ten foot radius. This, of course, is the hazard of thinking that cars are built like computers. Cars, as unsafe as they may be, are not allowed to explode. It doesn't really matter if a user-PC crashes. Of course, if you run life-or death software, you shouldn't run Windows. I'll never forget seeing for the first time the warning in the Windows 95 EULA that it is not to be used for life support equipment, or nuclear failsafes. So instead, for mission critical systems, people used embedded, or Unix-based systems. It's a question of the right tool for the job. For software that needs to be adaptable, different design principles are used than in software that needs to be fail-safe, and yet other principles are used for consumer software, where price is important, or embedded systems, where changes cannot be made post-production.

Of course, vendor lock-in still occurs, so the argument I'm making must, on some level, be a false one. Of course, the question of vendor lock-in is a complicated one. If I'm using $1 million of hardware, and another $5 million in proprietary software for that hardware, my costs of changing, or even upgrading hardware will be higher, especially for radical changes. This, however, is true of most complicated systems. Picking something almost completely apart from computers, let's say I own a fishing fleet. If I have $1 million worth of ships, and another $5 million invested in training of my crews and equipment, then upgrading my boats to use different navigational techniques, or changing my methodology of fishing would probably cost a commensurate amount. The problem with vendor lock-in is not one that emerges from the nature of code, particularly, but from the nature of any activity which may change that requires investment of time or capital. The lock-in is a problem inherent in the fact that systems are different. The rigidity isn't one of technology any more than it is of any system.²

A claim is made about the source of the lock in; it is a product of the precision inherent in computers. To quote, "human ideas that have previously been functional in part because of ambiguity must be stated precisely for the first time, and it becomes much harder to withdraw or modify an idea once formally specified." Of course, any large scale human endeavor requires a similar level of specification. Ships passing in the sea need a certain degree of precision to not collide, and once on co-ordinate system is picked, it becomes harder to switch. Imagine two ships that see one another; the first ship says: "I'll go east" and the second replies "I'll go towards Carthage." This is a problem inherent in communication. The precision question is a philosophical argument between logical positivists and ordinary language theorists, and does not really jibe, according to either theory, with the assertions made. The problem isn't with the precision of the concept, nor with the ambiguity, but with the fact that these systems are in fact so rigid; This has nothing to do with the system's inherent properties, but with the design of specific systems. Look at media players; I have one on my desktop that, when opened, can simply accept click and dragged media files. It avoids the problem of rigidity by... being flexible instead.

On the other side, if someone talks to me, with my continuous and hopefully not particularly rigid mind in Chinese, for instance, I happen not to be sufficiently flexible to deal with it. To mis-paraphrase, "but the horrible, limiting ideas of English are now locked-in. We may never know what might have been."

However, it is unfair of me to deal with the build up of an idea, and then ignore the ideas themselves. The concept of an agora, or marketplace, is one of free exchange of ideas and products. The bazaar that Eric Raymond discusses is one aspect of this marketplace, but not, I think, the one that Lanier is interested in. He is interested in, instead, how transparent the software is. The concept of natural monopolies has little to do, it seems, with the lock-in aspect. The key point that this focuses on is something that has little to do with the way users are stuck in a system, and much more to do with how they interact.

In Lanier's usage, the point of an antigora is that it is monolithic, and work is done around it. For operating systems, as he rightly points out, this is good. The fact that the work done is completely dependent on the monolith is not a problem, and it is a useful center piece. An agora, by contrast, is a marketplace - the interaction happens inside the system. This means that, for instance, with Bittorrent, the system is what occurs. By this I mean that the entire system as it is used is simply a pathway for the users. Similarly, in many ways, is an operating system like Linux - the development and the working OS are so closely tied together that the medium is the project. The third paradigm, that of a semigora, is between the other systems - the system is a fixed one, but the interaction that takes place is embedded and integral. Amazon would exist without it's users, and books could be ordered, but it would miss the point of the system that was built. This would also seem to be the paradigm of an open system not built by it's users, such as a commercial Linux distribution.

The point of how interaction occurs, of course, is Lanier's main thrust, and one that gave me an insight as to how the network as a whole could be viewed. The point cannot be, and is not, that the system is an independent entity. It is clearly dependent on the system on one end, and the support structure that is used to let it function. This system of technology is not the internet, it is simply a network. The other side is that the people investing in the system are not the system, because they cannot accomplish what they now routinely do, without the system. They are the layer above the network, and eighth layer in a seven layer model, which allows the network not to function, but to be what it is.

To conclude, I think that the point that Lanier leads to in the end of his essay is not that culture is the backbone and the product of the internet, and more than any human interaction is. The internet is simply a field in which either culture, capitalism, or exploitation can occur, and like all human interaction, it is up to us to decide how to build a structure that will encourage the only thing that seems to be worth the effort; the uniquely human quality, that of social interaction.



¹. I would contend, rather, that the digital lock-in becomes less important as layers are built, since systems become mostly interchangeable at any level lower than the one currently being used. Many operating systems can run on multiple types of hardware (and most hardware can run multiple OSes.) Most application suites can run on more than one OS, (and most OSes can run more than one application suite,) so the transfer is easier than it first appears.

². In fact, due to the layered nature of software designs, it seems that it is in fact easier to change a software layer than to change a different piece of technological equipment. Redesigning a spaceship, as NASA has recently been challenged to do, requires completely scrapping almost everything they have done with the previous types. In software, switching from a text driven database to a SQL driven one is hopefully much easier. In fact, if it was designed well, with the inevitable upgrade process in mind, it takes almost no time at all. The transition between different networking technologies is similar: I can rip out an entire network and replace the networking hardware, switching from a simple 100 computer Microsoft network to an Linux based network system, literally, over a long weekend.

This post was updated 1/21 with the two footnotes to clarify a couple of points, and fix a couple stylistic issues and capitalization problems, as well as spell check to fix my consistent misspelling of the word "piece," once I realized that Cato linked to it, and people might actually read it.