Thursday, May 21, 2009

The New Walled Gardens

(This post was originally published on the LiMo Foundation blog...)

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.


Anonymous said...

Android is OpenSource, brotha!

There's an experimentell Maemo-port for Android. Bringing Android to Limo or Moblin shouldn't be a too big problem neither.

Shivan said...

copying what I put on the other blog:
yadda yadda
look at the middleware, between "Database" and "Multimedia Framework".
There, you got it, I'm out.

Scott said...

I think you're stretching in characterizing "more" open as meaning "using a more common programming model".

The only way you can do a consumer-friendly app store is to standardize a lot of the environment for programs (access to services and interactions), which amounts to constraining the programming model.

I tend to think of open and closed more in terms of what you can actually put on the phone and whether it's sufficiently standardized that you CAN develop apps that work across the breadth of the platform.

On those criteria Apple loses on openness, because they have a vendor-controlled app store. Android has, as I understand it, an open app store. Does LiMo have an app store at all?

On standardization, both Apple and Android are (as of this moment) sufficiently standardized, though I'm less convinced that Android will stay that way once it has multiple vendors in the market. LiMo didn't used to even have cross-device compatibility as a goal - does it now?

I used to argue, at my previous, mobile-phone-centered employer, that real opennes (consumers' ability to choose what they put on their phones) would ultimately win the market. I still think it might, but I don't think it's commercially interesting for a long time - until phones aren't much like phones, anymore.

In the short term, you need the kind of constrained environment that a strong platform provides to meet consumer expectations; the freedom of the Linux desktop is why it's a tiny niche market. You and I might like a truly open Linux phone, but nobody I know personally, outside contacts in the OSS world, would. They want pieces that work together and that look smooth and consistent. Honestly, they mostly even wants the incremental security of Apple's more-constrained store, though they may chafe at some of the non-security limitations Apples enforces, like banning "offensive" content and competing products.

Anonymous said...

Hi! Your blog is simply super. you have create a differentiate. Thanks for the sharing this website. it is very useful professional knowledge. Great idea you know about company background.
Increasing your web traffic and page views Add, add your website in

michaelvk said...
This comment has been removed by the author.