dw2

6 March 2010

Fragmentation beyond good

Filed under: architecture, developer experience, fragmentation — David Wood @ 6:53 pm

Hmm, I thought I’d finished writing about mobile fragmentation, but the topic keeps rumbling on.

Some comments from distinguished industry colleagues prompt me to address this topic one more time.

My fellow Symbian co-founder Juha Christensen suggests “Fragmentation is good“:

I believe that already in 2011 we will see smartphones outsell “lesser” phones. By the end of 2012, there will be an installed base of over one billion smartphones. That year along, over 600 million smartphones will be sold worldwide.

One of the things that makes phones so different from PCs has to do with micro-segmentation. Like we’re getting used to hearing “there’s an app for everything,” we are a year or so away from “there’s a phone for every person”. Sony Ericsson’s newly released XPERIA 10 Mini, is a good examples of what’s to come. Intense segmentation of the market, opening up thousands of niches. Just like we all don’t drive the same car, the days are over where everyone in Silicon Valley either has the same BlackBerry, iPhone or Nexus One.

With over a billion people using smartphones, we will see thousands of micro-segments being serviced by thousands of different designs and usage model…

So far, I fully agree with Juha.  However, micro-segmentation doesn’t need to imply platform fragmentation.

With a good architecture, users can get lots of choice, even though there’s an underlying commonality of developer APIs.

As far as users are concerned, the platform supports multiple different interfaces – even though, as far as developers are concerned, there’s a single programming interface.

But Juha continues:

And this is where the goodness of fragmentation comes in. An operating system design comes with inherent restrictions. There is a need to make sure apps run the same way on all devices, that aspect ratios are more or less the same and a ton of other restrictions aimed a making the experience really good.

If one operating system was going to serve all form factors, all market segments, all use cases and all price points, the market would start trending towards a lowest common denominator…

This is where I disagree.  A well-designed mobile operating system can support a vast range of different kinds of devices.  There doesn’t need to be a “lowest common demoninator” effect.

There are, of course, some important benefits of competition between multiple different mobile operating systems.  But it’s a matter of degree.  If there’s too much competition or too much fragmentation, chaos ensues.

That’s why I prefer to say that the amount of fragmentation we have today, in the mobile space, is “beyond good”.

Sebastian Nyström also commented on the previous discussion, via Twitter:

Again we see the theme: fragmentation is part of a chain of cause and effect that has good results for consumers.  And, to an extent, I agree.  But only to a degree.

If the current amount of fragmentation is good, does that mean that twice as much fragmentation will be twice as good for consumers?  Or that ten times as much fragmentation will be ten times as good for consumers…?

If fragmentation is unconditionally good for consumers, should the designers of Qt (to pick, as an example, one important intermediate mobile platform) deliberately fragment it, into several different incompatible versions?

Clearly, it’s a question of degree.  But what degree is optimal?

Bruce Carney – former head of the Symbian Developer Network – raised the following points:

My $0.02 worth: don’t disagree that the industry should invest energy in standardization, but just cannot see the set of circumstances (or benevolent dictatorship) that will drive it as the value chain is too complex and fragmentation is a nice control point for too many actors…

So, I agree with Richard’s article. I have spend 10 years listening to developers bleet on about fragmentation, and if I could give them a simple message it would be “deal with it”, it allows you to find a niche and exploit it. Without fragmentation there would be a small number of winner-take-alls and most of you wouldn’t exist.

Yes, there’s good sense in telling developers to “deal with it”.  But there’s danger in that approach, too.

I’m reminded of an ongoing discussion that recurred time and again about strategy towards developers in Symbian:

  • Should we try to minimise compatibility breaks (such as between Symbian OS v8 and v9), or should we just tell developers to “deal with it”?
  • Should we try to minimise platform fragmentation, or should we just tell developers to “deal with it”?

The argument that developers should just accept things is that, after all, there was a big market awaiting them, with Symbian devices.  The pain of dealing with the inconsistencies (etc) of the Symbian world would be worth it.

However, history threw up new competitors, who had significantly simpler development systems.

And that’s a reminder, at a different level, for everyone preaching complacency about today’s mobile developer systems.  We need to remember that developers have choices.  Instead of working on mobile projects, they may well choose to work on something quite different instead.  The mobile opportunity is huge, but it’s by no means the only opportunity in town.  Those of us who want the mobile industry to thrive should, therefore, be constantly looking for ways to address the pain points and friction that mobile developers are experiencing.

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.

29 January 2010

A strategy for mobile app development

Filed under: Agile, applications, consulting, fragmentation, mashup* event, mobile web — David Wood @ 12:15 am

The mashup* event in London’s Canary Wharf district yesterday evening – hosted by Ogilvy – addressed the question,

  • Apps: What’s your strategy?

The meeting was described as follows:

This event will help people in strategic marcomms roles understand the key challenges with respect to apps and identify the building blocks of an app strategy:

  • What are the platform choices?
  • What are the app store choices?
  • What devices should you support? …

mashup* is bringing together several industry experts and specialist developers to help demystify, clarify and explain the issues around the rapidly emerging Apps channel…

The event was sold out, and the room was packed.  I didn’t hear anyone question the need for companies to have a mobile strategy.  Nowadays, that seems to be taken for granted.  The hard bit is to work out what the strategy should be.

