| The New Walled Gardens |
View Comments
| Written by Lefty Schlesinger, Director of Open Source Technologies, ACCESS |
| Wednesday, 06 May 2009 10:33 |
|
Consumers’ first exposure to the internet came via walled gardens for most people: America Online, Prodigy and Compuserve all offered a degree of access to the network, but at the cost of a variety of limitations to access and a great deal of control. In time, those walled gardens withered away, replaced by unmediated access. Similarly, mobile data services have, for years, been similar walled gardens, and in the same way, those efforts to “rope in” users are becoming untenable. Today, we see other walled gardens springing up as the old ones wither away. The new walled gardens are different, however: they’re about the ability to write software for, and to add software to, devices that are much more capable than older cell phones (and even many of the computers we used when we were using AOL to get to the network). The walls around these gardens are defined by programming models, by application distribution (and the policies around it) and most importantly, by platforms. Apple’s iTunes App Store, and the entire ecosystem associated with the iPhone, is an excellent example of one of these new gardens. The walls consist of an idiosyncratic programming model, one which uses non-standard languages and its own set of programming paradigms, as well as the store itself. Writing an application for the iPhone involves an investment in learning how to program for the device in Objective C—knowledge which is non-transferable to other contexts—as well as a fairly large “leap of faith” that Apple will actually accept the application and place it in the App Store for distribution. Android, similarly, attempts to lock in developers via similar means. Applications for Android can only be written in Java, and not even standard Java, and must be created to fit within the Android application framework. Again, this involves a fairly steep learning curve, and the learning is essentially unusable anywhere other than in the context of Android. What’s the attraction for these platform purveyors? Mostly—as with the early attempts at facilitiating internet access—it’s an attempt at a mechanism of control: control of the users, but this time at second-hand. Control is exerted via the development community associated with the device, and the expectation is that the availability of applications on a given platform (and their presumed unavailablity on others) will act as an incentive to coax users to stay with the device they have. Experience shows that these efforts are generally failures. AOL and the like had to be dragged, kicking and screaming, to the point of allowing unmediated access to the net as opposed to their little Disneyland-ified portion of it. People want freedom, and people don’t like to have stumbling blocks put in their path. Developers, on the other hand, want to write programs the way that they’re used to doing, and they want their work to be as widely available as it can be. Both of these factors conspire against the success over time of the current batch of walled gardens. We can see some of this beginning to happen in the area of MID devices: mainstream Linux is getting to be a popular choice there, and there are increasingly impressive efforts to adapt the basic Linux desktop user experience to these smaller devices. There’s a well understood programming model for these devices—it’s the same model used on the Linux desktop and on pretty much all devices based on mainstream Linux distros. This is the same programming model that will be exposed on the next wave of “open phones” coming from LiMo Foundation members. This is a core difference between the efforts of organizations like LiMo and others: LiMo is not reinventing a new wheel in order to “lock in” developers—and by extension users—to a particular device. The programming model, architecture and components used in a phone based on LiMo platform software is largely identical—in the open source portions, certainly—with any Linux-based desktop. Programs are developed and tested in the same ways, and programmers aren’t asked to face a learning curve that only enables them to program for a single device. One answer, and one which will be popular in some areas, is the idea of web-based applications, using Ruby or AJAX or any of the various “Web 2.0” development models. This is attractive in that there’s a lot less risk of being locked into a single platform but again it comes at a cost: not all applications can be readily adapted to running out “in the cloud”, and not all should. But in the meantime, efforts like BONDI, etc., offer some short term relief for at least a class of developers. In a free market, “open” generally wins over “closed” in time. Closed systems—and a walled garden is simply a somewhat larger “closed system”--ultimately frustrate both their developers and their users: the developers because they can’t do what they want, whether because they’re trammeled by programming models of by distribution models, and the users because they find they can’t get access to the programs and facilities that they want. Open will eventually win over closed in the mobile development marketplace and for the same reasons: people won’t stand for any more control exerted on them than they have to. And that goes for both developers as well as for end users. |
