Showing posts with label runtimes. Show all posts
Showing posts with label runtimes. Show all posts

Friday, November 28, 2008

Why can't we all just get along?

Blogger Tomaž Štolfa asks me, in a comment to one of my previous posts,
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:

  1. 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;
  2. 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;
  3. 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
  4. 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!

Saturday, September 13, 2008

Addressing the fragmentation of mobile operating systems

Back in February this year, Vodafone CEO Arun Sarin called on the mobile industry to reduce the number of operating systems in use. As reported in Computer World at the time, "Vodafone CEO calls for mobile OS consolidation":

Mobile phone operating systems are key to [user] experience, he said, but there are too many of them; as many as 30 or 40, Sarin estimated.

"We have to reduce that number. There's no way that developers of cool applications can develop for that many operating systems. If we had three, four, five, that would be better," he said...

One reason for the proliferation of mobile phone operating systems is that, historically, handset suppliers offered their own proprietary code to make the best use of their phones' limited processing and memory resources. Developing applications for such closed systems is difficult.

Today's high-end phones, though, have as much computing power as low-end PCs, spawning a new market for operating systems such as Symbian OS or Windows Mobile that run on phones from multiple manufacturers.

That ought to reduce the number of software platforms in the market, but more are still arriving, including several based on the open-source operating system Linux.
This same topic of there being too many mobile operating systems came up this week at the Symbian Foundation roundtable discussion held alongside the CTIA show in San Francisco. During the Q&A, several of the press and analysts in attendance pressed panellists on this point:

As the number of mobile operating systems increase, will fragmentation become a major issue for customers and developers?
As reported by Brad Smith in Wireless Week,

Christy Wyatt, vice president of Software Platforms and Ecosystem for Motorola, said there is always the danger there could be a complete fragmentation of operating systems, especially with the growing varieties of “open source” operating systems. But she said the reality is that companies involved in software services will work to focus on a few operating systems.
Marin Perez in InformationWeek takes up the story:
Additionally, Wyatt said she expects to see a "sharp contraction" in the number of mobile platforms in the future, including one consistent version of mobile Linux.
At the same time, the roundtable panellists suggested that resourceful and determined developers would find ways to ensure that their applications can run on the platforms with significant market share and revenue potential:
Because of the diversity in hardware, there will never be one unified language, said Oren Levine, product market manager in Nokia's S60 group. But Levine thinks developers will have significant incentive to make their applications work on multiple platforms due to the size of the overall mobile market.
So how much trouble is being posed to developers, in practice, by this diversity of mobile operating systems? Will a multitude of different operating systems continue in existence (contrary to the request of Arun Sarin), each driven and supported by its own factors? Will the mobile ecosystem as a whole find ways to smooth across the differences and fragmentation caused by this variety?

Just one day after the Symbian Foundation roundtable took place, one of the CTIA keynote speakers initially sounded bleak while addressing this same set of questions:
"Developing applications for the fragmented mobile ecosystem is a Herculean effort that often results in developers creating an application that serves the least common denominator of mobile devices with a poor user experience, and an inability to effectively scale," said Marco Boerries, executive vice president, Yahoo! Connected Life.
But then he unveiled a potential solution:
"Yahoo! Blueprint solves the most challenging problem plaguing today's mobile landscape -- now with one click, you can write once and have mobile services run across a critical mass of devices and operating systems, potentially reaching millions of users. We believe Yahoo! Blueprint is simply the best way to create mobile Internet services -- and we expect will change the world of mobile development moving forward."
Cade Metz of The Register recorded the message from Marco Boerries as follows:

Previously, the Blueprint platform was merely a means of developing widgets that run atop Yahoo! Go, an application suite available for various and sundry mobile phones.

"Blueprint is our way to help us and the rest of the industry to develop mobile services," Yahoo! mobile president Marco Boerries said this morning, during his keynote at the CTIA Wireless IT and Entertainment trade show in downtown San Francisco.

