Arcadian Visions

Nick Carr suggests some reading, including a provocative post from Jaron Lanier. To extend the link chain just once more, Jaron’s post was made as somewhat of a response to an article by Freeman Dyson. Phew.

Lanier’s point is that work in private can produce good things, or, more pointedly, better things than more public, open-source methodologies. My initial reaction to this was not exactly one of surprise.

Jaron’s portrayal of open-source as being eminently capable of producing polished clones of existing artefacts, while struggling to produce large-scale paradigm shifts makes a lot of sense. Of course, one has to couch all these claims and descriptions in some meliorating language. Namely, even if you, unfairly, view Linux as a purely derivative product, its continued development, making it a better and better product, does change the operating system game in terms of redefining what a potential customer expects from a product, and what that customer is willing to pay for. However, it is quite a bit harder to make the argument that Linux, in and of itself, represents a bold new direction for operating system design.

Importantly, one does not need to categorically decry either open- or closed-source development to consider Lanier’s submission. What seems clear is that the act of copying an existing artefact has the significant advantage of inherently providing a shared goal for all contributors. There is a platonic truth at the core of the effort captured in the object being copied itself. Unfortunately, the development of something substantially different from what has come before must instead rely on much more mundane forms of communication, and this is where closed-source development can have an advantage.

Once an artefact has been created, it may speak for itself. But until that time, the responsibility for communicating that artefact’s nature lies in the, effectively, side-band communication capabilities of its designers. The development process itself may in fact be viewed as the attempt to communicate this new idea. Unfortunately, without tangible evidence at hand, most people are unable to sufficiently convince others of the worthiness of one particular goal over another such that potential supporters are willing to set aside their own misgivings over particular design choices. A silly analogy is the fabrication of a chair. If you and I are to copy an existing chair, then who am I to disagree with the plan that we give our chair four legs? But if we are instead tasked with inventing a new mechanism for supporting the human form, then who are you to tell me that we must give our device four legs?

We are able to resolve, for better or for worse, the problems engendered by our own communication shortcomings by barter: I offer you some amount of money to follow my design. That way, a design that I couldn’t possibly implement on my own is brought into the world. Of course, closed-source approaches fail at least as often as they succeed, for hidden within the simple-to-express notion of, “I’ll pay you to follow my plan,” is the necessity that the contributor bring his or her own ingenuity to bear in figuring out how best to implement the given plan, or even improve it with the designer’s consent. We don’t want smart workers stupidly following orders, but we also don’t want too many chefs in the kitchen. No, there is still a place in the world for the cathedral and the bazaar. Neither can accomplish all that the other is capable of.

So, what motivated Lanier’s potential-flame-bait-yet-simultaneously-easily-defensible article? I can’t say for sure, but I think a lot of it stems from a single phrase in Dyson’s article describing the detrimental effect of speciation on Darwinian evolution: “It probably slowed down the pace of evolution considerably.” Delivered in such an off-hand manner, this statement doesn’t invite much scrutiny, but I think that this is where the disagreement begins. The comparisons to technology development are no stretch at all. The question is, does providing momentary succor for a single voice in the chorus facilitate the creation of something new, something better? Researchers do not scatter their best thoughts across peer reviews, they must instead cultivate some ideas in a controlled environment — asking for input from select others, working through the details themselves, maybe getting a post doc. to run some experiments — and present the seeds of the idea as a cohesive whole that has grown to something substantial enough for others to evaluate. This closed development is how complex communication is achieved, and while it may slow down diversification of ideas, or genetics depending on which branch of the discussion you find more compelling, it strongly supports the effort to strike out from today’s local minimum.

Some comments on an Ars review of the Eee PC note some surprise that Linux’s spread into mainstream consumer electronics is happening care of the low end of the hardware spectrum, as opposed to the high end where most desktop PC Linux fans feel it really shines.

What’s really happening is that the cost of software is being made more and more visible the cheaper the hardware gets. When you bought a $2,000 PC ten years ago, the fact that you paid another $100-200 for Windows wasn’t such a huge factor in most people’s minds. But if the cost of the OS doubles the cost of the purchase, well, that’s something people tend to notice. Note that this says nothing about the value of software in general approaching zero, or anything like that. Instead, it’s making a decision that was viewed as abstract to the point of absurdity by many, into something with real weight: how much is Windows worth to me? Consumers must ask themselves this question when considering any other piece of software, but the OS is both essential to the use of the computer, and it has been seen as a free throw-in from whoever sold the computer. Now that the OS can no longer be viewed as a freeby, historically unquantified benefits of Windows such as superior device support and user friendliness are being quantified, and a price tag is finally, truly being put on them.