One of the speakers, Charles Weir of Penrillian, gave a stark assessment of the difficulty in writing mobile apps:

  • For wide coverage of different devices, several different programming systems need to be used – apart from those (relatively few) cases where the functionality of the app can be delivered via web technology;
  • Rather than the number of different mobile platforms decreasing, the number is actually increasing: fragmentation is getting worse;
  • Examples of relatively new mobile platforms include Samsung’s bada and Nokia’s Maemo.

One mobile strategy is to focus on just one platform – such as the Apple iPhone.  Another strategy is to prioritise web-based delivery – as followed by another speaker, Mark Curtis, for the highly-successful Flirtomatic app.  But these restrictions may be unacceptable to companies who:

  • Want to reach a larger number of users (who use different devices);
  • Want to include richer functionality in their app than can be delivered via standard mobile browsers.

So what are the alternatives?

If anything, the development situation is even more complex than Charles described it:

  • Mobile web browsing suffers from its own fragmentation – with different versions of web browsers being used on different devices, and with different widget extensions;
  • Individual mobile platforms can have multiple UI families;
  • Different versions of a single mobile platform may be incompatible with each other

The mobile industry is aware of these problems, and is pursing solutions on multiple fronts – including improved developer tools, improved intermediate platforms, and improved management of compatibility.  For example, there is considerable hope that HTML 5.0 will be widely adopted as a standard.  However, at the same time as solutions are found, new incompatibilities arise too – typically for new areas of mobile functionality.

The suggestion I raised from the floor during the meeting is that companies ought in general to avoid squaring up to this fragmentation.  Instead, they should engage partners who specialise in handling this fragmentation on behalf of clients.  Fragmentation is a hard problem, which won’t disappear any time soon.  Worse, as I said, the nature of the fragmentation changes fairly rapidly.  So let this problem be handled by expert mobile professional services companies.

This can be viewed as a kind of “mobile apps as a service”.

These professional services companies could provide, not only the technical solutions for a number of platforms, but also up-to-date impartial advice on which platforms ought to be prioritised.  Happily, the number of these mobile-savvy professional services companies (both large and small) is continuing to grow.

My suggestion received broad general support from the panel of speakers, but with one important twist.  Being a big fan of agile development, I fully accept this twist:

  • The specification of successful applications is rarely fixed in advance;
  • Instead, it ought to evolve in the light of users’ experience with early releases;
  • The specification will therefore improve as the project unfolds.

This strongly argues against any hands-off outsourcing of mobile app development to the professional services company.  Instead, the professional services company should operate in close conjunction with the domain experts in the original company.  That’s a mobile application strategy that makes good sense.

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!

19 November 2008

New mobile OSes mean development nightmares

Filed under: collaboration, fragmentation, Future of Mobile, innovation — David Wood @ 11:30 pm

Over on TechRadar, Dan Grabham has commented on one of the themes from Monday’s Future of Mobile event in the Great Hall in High Street Kensington, London:

The increase in mobile platforms caused by the advent of the Apple iPhone and Google’s Android are posing greater challenges for those who develop for mobile. That was one of the main underlying themes of this week’s Future of Mobile conference in London.

Tom Hume, Managing Director of developer Future Platforms, picked up on this theme, saying that from a development point of view things were more fragmented. “It’s clear that it’s an issue for the industry. I think it’s actually got worse in the last year or so.”

Indeed, many of the panellists representing the major OS vendors said that they expected some kind of consolidation over the coming years as completion in the mobile market becomes ever fiercer.

The theme of collaboration vs. competition was one that I covered in my own opening remarks on this panel. Before the conference, the panel chairman, Simon Rockman of Sony Ericsson, had asked the panellists to prepare a five minute intro. I’ll end this posting with a copy of what I prepared.

Before that, however, I have another comment on the event. One thing that struck me was the candid comments from many of the participants about the dreadful user experience that mobile phones deliver. So the mobile industry has no grounds for feeling pleased with itself! This was particularly emphasised during the rapid-fire “bloggers 6×6 panel”, which you can read more about from Helen Keegan’s posting – provocatively entitled “There is no future of mobile”. By the way, Helen was one of the more restrained of that panel!

So, back to my own remarks – where I intended to emphasise that, indeed, we face hard problems within our industry, and need new solutions:

This conference is called the Future of Mobile – not the Present Day of Mobile – so what I want to talk about is developments in mobile operating systems that will allow the mobile devices and mobile services of, say, 5 years time – 2013 – to live up to their full potential.

I believe that the mobile phones of 2013 will make even the most wonderful phones of today look, in comparison, jaded, weak, slow, and clunky. It’s my expectation that the phones used at that time, not just by technology enthusiasts and early adopters, but also by mainstream consumers, will be very considerably more powerful, more functional, more enchanting, more useful, more valuable, and more captivating than today’s smartphones.

To get there is going to require a huge amount of sophisticated and powerful software to be developed. That’s an enormous task. To get there, I offer you three contrasts.

The first contrast is between cooperation and competition.

The press often tries to portray some kind of monster, dramatic battle of mobile operating systems. In this battle, the people sitting around this table are fierce competitors. It’s the kind of thing that might sell newspapers. But rather than competition, I’m more interested in collaboration. The problems that have to be solved, to create the best possible mobile phone experiences of the next few years, will require cooperation between the people in the companies and organisations represented around this table – as well as with people in those companies and organisations that don’t have seats here at this moment, but which also play in our field. Instead of all of us working at odds with each other, spreading our energies thinly, creating incomplete semi-satisfactory solutions that are at odds with each, it would be far better for us to pool more of our energies and ideas.

