dw2

4 March 2010

Coping with mobile fragmentation

Filed under: applications, developer experience, fragmentation, runtimes, smartphones, standards — David Wood @ 10:21 pm

My recent article “Choosing intermediate mobile platforms” appeared on the same day as the TechCrunch article by Rich Wong, “In Mobile, Fragmentation is Forever. Deal With It“.  Despite the different titles, the articles covered many of the same topics.

Rich and I were fellow jury members at the Emerging Startups Mobile Premier Awards in Barcelona last month.  The discussions of the jury room ought to be kept confidential, but I’m not revealing too many secrets if I say that the topic of de-fragmentation magic bullets came up during our deliberations.  So it’s no coincidence that we both have something to say on the topic!

Even though I’ve written about mobile fragmentation many times in the past, Rich’s article has spurred me to put pen to paper one more time.  Mainly I agree with what he says, though there are a few additional points that deserve to be stressed.

Points of agreement

  • Mobile data is on fire. Despite a few false starts, we are now in the midst of a transformative “Open Mobile 3rd Wave” … We are just in the early swell of the wave … thanks to continued improvements we’re now seeing in smart phones, mobile OS platforms and 3G/4G networks, the raw ingredients are just getting better every month.
  • There is an alphabet soup of protocols, standards, and regional differences by country which can be daunting for any entrepreneur. Just look at the range of technologies on handset platforms alone…
  • Anyone who is waiting for a single silver bullet to solve fragmentation issues in mobile will be waiting a very long time, especially if they want to go after the global mobile opportunity…
  • Sadly, whether or not there is an elegant technical answer, it will be hard to drive any single set of worldwide standards given the different economic incentives of the many players, however good it would be for developers…
  • Get a guide.  It is difficult to explain the subtleties of the mobile ecosystem without a longer dialogue, but the good news is that there are quite a few battle-scarred mobile veterans around that can help you with the Cliff Notes on the industry. Find one to help you.
  • Don’t wait.  There’s an incredible startup and wealth-creating opportunity in this new arena of Open Mobile. The smartest entrepreneurs will not wait for these fragmentation issues to be solved but are figuring out now how to pick a use case, a core platform, and geography to bound their problem and get going. Once you have initial momentum, you can pick through these fragmentation landmines, and make a 2nd and 3rd step. Don’t wait for the unifying technology to solve these issues before diving in. It’s going to be an exciting time to build great mobile companies this next 5-7 years.

Next, let’s extend the discussion:

Some developers can find a magic bullet

It’s true: there won’t, in the foreseeable future, be a single platform that all developers can use to solve all their mobile needs.

However, platforms and tools are appearing which can address all the mobile needs of some developers.  I tried to give some examples of these potential solutions in my previous article.

I’m far from being an expert in any of these systems, so I risk being completely wrong in my assessment.  However, it does appear that at least some of these emerging solutions can remove a significant part of the technical pain from a developer who wants to deploy a particular kind of solution across a wide range of mobile devices.

Depending on the kind of application the developer has in mind, a different intermediate platform may be needed.  So, no single magic bullet.  But there are plenty of smart solutions that deserve a hearing.

Before trying to roll their own mobile solutions, developers should, therefore, take a look at what’s already available.

New intermediate platforms for old phones

Rich makes a good point when he notes,

One of the worst myths floating around the blogosphere is the wait by some for a “unifying technology” that will make things “simpler and easier” to develop services and apps for the global mobile market.  At times, some have claimed that Java (J2ME) was the answer, then Flash Lite, then Webkit browsers, and most recently HTML5. While each solution has its merits, there will not be any unification anytime soon. Even as HTML5 richness has improved substantially, browser support will still vary and many, many phones will not support HTML5 for 7+ years.

In other words, even if new devices contain a powerful new intermediate platform (such as HTML5), this will leave the vast majority of existing phones in the cold.

However, this dynamic can change, to the extent that new platforms can be installed on existing phones.

For example, Qt Labs have recently described a “smart installer” that is now available for beta testing:

Qt 4.6.2 is released, and in addition to all the bug fixes in it, we’ve also snuck in a feature or two, especially for the Symbian platform. One of interest is the ability for Qt to make use of the beta version of the Nokia Smart Installer, which makes it easier to deploy your Qt application to Symbian phones…

When the user now installs yourapp_installer.sis on their phone, the Smart Installer will go on-line and get all the dependencies that your Qt application requires, typically Qt and QtWebkit + Open C. If these packages are already installed on the phone, the Smart Installer does nothing. So, it is a little bit like an “apt-get for Symbian” has been wrapped around your application.

In other words, the Qt environment will be automatically installed onto the phone, if it’s not already present.

