Archive for December, 2008


Thursday, December 11th, 2008

The smartphone software market has been busy lately. Android comes along; Nokia open-sources Symbian OS; the iPhone becomes wildly popular.

Ten years ago, Symbian was formed. It was the “open” alternative. Now, people look at Symbian and – until the Foundation announcement – ask what on earth is open about Symbian? Surely it’s more closed than Android etc.? I get asked these questions all the time.

Ten years ago, things were easy. The alternatives were closed platforms built by the phone manufacturers themselves: NOS, OSE etc. They had no APIs for developers (well, Java on phones was just beginning to take off) and they were entirely closed. Symbian was open in two key ways: firstly, it had APIs which third parties could use to add to the device software; and secondly, all the source code was available to the licensees, and the development costs could therefore be shared. That was radical ten years ago in the mobile marketplace!

Today, the industry has moved on. “Open” today doesn’t mean just sharing source code between a few large companies – it means publishing it on the web and letting anyone change it. But we’re going to see the same battle fought on exactly the same things: the openness of the APIs, and the degree to which the code is open source. Again, the Symbian Foundation is pushing the envelope. On both counts, it is in principle more ‘open’ than any of the alternatives.

Allow me to explain by way of a diagram.

Ade’s openness graph

Some caveats for nit-pickers.

  1. Symbian (pre-foundation) had different API classifications – available to all, partners only, or nobody. Even if you were using just the ‘available to all’ category, it still had more APIs than Android (where you can’t run native code on real devices) or the iPhone (where you can’t even run a background task). When the foundation becomes active, presumably all the ‘partners only’ APIs will become available to everyone, which will wipe the floor with the competitors.
  2. No, you really can’t run native code on Android devices. Yet..
  3. No, you really can’t run background processes on an iPhone..
  4. I have no idea about LiMo and friends. I’m assuming they fit the mould of Motorola’s Linux Java platform, where the kernel is GPLed but the only APIs available are Java. This may be a gross disservice to LiMo, as I think it is intended to have native APIs. But to be honest, I don’t count it as one of the major players at the moment.

What does this tell us?

For one thing, Android is substantially less open than Symbian OS on both counts. This may change, of course. But right now, there’s nothing to stop handset makers taking the Android code, and altering it willy-nilly to create purely proprietary software. Furthermore, you, as a third party developer, can’t run native code. So you can’t port your existing software. You can’t talk to hardware, beyond the ways that Google gives you. You certainly can’t run emulators or different execution environments such as Python.

Even before the Foundation move, it could be argued that the Symbian APIs were more open than the Android ones. Symbian and Nokia have jumped through a lot of hoops to produce a reasonable POSIX compatibility layer which enables lots of existing software to work on Symbian devices, relatively unchanged.

So: Symbian currently looks like the most open platform. Sadly, Symbian has some major practical issues to sort out which prevent the platform from appearing open. In addition, the APIs are certainly hard to develop against (but since Symbian is the only platform that allows different runtime environments such as Python, it could be argued that doesn’t matter in the long term).

Finally, credit where it’s due: Android and Google really forced Nokia to make this change. Full credit to Nokia, though, for such a bold step.

(All trademarks and logos are owned by their respective owners).