I’m not saying that all competition should be stopped – far from it. An element of competition is vital, to prevent a market from becoming stale. But we’ve got too much of it just now. We’ve got too many operating systems that are competing with each other, and we’ve got different companies throughout the value chain competing with each other too strongly.

Where the industry needs to reach is around 3 or 4 major mobile operating systems – whereas today the number is somewhere closer to 20 – or closer to 200, if you count all the variants and value-chain complications. It’s a fragmentation nightmare, and a huge waste of effort.

As the industry consolidates over the next few years, I have no doubt that Symbian OS will be one of the small number of winning platforms. That brings me to my second contrast – the contrast between old and new – between past successes and future successes.

Last year, Symbian was the third most profitable software company in the UK. We earned licensing revenues of over 300 million dollars. We’ve been generating substantial cash for our owners. We’re in that situation because of having already shipped one quarter of a billion mobile phones running our software. There are at present some 159 different phone models, from 7 manufacturers, shipping on over 250 major operator networks worldwide. That’s our past success. It grows out of technology that’s been under development for 14 years, with parts of the design dating back 20 years.

But of course, past success is no guarantee of future success. I sometimes hear it said that Symbian OS is old, and therefore unsuited to the future. My reply is that many parts of Symbian OS are new. We keep on substantially improving it and refactoring it.

For example, we introduced a new kernel with enhanced real-time capabilities in version 8.1b. We introduced a substantial new platform security architecture in v9.0. More recently, there’s a new database architecture, a new Bluetooth implementation, and new architectures for IP networking and multi-surface graphics. We’re also on the point of releasing an important new library of so-called “high level” programming interfaces, to simplify developers’ experience with parts of the Symbian OS structure that sometimes pose difficulty – like text descriptors, active objects, and two-phase object construction and cleanup. So there’s plenty of innovation.

The really big news is that the pace of innovation is about to increase markedly – for three reasons, all tied up with the forthcoming creation of the Symbian Foundation:

  1. The first reason is a deeper and more effective collaboration between the engineering teams in Symbian and S60. This change is happening because of the acquisition of Symbian by Nokia. By working together more closely, innovations will reach the market more quickly.
  2. The second reason is because of a unification of UI systems in the Symbian space. Before, there were three UI systems – MOAP in Japan, UIQ, and S60. Now, given the increased flexibility of the latest S60 versions, the whole Symbian ecosystem will standardise on S60.
  3. The third reason is because of the transition of the Symbian platform – consisting of Symbian OS together with the S60 UI framework and applications – into open source. By adopting the best principles of open source, Symbian expects to attract many more developers than before to participate in reviewing and improving and creating new Symbian platform code. So there will be more innovation than before.

This brings me to the third of the three contrasts: openness vs. maturity.

Uniquely, the Symbian platform has a stable, well-tested, battle-hardened software base and software discipline, that copes well with the hard, hard task of large-scale software integration, handling input from many diverse and powerful customers.

Because of that, we’ll be able to cope with the flood of innovation that open source will send our way. That flood will lead to great progress for us, whereas for some other software systems, it will probably lead to chaos and fragmentation.

In summary, I see the Symbian platform as being not just one of several winners in the mobile operating system space, but actually the leading winner – and being the most widely used software platform on the planet, shipping in literally billions of great mobile devices. We’ll get there, because we’ll be at the heart of a huge community of impassioned and creative developers – the most vibrant developer ecosystem on the planet. Although the first ten years of Symbian’s history has seen many successes, the next ten years will be dramatically better.

Footnote: For other coverage of this event, see eg Tom Hume, Andrew Grill, Vero Pepperrell, Jemima Kiss, Dale Zak, and a very interesting Twitter channel (note to self: it’s time for me to stop resisting Twitter…)

3 November 2008

Mobile 2.0 keynote

Filed under: developer experience, fragmentation, integration, Open Source, vision — David Wood @ 11:32 pm

Earlier today, I had the privilege to deliver the opening keynote at the Mobile 2.0 event in San Francisco. This posting consists of a copy of the remarks I prepared.

The view from 2013

My topic is Open Source, as a key catalyst for Mobile Innovation 2.0.

Let’s start by fast forwarding five years into the future. Imagine that we are gathered for the 2013 “Mobile 2.0” conference – though the name may have changed by that time, perhaps to Mobile 3.0 or even Mobile 4.0 – and perhaps the conference will be taking place virtually, with much less physical transportation involved.

Five year into the future, we may look back at the wonder devices of today, 2008: the apparently all-conquering iPhone, the Android G1, the Nokia E71, the latest and greatest phones from RIM, Windows Mobile, and so on: all marvellous devices, in their own ways. From the vantage point of 2013, I expect that our thoughts about these devices will be: “How quaint! How clunky! How slow! How did we put up with all the annoyances and limitations of these devices?”

This has happened before. When the first Symbian OS smartphones reached the market in 2002 – the Nokia 7650, and the Sony Ericsson P800 – they received rave reviews in many parts of the world. These Symbian smartphones were celebrated at the time as breakthrough devices with hitherto unheard of capabilities, providing great user experiences. It is only in retrospect that expectations changed and we came to see these early devices as quaint, clunky, and slow. It will be the same with today’s wonder phones.

Super smart phones

That’s because the devices of five years time will (all being well) be so much more capable, so much slicker, so much more usable, and so much more enchanting than today’s devices. If today’s devices are smart phones, the devices of 2013 will be super smart phones.