So Linux’s advantages may now be nearing full operational status: you can go back and forth about device support and ease of use, but the Linux side will always have price as a kicker. A kicker that, until hardware prices dropped below a certain threshold (apparently $500 or so), wasn’t worth much, but is now worth a fortune.

Stephen O’Grady suggests that Google providing their own package repository may herald a future of ISV-managed repositories as part of a trend of distributing the power of the distribution maintainers. I hope not.

The problem with the strategy of providing your own repository is that you’ve lost one of the biggest advantages of a package management system.

The three main benefits of a package management system are, in short, (a) ease of discovery, (b) ease of installation, and (c) ease of maintenance. Given that quite a few applications (on every OS) come with automatic update mechanisms (e.g. “check for updates on startup”), item (b) isn’t a hugely differentiating factor. Item (a) really only exists because everything is already there when you install the OS. You don’t have to find the ISV’s website to download anything, since the package management system already knows how to find it (e.g. just type in “Ruby”)… which is not at all the case with ISV-managed repositories. That leaves you with ease of installation, and I do not think the process of setting up Google’s repository in, for example, Ubuntu qualifies as “magic.” If users start getting lots of their software from Google’s repository (perhaps even software only hosted, but not developed, by Google), then the one-time installation cost is fine. But that takes you right back to centrally-managed repositories vs. ISV-managed ones.

No, I think what Google has done here is a very practical avoidance of writing their own automatic update routines into every piece of software they write. It makes good sense, but I don’t think a proliferation of ISV-managed package repositories represents an appealing future of supposedly easy software discovery, installation, and maintenance.

When I read the WWDC 2007 coverage (or here, or a dozen other places), what I heard was the first real cry for offline web apps. On desktops and notebooks, web-based apps are trying to displace desktop apps that don’t generally have an offline “problem,” but Apple has, at this point, forced the issue by creating a popular (?!?!) platform with no desktop apps to displace.

This completely changes the value proposition of offline-enabling technologies like Google Gears. If the iPhone is to be used as any sort of general computing device (not just a phone, and not just an iPod), and all 3rd party applications are to run in the browser, then it is absolutely necessary that there be some offline capability for web-based applications. There simply is no option.

This new-found dependence on Safari is consistent with the just-released Safari 3 Beta for Windows XP, Vista, and OS X, and a deep reliance on Google technologies is consistent with the built-in Google Maps for the iPhone that seems to be demonstrated every time an iPhone is turned on. So, the big question, where is Google Gears for Safari?

I think Dare’s hit on a big question mark surrounding technologies like Google Gears: branch and merge. I’m sure that any programmer who’s used source control and thought about how it all works has come up with situations in which an automated merge just isn’t possible (e.g. two people edit the same line of source). In the server replication arena, the same thing happens if you have backup servers that fail a lot. With one failure, you can switch to a backup, and then playback the changes to the first system when it comes online again (or even do a full re-sync). But if the backup goes down, then the primary comes online, you’ve got issues. The first server will potentially present the user with a state that is inconsistent with changes the user has made. This is the same scenario that will be encountered by users interacting with web services in offline mode. Make no mistake: this is not a solved problem. There are always going to be scenarios that will reveal the fact that offline != online.

That said, I don’t think too many software developers using a one-user source code repository have any problem mentally recognizing the need for offline changes to be synced before they will be available from the server. It’s a valid question whether or not that understanding will be found in people using Google Docs in offline mode, and I think it’s also the case that, a deeper understanding of the situation notwithstanding, developers have an easier time of merging thanks to a usage pattern based on having many discrete files that can be edited independently (that is, merging the text is less of a problem even if dependencies can break the program). But my opinion is that it won’t be that big of a deal. Most users won’t be editing documents on multiple devices with any great frequency, so there’s less of a chance of stumbling into an inconsistent state. Moreover, despite specifically targeting the disconnected state of modern devices, I don’t think the people providing offline enabling technologies are arguing that that state will be anything other than a transient disturbance (e.g. going through a tunnel, cable’s out for an hour, etc.). In that case, the most critical question when evaluating the potential for trouble relates to a specific usage pattern: how likely is it that the first device a user connects to an online service after a period of involuntary disconnectedness is the same as the last device the user connected with? I’d say it’s pretty likely, and, in that case, manual merges won’t become a significant part of software usage for the masses.