I am also wondering why you are not trying to explore a non-os specific scenario?
Developers and service designers do not want to be bound to a single platform when developing a service for the masses. So it would make much more sense to se a bright future with cross-platform standards set by an independent party (W3C?).
If the industry will not agree on standards quickly enough Adobe (or some other company) will provide their own.
It’s a good question. I’m actually a huge fan of multi-platform standards. Here’s just a few of many examples:
- Symbian included an implementation of Java way back in v4 of Symbian OS (except that the OS was called “EPOC Release 4” at the time);
- Symbian was a founder member of the Open Mobile Alliance – and I personally served twice on the OMA Board of Directors;
- I have high hopes for initiatives such as OMTP’s BONDI that is seeking to extend the usefulness of web methods on mobile devices.
Another example of a programming method that can be applied on several different mobile operating systems is Microsoft’s .NET compact framework. Take a look at this recent Microsoft TechEd video in which Andy Wigley of Appa Mundi interviews Mike Welham, CTO of Red Five Labs, about the Red Five Labs Net60 solution that allows compact framework applications to run, not only on Windows Mobile, but also on S60 devices.
There’s no doubt in my mind that, over time, some of these intermediate platforms will become more and more powerful – and more and more useful. The industry will see increasing benefits from agreeing and championing fit-for-purpose standards for application environments.
But there’s a catch. The catch applies, not to the domain of add-on after market solutions, but to the domain of device creation.
Lots of the software involved in device creation cannot be written in these intermediate platforms. Instead, native programming is required – and involves exposure to the underlying operating system. That’s when the inconsistencies at the level of native operating systems become more significant:
- Differences between clearly different operating systems (eg Linux vs. Windows Mobile vs. Symbian OS);
- Differences between different headline versions of the same operating system (eg Symbian OS v8 vs. Symbian OS v9);
- Differences between different flavours of the same operating system, evolved by different customers (eg Symbian OS v7.0 vs. Symbian OS v7.0s);
- Differences between different customisations of the same operating system, etc, etc.
(Note: I’ve used Symbian OS for most of these examples, but it’s no secret that the Mobile Linux world has considerably more internal fragmentation than Symbian. The integration delays in that world are at least as bad.)
From my own experience, I’ve seen many device creation projects very significantly delayed as a result of software developers encountering nasty subtle differences between the native operating systems on different devices. Product quality suffered as a result of these project schedule slips. The first loser was the customer, on encountering defects or a poor user experience. The second loser was the phone manufacturer.
This is a vexed problem that cannot be solved simply by developing better multi-os standard programming environments. Instead, I see the following as needed:
- Improved software development tools, that alert systems integrators more quickly to the likely causes of unexpected instability or poor performance on phones (including those problems which have their roots in unexpected differences in system behaviour); along this line, Symbian has recently seen improvements in our own projects from uses of the visual tools included in the Symbian Analysis Workbench;
- A restructuring of the code that runs on the device in order to allow more of that code to be written in standard managed code environments – Symbian’s new Freeview architecture for networking IP is one step in this direction;
- Where possible, APIs used by aspects of the different native operating systems should become more and more similar – for example, I like to imagine that, one day, the same device driver will be able to run on more than one native operating system
- And, to be frank, we need fewer native operating systems; this is a problem that will be solved over the next couple of years as the industry gains more confidence in the overall goodness of a small number of the many existing mobile operating systems.
The question of technical fragmentation is, of course, only one cause of needless extra effort having to be exerted within the mobile industry. Another big cause is that different players in the value chain are constantly facing temptation to try to grab elements of value from adjacent players. Hence, for example, the constant tension between network operators and phone manufacturers.
Some elements of this tension are healthy. But, just as for the question of technical fragmentation, my judgement is that the balance is considerably too far over to the “compete” side of the spectrum rather than the “cooperate” side.
That’s the topic I was discussing a few months back with Adam Shaw, one of the conference producers from Informa, who was seeking ideas for panels for the “MAPOS ’08” event that will be taking place 9-10 December in London. Out of this conversation, Adam came up with the provocative panel title, “Can’t We All Just Get Along? Cooperation between operators and suppliers”. Here’s hoping for a constructive dialog!