These devices will be performing all kinds of intelligent analysis of data they are receiving through their sensors: their location and movement sensors, their eyes – that is, their cameras – and their ears – that is, their always-on recording devices.

They’ll also have enormous amounts of memory – both on-board and on-network. Based on what they’re sensing, and on what they know, and on their AI (artificial intelligence) algorithms, they’ll be guiding us and informing us about all the things that are important to us. They’ll become like our trusted best friends, in effect whispering insight into our ears.

We can think of these devices as like our neo neo-cortex. Just as primates and especially humans have benefited from the development of the neo-cortex, as the newest part of our brains in evolutionary terms, so will users of super smartphones benefit from the enhanced memory, calculation powers, and social networking capabilities of this connected neo neo-cortex.

In simple terms, these devices can be seen as adding (say) 20 points to our IQs – perhaps more. If today’s smartphones can make their users smarter, the super smartphones of 2013 can make their users super smart.

Solving hard problems

That’s the potential. But the reality is that it’s going to be tremendously hard to achieve that vision. It’s going to require an enormously sophisticated, enormously capable, mobile operating system.

Not everyone shares my view that operating systems are that important. I sometimes hear the view expressed that improvements in hardware, or the creation of new managed code environments, somehow reduce the value of operating systems, making them into a commodity.

I disagree. I strongly disagree. It’s true that improvements in both hardware and managed code environments have incredibly important roles to play. But there remain many things that need to be addressed at the operating system level.

Here are just some of the hard tasks that a mobile operating system has to solve:

  • Seamless switching between different kinds of wireless network – something that Symbian’s FreeWay technology does particularly well;

  • Real-time services, not only handling downloads of extremely large quantities of data, but also manipulating that data in real time – decompressing it, decrypting it, displaying it on screen, storing it in the file system, etc;

  • All this must happen without any jitter or delay – even though there may be dozens of different applications and services all talking at the same time to several different wireless networks;

  • All this rich functionality must be easily available to third party developers;

  • However, that openness of developer access must coexist with security of the data on the device and the integrity of the wireless networks;

  • And, all this processing must take place without draining the batteries on the device;

  • And without bamboozling the user due to the sheer scale and complexity of what’s actually happening;

  • And all this must be supported, not just for one device, but in a way that can be customised and altered, supporting numerous different form factors and usage models, without fragmenting the platform.

Finally, please note that all this is getting harder and more complex: every year, the amount of software in a top-range phone approximately nearly doubles. So in five years, there’s roughly up to 32 times as much software in the device. In ten years, there could be 1000 times as much software.

Engaging a huge pool of productive developers

With so many problems that need to be solved, I will say this. The most important three words to determine the long-term success of any mobile operating system are: Developers, Developers, Developers. To repeat: the most important three words for the success of the Symbian platform are: Developers, Developers, Developers.

We need all sorts and shapes and sizes of developers – because, as I said, there are so many deep and complex problems to be solved, as the amount of software in mobile phone platforms grows and grows.

No matter how large and capable any one organisation is, the number of skilled developers inside that organisation is only a small fraction of the number outside. So it comes down to enabling a huge pool of productive and engaged developers, outside the organisation, to work alongside the original developers of the operating system – with speed, creativity, skill, and heartfelt enthusiasm. That’s how we can collectively build the successful super smart phones of the future.

Just two weeks ago, the annual Symbian Smartphone Show put an unprecedented focus on developers. We ran a Mobile DevFest as an integral part of the main event. We announced new developer tools, such as the Symbian Analysis Workbench. We will shortly be releasing new sets of developer APIs (application programming interfaces) in new utility libraries, to simplify interactions with parts of the Symbian programming system that have been found to cause the most difficulty – such as text descriptors, two phase object construction and cleanup, and active objects.

The critical role of open source

But the biggest step to engage and enthuse larger numbers of developers is to move the entire Symbian platform into open source.

This will lower the barriers of entry – in fact, it will remove the barriers of entry. It will allow much easier study of the source code, and, critically, much easier participation in the research and creation of new Symbian platform software. We are expecting a rapid increase in collaboration and innovation. This will happen because there are more developers involved, and more types of developers involved.

That’s why the title of my talk this morning is “Open Source: Catalyst for Mobile Innovation 2.0”. The “2.0” part means greater collaboration and participation than ever before: people not just using the code or looking at the code, but recommending changes to it and even contributing very sizeable chunks of new and improved code. The Open Source part is one of the key enablers for this transformation.

Necessary, but not sufficient

However, Open Source is only one of the necessary enablers. Open Source is a necessary but not sufficient ingredient. There are two others:

  1. A stable and mature software base, with reliable processes of integration, which I’ll talk more about in a moment;

  2. Mastery of the methods of large-scale Agile development, allowing rapid response to changing market needs.

Fragmentation inside an operating system

Here’s the problem. Fragmentation is easy, but Integration is hard.

Fragmentation means that different teams or different customers pull the software in different directions. You end up, in the heat of development in a fast-moving market, with different branches, that are incompatible with each other, and which can’t be easily joined together. The result is that solutions created by developers for one of these branches, fail to work on the other branches. A great deal of time can be wasted debugging these issues.

Here, I speak from bitter experience. During the rapid growth days of Symbian, we lost control of aspects of compatibility in our own platform – despite our best efforts. For example, we had one version called 7.0s and another called 7.0, but lots of partners reported huge problems moving their solutions between these two versions. Because of resulting project delays, major phones failed to come to the market. It was a very painful period.