The drawbacks with this, of course, include the facts that upgraded new intermediate platforms can:

  • Have heavy hardware requirements – for example, they may use up a considerable portion of the available memory on older phones;
  • Be difficult to install on simpler phones (the above “smart installer” depends on the Symbian software installation system being present on the phone).

However, we can see these points as challenges rather than dead ends.  And it’s handy that there are a considerable number of intermediate platforms under development, adopting different approaches.  It’s reasonable to expect that at least some of these platforms will find ways to reach out successfully to older devices.

An imperative to solve the fragmentation problem

It’s true that developers need to make progress in the existing, heavily fragmented mobile world, without waiting for the fragmentation to be solved.

However, this doesn’t mean the mobile industry should stop worrying about the drawbacks of excess fragmentation.  The effort that people have to put in to bridge different fragments of the mobile world is effort that would be better placed providing direct benefits to users.

  • For example, suppose that a developer puts 40 units of effort into the platform-independent logic of an application, and then another 30 units of effort for each adaptation of the application to a different mobile operating system platform.  To cover six different mobile platforms would require a total of 220 units of effort.
  • Imagine, instead, that the developer could use an intermediate platform that would cover all these operating systems.  Suppose in this case that the adaptation to the single intermediate platform consumes 30 units of effort (on top of the 40 units for the platform-independent logic), and then the developer prefers to add a little polish for each of the different operating systems.  If the intermediate platform is doing its job well, this final polish ought be require something like just 5 units of effort each time.  That makes a total of 100 units of effort.
  • The net saving of 120 units of effort can then be applied to developing v2 of the application, or to some other quite different project, rather than wrestling with different mobile operating systems.

So whilst we advise developers that their approach to fragmentation should be to “Cope with it”, we should be vigorously campaiging at the same time for rapid progress towards meaningful standardisation of fit-for-purpose intermediate platforms.

The problems that need to be solved

I’ll end with some remarks about the main issues that this standardisation process (whether formal or informal) needs to solve:

  1. Performance – especially battery usage.  This includes coping with applications that want to run in background (potentially draining batteries).
  2. Functionality – so that the intermediate platform provides access to the really interesting parts of the functionality of the mobile device and the mobile networks.
  3. Security – to avoid applications wreaking havoc with user data (especially when these applications have accesss to advanced functionality of the device and network).
  4. Device reconfiguration – to cope with the fact that the “one box” design of most smartphones today is going to be replaced by “multi-component” designs over the next 3-7 years, with new roles for detachable screens (and more).
  5. Business models – to ensure that there are enough ways for applications to be economically viable (rather than just technically viable).
  6. Speed of standardisation – so that the big picture of “a rising tide lifts all boats” prevails, rather than the process becoming bogged down in smaller scale turf wars and filibustering.

On the last point, history might just show that the single most significant announcement at Mobile World Congress was about the formation of WAC – the Wholesale Application Community:

A number of the world’s leading telecommunications operators and device manufacturers are launching an open global alliance, that will establish a simple route to market for developers and provide access to the latest and widest range of innovative applications and services to as many customers as possible worldwide.

Together, we have signed a memorandum of understanding with the aim of building an environment or ’wholesale applications community’ where innovative applications can be developed irrespective of device or technology.

The new alliance, which represents more than three billion customers worldwide is inviting players from across the ICT industry, not only operators and developers, but also handset manufacturers and internet players to join forces to create an initiative based on openness and transparency. We believe this model presents the most compelling format on the market where developers will thrive and customers will reap the benefits of greater choice.

The mobile industry doesn’t have a great track record for working together quickly in this way.  However, more people than ever before in the industry are aware of the likely price of failure.

Choosing intermediate mobile platforms

Filed under: applications, developer experience, fragmentation, runtimes, smartphones — David Wood @ 12:55 am

Over the last few months, one thing I’ve noticed is the increasing number of companies who are offering mobile intermediate platforms and tools, that are designed to hide differences between underlying mobile operating systems.  For example, I heard about several new ones (that is, new for me) during Mobile World Congress at Barcelona.

I’d like to mention some of these companies.  But first, here’s some context.

People who want to develop applications (or provide content or services) for mobile devices face two levels of decision about platform choice.

The first decision is: what should developers do about the fact that different mobile devices run many different mobile operating systems (such as Symbian, BlackBerry, iPhone, Android, Palm webOS, LiMo, Maemo, Series 40, Bada, Windows Mobile…)?

In other words, should developers:

  1. Prioritise one operating system platform above all others, and attempt to become an expert in that?
  2. Try to become experts in all the major operating system platforms (including different UI families and other platform sub-variants)?
  3. Rely on third party experts who can deliver “mobile applications as a service” across a wide range of relevant operating systems?
  4. Try to find an intermediate platform and/or tool, that will hide the differences in underlying mobile operating system?

The first of these approaches has the merit of simplicity, but cuts off large numbers of devices.  The second of these approaches is particularly hard to achieve: it requires wide-ranging knowledge.  The third is what I advocated in an earlier blog post, “A strategy for mobile app development“: it involves building a relationship with an external company which maintains up-to-date knowledge about changing mobile operating systems.  The fourth is a variation on the third.  Rather than rely on paying a third party to use their own systems to develop apps for each different platform, it relies on finding an intermediate platform and/or tool, to achieve the same end.

That takes me to the second decision about platform choice: what should developers do about the fact that there are so many different intermediate platforms available?

In one way, this second decision is harder than the first one.  That’s because the number of intermediate platforms available seems to be larger even than the number of different mobile operating systems.  Therefore the choice is larger.  (And it seems to be getting larger all the time, with the emergence of new intermediate plaforms.)

But, thankfully, in another way, this decision is easier.  That’s because there may well be more than one “right answer”.  Depending on the type of applications being developed, various different intermediate platforms are well-suited to distributing the application acrosss a wide range of mobile devices.

I’m not expecting a consolidation, any time soon, down to just a few intermediate mobile platforms.  Developers’ needs are too varied for that.  But I am expecting at least some of these platforms to become better and better, as their owners respond smartly to the evolving needs of the growing number of developers who want to bring applications to ever larger numbers of mobile devices.

Here are just four of these platforms which have caught my eye recently.  As I said, different platforms are appropriate for different kinds of developer needs.

1. JumpStart Wireless BusinessSuite

JumpStart Wireless has a solution for enterprises that want to improve how they interact with their mobile workforce.

A special feature of this solution is that no “programming” in a traditional sense is required: no C/C++, no Java, no HTML.  Instead, I heard the solution described as “you fill in a spreadsheet” giving details of an existing paper-based system that you’d like to replace by a version that runs on mobile devices – a paper-based system for work orders, time cards, daily reports, punch lists, inspections, sales orders, and so on.  The architect and founder of JumpStart Wireless, Dr. Jeffrey Bonar, observed many similarities between systems used by different companies, and captured the similarities in the engine that lies at the heart of the JumpStart Wireless BusinessSuite platform.  The platform generates versions of the application that can run on a wide variety of different mobile devices.

Their website states:

Problem: Mobile Employees Typically Waste Hours Per Day With Paperwork and Communicating to Headquarters

Time and money wasted:

  • Driving to pickup/drop-off paperwork, filling out paperwork and excessive phone calls.
  • Chasing down missing paperwork, correcting errors and dealing with illegible paperwork.
  • Dealing with backlogs of completed work waiting to be closed out and billed.
  • Manually entering field data

Solution: JumpStart Wireless™ – One Tenth the Cost of Conventional Wireless Approaches

  • Leveraging JumpStart Wireless’s patent pending artificial intelligence technology, your customized wireless applications are one tenth the price of conventional approaches to wireless software.
  • Your forms and mobile employee process is automatically transformed into a wireless device application

Works with Normal Cell Phones and PDAs

  • JumpStart Wireless applications work on normal, off-the-shelf cell phones and BlackBerrys.
  • You do not need an expensive ($700-$2000), complex, custom device

2. The MoSync Mobile Development SDK

The MoSync Mobile Development SDK takes a different approach. It provides access to a wide range of underlying device functionality, via a C/C++ SDK.  As such, it requires a greater degree of software skill from the developer, and in principle can enable a rich variety of different kinds of application.

MoSync were one of the finalists in the Mobile Premier Awards at Barcelona, where I had the chance to meet a couple of their founding team.

Their website states:

Mobile cross-platform done right

Today’s mobile device market is more fragmented than ever.  New platforms are introduced every year.  Dozens of new devices arrive from manufacturers every month.  Sometimes it can seem that writing your application is the easy part: the real headache is tailoring it for all those different platforms and devices, and trying to keep up with the ever-changing marketplace.

We think that mobile application development is hard enough without having to worry about porting issues. That’s why we’ve created MoSync — a truly open-source solution for today’s fragmented mobile market.

MoSync’s fully-featured software development kit helps you develop anything from simple programs for basic mobile phones to advanced applications that exploit the full potential of the latest intelligent smart phones and mobile devices.

And with MoSync you can adapt, build, and package your application for hundreds of different mobile devices in a few clicks – all from the same code base! That means huge savings in development costs, faster time-to-market, and wider distribution and revenue possibilities…

Most approaches to cross-platform software development involve

  • either manual brute-force porting (in essence rewriting the application for lots of mobile devices)
  • or the use of virtual machine runtimes that need to be installed on the target devices.

MoSync does neither — instead it gives you the best possible solution: Symbian, Windows Mobile, j2me, Moblin, and Android built from a single source…

3. The Airplay platform from Ideaworks Labs

The Airplay platform from Ideaworks Labs has particular strengths for high-performance rich-media mobile applications – including graphically-intense mobile games.

Their website states:

Airplay is a native mobile application development and deployment solution that overcomes many of the major problems faced by developers and publishers of mobile games today.

The Airplay SDK comprises a set of powerful and extensible tools and technologies within a framework of processes and workflow best practices. This combination of technology and know-how delivers massive cost savings during both development and deployment and enables a much faster time to market.

This solution is the unique result of a 7-year symbiotic relationship between Ideaworks Labs and Ideaworks Game Studio divisions, and it is through building many of the most innovative mobile games in the world that our solution has been fine-tuned and thoroughly battle-tested.

Key Features:

  • Single Binary: Airplay combines the platform-specific execution environment implementation with a single binary for each game or application. The key advantage of this is there is no need to embed software on the handset, no dependence on manufacturing supply chain, or individual manufacturer or operator deals.
  • Open Platforms: All applications built using Airplay run on all “open” platforms, such as Symbian, BREW, Windows Mobile, Linux, and can be embedded on “closed” platforms, such as RTOS.
  • Scalable Graphics: Fully scalable graphics pipeline optimized to support all leading semiconductor architectures…
  • OpenKODE compliant: Ideaworks Labs was co-spec lead in Khronos on OpenKODE Core API, committed to standards-based portability of native applications.

4. EZMobile from 509inc

509inc have a solution which may appeal to developers who already have a web service, which they want to connect to mobile devices in such a way that it takes advantage of mobile device features such as location.

Their website states:

5o9 EZMobile uses Web standards to simplify development and the support of mobile users. 5o9 EZMobile works with existing Web servers, most HTTP mobile browsers and any network. 5o9 EZMobile can reduce the time and cost to mobilize by 2 to 10 times that of cross-platform mobile application development and support…

5o9 EZMobile software enables enterprise-level Mobile SaaS by delivering contextual data to your Web Apps. It provides a cost-effective alternative to cross-platform mobile application development.

Now you can extend your existing Web services to mobile users by leveraging the power of the Web. Your Web apps can access real-time who, what and where data about your mobile users, letting you personalize services via customized menu-based navigation. Standardize delivery, via the browser, across multiple mobile platforms. You determine the data you need. You control your data security and privacy  policies. You choose the appropriate level of personalization for your mobile employees, customers and partners.

Experienced cross-platform mobile developer Simon Judge recently looked more closely at 509inc and wrote some of his findings in a blog post “509 Bridges the App Web Gap“:

Last year I mentioned how 5o9 had developed a solution that allowed BlackBerry and Windows Mobile device location to be made available to web sites. Since then, things have progressed and they now offer a range of multi-platform tools for mobile developers.

5o9 told me that their view of the future is that for mobile to really take off the web has to know the end-user better. This means that web browsers need better access to phone features.

If you go to the 5o9 web site you can learn more. However, what it doesn’t say is how this technology works and how it might be integrated into your mobile solution, so I dug deeper

The 5o9 solution is a simple mobile application that can share critical meta data (without the need to type it in) with any web app in the world. It works by extending the HTTP protocol with new customizable HTTP_X headers….

Some people think that the future of mobile is the web. Until such time, technologies such as those offered by 5o9 can be used to bridge the gap.

This is just to scratch the surface…

Above, I’ve provided brief details of four attractive intermediate mobile platforms, but there are probably at least five times as many more that could be added to this list (I apologise for the highly selective nature of my list).

And that’s without covering the better known intermediate platforms such as Qt, Java, HTML5, Adobe Flash/AIR, and Microsoft Silverlight.  It would take a long time to fairly compare and evaluate all serious players in this space.

One conclusion that can be drawn from this multiplicity of offerings is that there’s wide perception of the need for such solutions, driven by the combination of two observations:

  • The mobile opportunity is huge, and demands attention
  • Mobile development is still generally seen as unnecessarily difficult.

28 November 2008

Why can’t we all just get along?

Filed under: collaboration, compact framework, fragmentation, runtimes — David Wood @ 8:58 pm

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!

13 September 2008

Addressing the fragmentation of mobile operating systems

Filed under: fragmentation, runtimes — David Wood @ 12:46 am

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:

Blog at WordPress.com.