Monday, June 18, 2007

Avoiding platform fragmentation

I'm going to continue posting regularly, but hope to do so with less time away from my day job. So bear with me as I try shorter posts.

One of the big problems that embedded Linux for mobile phones has right now is that it’s a technology, not a platform. Below is a slide from my presentation Monday at the DRUID conference on Apple’s iPhone strategy.

When I say “platform,” I mean in the sense of the seminal 1999 article by Bresnahan & Greenstein, or my own (far less influential) 2000 article with Jason Dedrick (which referred to a “standards architecture”, a terminology I no longer use). The leader in platform research is Anabelle Gawer of Imperial College London, who has spent pretty much her whole career since her 2000 MIT dissertation (on platforms) writing about platform issues, including the HBS book adapted from her dissertation.

At it turns out, I chatted with Anabelle last week at Imperial, we were presenting in the same session Monday evening, and chatted about platform issues at dinner (before devolving to more prosaic issues like how to raise a family on a professor’s salary in high-cost areas like London or Silicon Valley). (I used the same session and dinner to solicit other blog readers, like Hui YAN of Aalborg U.)

This morning, the near-solstice Danish sunlight woke me at 3:30 a.m. and I somehow never made it back to sleep. Trying to kill an hour (which turned into 3) I browsed through my RSS reader, and found an interesting article on LiPS, reacting to the same LiPS news I mentioned last week. Symbian developer Simon Judge believes that while allowing for vendor variation, LiPS will reduce the existing fragmentation of Linux on mobile.

Judge argued that the LiPS strategy of variation under standard APIs makes for a better platform than the Symbian strategy of variation on top of standard APIs:

The Symbian OS has evolved to push phone specific functionality (and unfortunately some non-specific) on top of the platform and this has resulted in UIQ, S60 and FOMA. These are not just UI variants but also include many extra internal and 3rd party APIs. Fragmentation is undesirable not only for developers but also for phone OEMs because they have to license extra software other than Symbian OS to create a new phone (or spend an inordinate amount of effort creating the missing components). …

If the LiPS extensibility scheme of pushing phone capability variations under rather than on top of the OS platform a) is workable and b) is adopted by phone OEMs, then it might actually prevent fragmentation.
In fact, Symbian OS is not a platform, it’s a shared technology that enables Nokia’s S60 and Sony Ericsson’s UIQ platforms. The fragmentation of the Symbian application APIs is unfortunate. Somewhere I read or heard that UIQ (which began as a cool pen-based UI) has more apps than S60, even though its installed base of S60 is 3x or 4x that of UIQ.

However, this is a painful reality of the political compromise that created Symbian as the anti-Windows Mobile coalition. When it was founded in 1998, (effectively as a Psion spinoff) Symbian actually tried to have a common UI and platform. Last month, I found a telling interview with Colly Myers, Symbian’s founding CEO. When asked what he would most want to do over as CEO, Myers replied:
We wouldn't have spent time on user interfaces. We'd have left that much earlier. Everyone was keen to share and we tried hard for two years, but it was never going to happen. Everything about those companies [phone OEMs] is based in their own UIs. So that was two years wasted.
In other words, Nokia and Sony Ericsson don’t want to end up like HTC (or Dell or Compaq) as nothing more than commodity distributors of someone else’s look and feel.

Unix (and now Linux) has had its own GUI wars. Back in the 1980s, MIT’s X allowed for the idea of common APIs but different look-and-feel, but (AFAIK) the APIs were incomplete — applications written for the various X-based GUIs (CDE, Motif, KDE, Gnome), are not binary compatible.

By joining GMAE LiPS has firmly sided with Gnome, and picking a single GUI is a good step towards defining a common platform. But then we’re back to Symbian’s dilemma — how do all the LiPS members distinguish their products with a common GUI?

Oops, this was supposed to be a shorter post. Maybe next time.

Technorati Tags: , , ,


Doug Klein said...

Regarding your comments on X; the problem was not really binary compatibility (at least not in the typical sense of the word) but rather "look and feel" incompatibility. You could always mix and match applications (OpenView and Motif, for example), but it got pretty odd since buttons worked differently, cut & paste didn't cross over correctly, etc.

The thing that killed it all was actually Windows 3.1. Once that came out and PCs got fast enough to run reasonable applications it was game over. The Unix players could never match the single platform standard and low cost advantages. I lived through this battle for 10 years, eventually giving up and actually moving our company at the time from Unix peripherals (X terminals) to Windows peripherals (WBT - Windows Based Terminals).

The mobile phone world is a mess. Oddly enough I find myself wishing a Microsoft would happen again - it would certainly make my current efforts as an ISV for mobile devices far, far easier :)

Joel West said...

Doug, I'm not sure if we agree or disagree. If you can't have one set of binaries that cleanly work on all GUIs, then that's not really a single platform. If, as you say, the OpenView apps look like OpenView apps and the Motif apps look like Motif apps, that’s a lose.

Today some GUIs are set up with different skins but the same APIs. So if your app looked like CDE on a CDE machine and Gnome on a Gnome machine, that would be fine. But apparently no one has done that.

Yes, Windows 3.1 (and NT) started clobbering the Unix market. But not just because of the fragmented platform, but also because of the economies of scale and thus cheaper prices. Jim Isaak has covered this well in his tale of POSIX standardization, based on his role as head of the IEEE standardization committee.