Nowadays, in the light of our battle-hardened experience, Symbian OS is a much more mature and stable platform, and it is surrounded and supported by an ecosystem of very capable partners. In my view, we have great disciplines in compatibility management and in codeline management.

The result is that we have much better control over the integration of our platform. That puts us in a better position to handle rapid change and multiple customer input. That means we can take good advantage of the creativity of open source, rather than being pulled apart by the diverse input of open source. Other platforms may find things harder. For them, open source may bring as many problems as it brings solutions.

Fragmentation across operating systems

This addresses the fragmentation inside a single operating system. But the problem remains of fragmentation across different operating systems.

Although competition can be healthy, too many operating systems result in developers spreading their skills too thinly. The mobile industry recognises that it needs to consolidate on a smaller number of mobile operating systems moving forwards. The general view is that there needs to be consolidation on around three or (at the most) four advanced mobile operating systems. Otherwise the whole industry ends up over-stretched.

So, which will be the winning mobile operating systems, over the next five years? In the end, it will come down to which phones are bought in large quantities by end users. In turn, the choices offered to end users are strongly influenced by decisions by phone manufacturers and network operators about which operating systems to prefer. These companies have four kinds of issues in their minds, which they want to see mobile operating systems solve:

  • Technical issues, such as battery life, security, and performance, as well as rich functionality;

  • Commercial issues, such as cost, and the ability to add value by differentiation;

  • Political issues, in which there can be a perception that the future evolution of an operating system might be controlled by a company or organisation with divergent ulterior motivations;

  • Reliability issues, such as a proven track record for incrementally delivering new functionality at high quality levels in accordance with a pre-published roadmap.

A time for operating systems to prove themselves

Again, which will be the winning operating systems, over the next five years? My answer is that is slightly too early to say for sure. The next 12-18 months will be a time of mobile operating systems proving themselves. Perhaps three or four operating systems will come through the challenge, and will attract greater and greater support, as customers stop hedging their bets. Others will be de-selected (or merged).

For at least some of the winning smartphone operating systems, there will be an even bigger prize, in the subsequent 2-3 years. Provided these operating systems are sufficiently scalable, they will become used in greater and greater portions of all phones (not just smartphones and high-end feature phones).

Proving time for the Symbian Foundation platform

Here’s how I expect the Symbian platform to prove itself in the next 12-18 months. Our move to open source was announced in June this year, and we said it could take up to two years to complete it. Since then, planning has been continuing, at great speed. Lee Williams, current head of the S60 organisation in Nokia, and formerly of Palm Inc and Be Inc, has been announced as the Executive Director of the Symbian Foundation.

The Foundation will make its first software release midway through the first half of 2009. Up till that point, access to internal Symbian OS source code is governed by our historical CustKit Licence and DevKit Licence. There’s a steep entry price, around 30,000 dollars per year, and a long contract to sign to gain access, so the community of platform developers has been relatively small. From the first Symbian Foundation release, that will change.

The source code will be released under two different licenses. Part will be open source, under the Eclipse Public Licence. This part has no licence fee, and is accessible to everyone. The other part will be community source, under an interim Symbian Foundation Licence. This is also royalty free, but there is a small contract that companies have to sign, and a small annual fee of 1,500 dollars. I expect a large community to take advantage of this.

This interim community source part will diminish, in stages, until it vanishes around the middle of 2010. By then, everything will be open source. We can’t get there quicker because there are 40 million lines of source code altogether, and we need to carry out various checks and cleanups and contract renegotiations first. But we’ll get there as quickly as we can.

There’s one other important difference worth highlighting. It goes back to the theme of reducing fragmentation. Historically, there have been three different UIs for Symbian OS: S60, UIQ, and MOAP(S) used in Japan. But going forwards, there will only be one UI system: S60, which is nowadays flexible enough to support the different kinds of user models for which the other UI systems were initially created.

To be clear, developers don’t have to wait until 2010 before experimenting with this software system. Software written to the current S60 SDK will run fine on these later releases. We’ll continue to make incremental compatible releases throughout this time period.

What you should also see over this period is that the number of independent contributors will increase. It won’t just be Nokia and Symbian employees who are making contributions. It will be like the example of the Eclipse Foundation, in which the bulk of contributions initially came from just one company, IBM, but nowadays there’s a much wider participation. So also for the Symbian Foundation, contributions will be welcome based on merit. And the governance of the Foundation will also be open and transparent.

The view from 2013

I’ll close by returning to the vision for 2013. Inside Symbian, we’ve long had the vision that Symbian OS will be the most widely used software platform on the planet. By adopting the best principles of open source, we expect we will fulfil this vision. We expect there will in due course be, not just 100s of millions, but billions of great devices, all running our software. And we’ll get there because we’ll be at the heart of what will be the most vibrant software ecosystem on the planet – the mobile innovation ecosystem. Thank you very much.

29 September 2008

Market failure and mobile operating systems

Filed under: Economics, fragmentation, leadership, market failure — David Wood @ 9:57 pm

In seeking to talk about economics, and about market failure, I’m moving way outside my depth. There seem to be so many different viewpoints about economics, each appearing reasonably plausible to me (when I read them in isolation), yet all contradicting each other. It’s a tough subject! What one writer sees as a market failure, another writer sees instead as a failure of individual actors within that market – and so on.

However, one of my correspondents has made a series of thought-provoking comments about market failure in the particular field of mobile operating systems. I believe these comments are sufficiently unusual and also sufficiently intriguing, to deserve consideration by a wider audience – despite my reticence to broach the subject of economics. The comments arose in the responses to an earlier posting of mine, “De-fragmenting the mobile operating system space“. To quote from these responses:

Currently, mobile developers withstand very high development costs due to a very fragmented mobile ecosystem, meanwhile mobile OSes enjoy a much lower developing cost than they would if they had to built compatible OSes between versions: therefore, a de-fragmentation process would move developing costs from mobile developers to mobile OS developers, that is, mobile OS companies/foundations would have to internalize those costs.

But developing an OS with full source or binary compatibility between versions is an order of magnitude more expensive than building one with broken compatibility, and it gets worse with time and versions. Moreover, building a de-fragmented mobile OS requires committing considerable resources (people, money, time) in the present, sunk costs that must have positive expected returns in the future (at least to cover developing costs and money opportunity costs).

Will foundations/consortiums (Symbian, LiMo, OHA/Android), given their non-profit nature, carry these investments in the present to obtain stable software platforms in the future? As Adam Smith wrote, displaying good will and hope is not enough: mobile foundations/consortiums/companies committing resources in the present must charge higher prices in their future and profit handsomely from their risky investments, otherwise the effort will stop…

To paraphrase:

  • Economic incentives on individual mobile operating systems will lead these operating systems to diverge from each other;
  • This divergence will mean that application developers (and providers of middleware, etc) will suffer greater difficulties, because of having to spread their efforts across larger numbers of diverse mobile operating systems;
  • As things stand, no one who is in a position to actually do something to reduce the divergence of mobile operating systems, has a sufficient financial incentive to make that happen;
  • So we can actually expect things to get worse for application developers, rather than better.

(I’m over-simplifying what my correspondent actually says; see the original for the full argument.)

Tentatively, I have the following answers:

  • I believe that things will actually get better for application developers, rather than worse;
  • It’s my experience that major players in the mobile phone industry can, on occasion, take actions based on strategy rather than business case;
  • This requires strong self-discipline on the part of these companies, but it’s not unknown;
  • Action on strategic grounds becomes more likely, the more clearly the argument is made that the actions that make sense in the short-term are actually detrimental to longer term interests;
  • The other key factor in this decision is whether the various actors can have a high degree of confidence in at least the medium-term viability of the software system they’re being asked to collectively support.

So, in line with what I’ve argued here, what we need to do is to keep on pushing (in creative and diverse ways) the merits of the case in favour of de-fragmenting mobile operating systems – and to keep on highlighting the positive features of the mobile operating systems (such as Symbian OS) that are most likely to enable at least medium-term success for the whole industry.

Incidentally, one big contribution that the shareholders and customers of Symbian are taking, towards that end, is to agree to standardise on S60 as the UI framework for the future. They’ve taken that decision, even though both UIQ and MOAP(S) have much to commend them as alternative UI frameworks on top of Symbian OS. They’ve taken that decision for the greater common good. New phones based on the UIQ and MOAP(S) UI frameworks will continue to appear for a while, during a transitional period, but the Symbian Foundation platform software is standardising on the S60 framework. Elements of both UIQ and MOAP(S) will be available inside the Symbian Foundation platform, but the resulting system will be compatible with S60, not UIQ or MOAP(S). That’s a decision that will bring some pain, but the shareholders and customers have been able to support it because:

  • S60 is now (in contrast to the earlier days) sufficiently flexible and mature, to support the kinds of user experience which previously were available only via UIQ or MOAP(S);
  • Indeed, S60 now has flexibility to support new types of UI experiences, whilst maintaining common underlying APIs;
  • Distribution of S60 will pass out of the hands of Nokia, into the hands of the independent Symbian Foundation.

I also believe that the disciplines of binary compatibility that have been built up in Symbian, over several years, are significantly reducing the difficulties faced by developers of add-ons and plug-ins for Symbian software. Because of this discipline, it now costs us less to maintain compatibility across different versions of our software. It’s true that some practical issues remain here, with surprising incompatibilities still occasionally arising in parts of the software stack on Symbian-powered phones other than Symbian OS itself. But progress is being made – and the leading nature of the Symbian platform will become clearer and clearer.

To finish, I’ll give my response to one more comment:

Samsung is gaining market share and producing S60 devices. Let’s suppose that Samsung starts snatching portions of market share from Nokia, do you really think anyone believes that Nokia would refrain from intentionally breaking compatibility to derail Samsung, if that would be necessary?

I can see that there might be some temptation towards such a behaviour, inside Nokia. But I don’t see that the outcome is inevitable. Nokia would have to weigh up various possible scenarios:

  • Symbian Foundation quality assurance tests will notice the compatibility breaks, and will refuse to give Symbian accreditation to this changed software;
  • The other licensees could create their own fork of the software (which would have official endorsement from the Symbian Foundation) and build up a lot of momentum behind it.

Instead, Nokia – like all users of Symbian Foundation software – should be inclined to seek differentiation by providing their own unique services on top of or alongside Symbian platform software rather than by illicitly modifying the platform software itself. That’s a far better way to deploy skilled software engineers.

17 September 2008

Five reasons open source won’t work in mobile(?)

Filed under: fragmentation, leadership, OSiM — David Wood @ 9:44 pm

John Bruggeman, Chief Marketing Officer of Wind River, gave the stand-out presentation on Day One of OSiM (Open Source in Mobile) conference in Berlin today. It was an extraordinary piece of theatre, that captivated the audience – who were already in the midst of a feast of interesting and thought-provoking presentations from other speakers.

Officially entitled “How open source can drive your next device innovation breakthrough“, the majority of the presentation focused on an artful walkthrough of what John called “Five reasons why open source won’t work in mobile“.

These reasons were presented, with great eloquence and wit, as a wake-up call – “to uncover the ugly truth”.

Here’s the context. Speakers earlier in the day had outlined enchanting prospects for Open Source Linux to reach an installed base of 10 billion mobile devices within perhaps just five years (that’s right – it would involve many people having more than one device – such as separate mobile phones and MIDs). But John said that such prospects were illusory, and he gave the following reasons:

1. Linux phones will never be as good as the iPhone

Here, despite what you might first think, “good” means “good for application developers”. Apple iPhone application developers can be confident that, with just one version of their code, they can reach every member of the 15M+ iPhone user community. But in the Linux space, there are already 96 different major and minor variants (based on 10 different mobile Linux platforms). So application developers will have to work much harder, even to begin to reach all Linux phone users.

[Although John was exaggerating some of his rhetoric, for effect, he was quite clear that the figure of 96 was bona fide – and he said that his Wind River colleague Jason Whitmire would show a slide to justify that figure in another presentation later in the day. Unfortunately I missed that later presentation, since I was in another stream at that time.]

2. The mobile industry has been confused and misled by the Symbian Foundation announcement

Previously, open source endeavours in mobile were united (albeit in a highly fragmented sense – see point 1) around the vision of Linux being at the heart of any praiseworthy phones. But with the announcement that the Symbian platform will become open source, everyone has become confused.

[John actually said that “Symbian have polluted the open source message by telling everyone open source is easy” and “Symbian has a gigantic community, but in an evil and dirty way, Symbian is attracting children with candy”. As I said, it was an extraordinary piece of theatre – with lots of exaggeration for effect.]

3. Operators insist on hedging their bets

Because there are so many platform choices, without clear winners, operators are fearful of the risk of standardising on the wrong choices. That’s a big risk for them. So they bet on multiples – perpetuating the fragmented status quo.

4. Phone manufacturers won’t let go of the past

Phone manufacturers have built up huge amounts of legacy code, on numerous operating systems, and they insist on keeping on using these systems. Just like the operators, they fear the risk of giving up what turns out to be a winning system – and in this way, they keep the whole industry confused.

5. Too many people in the mobile value chain just don’t get it

Too many people have been confused by the word “free” and have thought that, because Linux itself has zero licensing cost, everything else of value in the emerging new mobile value chain should also be free of cost. They don’t realise that the real meaning of “free” is “free access”. This distracts people from being able to generate the new kinds of revenues that will strengthen the companies who have key roles to play in the open source mobile value chain.

In summary, “We are all to blame”.

After the wake-up call

Was that the end of the talk? (After all, due to previous sessions over-running, it was now well into the time allocated for the lunch session.)

Well, after some dramatic suspense, John went on to offer another set of five points – things that, whilst hard for us to do (he said), would make open source work in mobile after all:

  1. Hire new product marketers, who deeply understand the different world of open source;

  2. Hire new engineering directors, who (likewise) deeply understand the different world of open source. We need to realise that developing open source software solutions is fundamentally different from the processes in proprietary projects;

  3. Stop looking over your shoulder, and learn to innovate;

  4. Change your low cost platform into a high value play;

  5. Think outside the phone – there are incredible lessons that we can learn from adjacent and complementary markets.

Evaluation

My own view is that the proposed solutions are a lot less convincing than the list of problems. True, open source introduces and demands new thinking models. However, many of the disciplines of large-scale system software development apply in fairly similar ways across both closed-source and open-source projects.

As I see it, the real solution to platform fragmentation is clear platform leadership. Once it becomes clear to operators and handset manufacturers that a given platform is going to allow them strong opportunities for meaningful differentiation, speedy product development, good quality output, and significant revenues, they’ll naturally gravitate towards that platform, and other platforms will fade from the scene.

Remember the old adage: the best marketing tool is a winning product. That beats a bunch of pretty powerpoint slides anyday. If you don’t have a winning product, then you’ll inevitably struggle. Historically, the Symbian platform has been advanced by the visible market successes of a series of breakthrough phone models. (And the very first phone manufacturers who came to us, had all taken a close look at the Psion Series 5 PDA, and liked what they saw.) The longer term success of the Symbian platform will be determined by whether or not there are new breakthrough commercially successful phones in the next 12-24 months. With 92 separate products (*) under development by our customers at the last count, I see plenty of grounds for optimism.

And by the way, if anyone ever does hear me (or anyone else from Symbian) giving the impression that “open source is easy”, please pull me up. Building world-beating smartphones is hard, however you go about the business. Recognising that it is a hard task is, paradoxically, part of the beginning of the real solution. Sad to say, clinging to the hope that there’s an easy route to smartphone success has been the downfall of many a project.

Footnote: (*) Symbian uses the following principle to count the number of products under development (as opposed to those which are merely “prospects” or “roadmap items”):

Models in development are defined by Symbian as phones prior to launch where licensees

  1. have committed a minimum development team; and
  2. have a visible plan to launch; and
  3. have a minimum expected lifetime shipment for the phone.

15 September 2008

De-fragmenting the mobile operating system space

Filed under: fragmentation, openness, operators — David Wood @ 3:37 pm

One response to my previous posting, “Addressing the fragmentation of mobile operating systems“, gave me a lot to think about. The points made by this anonymous commenter deserve a considered response. Here goes:

>Don’t get me wrong, I would like to have just two operating systems in the mobile space. But I’m quite realistic and tired of hypocrites like Arun Sarin, that call for software homogeneity and then sell every OS available: please, put your money where your mouth is.

I recognise the disconnect that often seems to exist, between the strategy arms of various network operators, that say they are going to reduce the number of mobile operating systems they support, and the local operational arms, that appear to disregard that policy. However, I don’t think the disconnect is total. I am aware of several instances where an attractive new smartphone model was rejected by a network operator, on the grounds that the software platform of that smartphone wasn’t on their approved short list.

Admittedly, I suspect that if the smartphone model had been knock-out gorgeous, the strategic directive would have been trumped by local sales considerations. But seeing that the model was only “good” (and not “great”) the centrally approved policy held sway. So these policies do have some force (albeit not so strong a force as you and I might like).

>So, in your point of view, the losses caused by third parties delays and incurred by mobile manufacturers are so large, that they justify that manufacturers relinquish the short-term gains of incompatible operating systems and join their forces to reduce the number of operating systems and/or accept just one OS.

On reflection, it was unfair of me to pick on delays caused by third party software. Delays caused by malfunctions in second party software (written by the phone manufacturer) and in first party software (provided by the operating system vendor) can be equally bad. Unsuspected incompatibilities in the behaviour or functionality of lower-level software can result in lengthy debugging sessions to eventually understand why higher-level software is inexplicably failing to perform as expected on the latest build of the software platform.

My point remains that it can take a long time for a device creation software team to become truly expert in all the vagaries of the underlying software platform. I wish that weren’t the case; I wish that the underlying software platform was more transparent and predictable. Marketing representatives of all the major mobile software platforms might seek to convince people that their own particular platforms are uniquely stable and dependable. And large parts of these software platforms are, no doubt, both stable and dependable. However, because there are many millions of lines of code in the entire platform, and because there are lots of complex fast-changing inter-dependencies between different modules, the unfortunate reality is that the software platforms demand considerable attention from members of the device creation community.

For that reason, manufacturers of advanced mobile phones will put an undue penalty on themselves if they spread the attention of their development teams over several different mobile operating systems. It would be far better for them, over time, to focus on a smaller number of these complex operating systems.

>the natural solution to that problem… [is] to stop outsourcing to third parties those fundamental pieces of code and start producing internally themselves. And maybe, just maybe, that’s what Symbian Foundation is all about: tight control of every software layer

It’s true, the Symbian Foundation has the intent of providing a software platform with a greater degree of completeness that has previously been the case. The idea is that mobile phone manufacturers will receive a more self-contained package of software than in the past. They’ll have less need to source missing portions.

On the other hand, mobile phone manufacturers will still seek to differentiate their phones, by means of:

  • Replacing some of the components provided by the Symbian Foundation
  • Optimising other components, with an eye to the unique hardware and network needs of their own products
  • Adding in new low-level components, that support new services and user experience.

For this reason, I expect that the device creation marketplace will remain large and vibrant.

>Fragmentation manifests itself as a technical problem (incompatibilities between devices) but it’s not created by technical problems in itself, its real nature is political: the inability of all industry players to reach an agreement to des-fragment the mobile ecosystem and, in absence of that agreement, the power/control of one player to impose a standard

I understand the motivations of the different industry players who each participate in multiple different software foundations. We can call this “irresponsible promiscuity” and/or “a failure of industry alignment”, but it can also be seen as a pragmatic hedging of bets. For as long as it remains unclear which of several mobile operating systems will be long-term winners and which will be long-term losers, it’s understandable that industry players will loath to constrain themselves to just one or two mobile operating systems.

However, once it starts to become clear that a particular mobile OS is reaching new levels of utility, productivity, and innovation, industry players are likely to focus their minds sharply – and the political landscape will change. Even so, I don’t expect there will be just one winner. That would introduce its own problems. But I do expect that the number of mobile operating systems will significantly decrease.

>Short-term, no industry player profits from a des-fragmentation process, since it implies to lower the switching costs

Symbian has thought long and hard about the risks and issues in lowering switching costs. If we provide APIs that are more in line with those used by other platforms (for example, the APIs in our PIPS libraries), the risk is that software that runs on Symbian phones will more easily be ported to run on other devices.

At first sight, that looks like a negative outcome for Symbian. However, I think the actual outcome is positive. Partners and customers dislike being locked into a single operating system. If we make it easier for partners and customers to migrate their software assets to other platforms, it means, paradoxically, they will be happier to create software assets on our platform in the first place.

>Even Symbian, when Nokia S60 programs are not allowed to run on a S60 Samsung due to lack of certificates, is creating artificial fragmentation and switching costs: why waste resources with software compatibility when a certificate breaks it all?

I see this example as an implementation error rather than any deliberate policy. The subject of certificates is tricky, but I sincerely hope that we’ll diminish the pains they unintentionally cause. Essential fragmentation is hard enough, without “artificial fragmentation” making things worse.

>Anonymous said…

Final comment: initially I was unsure whether I wanted to reply at length to someone who didn’t give their name. I prefer open discussion to shadow discussion. However, I guess that there’s good reason for the commenter to seek anonymity here.

Older Posts »

Blog at WordPress.com.