"You can write a Blueprint service, and with one click, you can generate a standalone application that runs on hundreds of Java devices, on Windows Mobile devices, on Symbian devices and that you can freely distribute. Never has it been so easy to build mobile applications that are this powerful."
Of course, this sounds very similar to the oft-repeated promise of "Write Once, Run Anywhere (WORA)" (sometimes also expressed as "Write Once, Run Everywhere"). Back in January 1996, Sun's press release covering Java 1.0 stated,
"Java's write-once-run-everywhere capability along with its easy accessibility have propelled the software and Internet communities to embrace it as the de facto standard for writing applications for complex networks," said Alan Baratz, JavaSoft's newly appointed president. "We're delighted to invite developers to download Java 1.0 immediately and start building the next killer application."
Twelve years later, after a history of (at best) mixed success with runtimes that aim to provide WORA, the prospect of a real implementation of this promise remains alluring. And it's not just Yahoo! that are proclaiming new implementations of this ideal. Another product announcement at CTIA, this time by the Frisco, Texas-based software company Recursion Software, used similar language:

Recursion Unveils Universal Android, .NET CF and Symbian Platform

Voyager pervasive platform achieves "Write Once, Run Everywhere" for application messaging and communications

Recursion Software, Inc., an innovative provider of next-generation platforms and intelligent middleware, today at CTIA Wireless and IT 2008 announced a new release of Voyager, a pervasive software platform that blurs the lines between Android, Symbian, Microsoft .NET and Compact Framework (CF), and JEE.

Voyager turns traditional software development on its head by allowing developers to natively write and maintain one code-set in either Java or .NET and publish the code to the device(s) of their choice regardless of the virtual machine they employ, instantly expanding an application’s device and market reach. Combined with Voyager’s existing support for more than 15 embedded operating systems, this release signifies Voyager’s evolution into a pervasive platform for all "Screens of Life" (TV, PC, phone, car, ultra mobile PC).

There are many other products that sound, on first hearing, to be making claims similar to those advanced on behalf of Yahoo! Blueprint or Recursion Voyager. I've not seen any detailed analysis as to the comparative strengths of these different products. (I'll be grateful to any reader of this blog who provides pointers to such analysis.) However, I have no doubt that these products can significantly reduce the effort that developers need to invest, to create certain kinds of mobile software. At least some of the pain and frustration of multiple mobile operating systems can be reduced.

But whilst these intermediate platforms address issues in the market for add-on applications, they provide less help in the arguably even more important market of "device creation software". That's the market of software components that are built into mobile phones:
  • Filling gaps in the operating systems themselves
  • Providing special optimisations for particular hardware or particular networks
  • Enabling low-level differentiation between different devices.
Software at this level tends to need to be written in the native language (usually C or C++) and to use the native APIs of the underlying software platform. Intermediate platforms can't be used for these purposes, as they don't provide sufficiently intimate connections to the device firmware.

My own experience - confirmed by many discussions over the years with people deeply involved in specific phone creation projects - is that device creation projects often suffer back-breaking delays because third party software has difficulty in slotting into the overall device software. These delays can occur, even though the third party providers in question seem to have a good track record with previous versions of their software. The problem is that incompatibilities between different versions of the operating system software result in unexpectedly different behaviour from the third party plug-ins. The changes at the platform level invalidate some of the design, the optimisation parameters, or the testing of the plug-ins.

If this kind of delay results from fairly modest incompatibilities between two different versions of the mobile operating system, how much greater is the delay caused by the incompatibilities between two totally different operating systems?

For me, this is the real reason why the mobile industry needs to evolve towards fewer mobile operating system. The companies that keep working with too many different systems are likely to find their development resources stretched too thinly - and (despite possible short-term gains) they'll lose their effectiveness as a result.

Footnote: The topic of multiple intermediate programming environments will be covered in the keynote panel session "Who will win the runtime race?" on day two (22nd Oct) of the 2008 Symbian Smartphone Show. The panellists will include: