Market failure and mobile operating systems

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.

Beyond smartphones

Smartphones constitute a huge market place. Bear in mind, not just the enormous number of smartphones sold each year, but also the fact that manufacturers earn considerably larger profits, for each smartphone sold, than they do for ordinary phones. Plausibly, although smartphones account for only around 10-15% by units of the 1B+ total annual market of all mobile phones, they provide upwards of 20-25% of the sales revenues for all mobile phones - and perhaps more than 40% of the profits. What's more, users of smartphones typically run up significantly larger monthly usage bills than users of other kinds of mobile phones.

For this reason, the 1996 strategic decision by Psion Software to focus future development of the EPOC32 software system on smartphones turns out to have been marvellously prescient. I'm proud to have been part of that strategic review. The easy decision at the time would have been to continue to focus on the category of devices where EPOC software had historically flourished (in both its 16-bit and 32-bit variants) - in smart handheld organisers, known as "palmtops" or "PDAs". But the decision was taken to target a market that did not exist at the time, and which was expected in due course to dwarf the PDA market. This sowed the seeds for the corporate transformation, 18 months later, of Psion Software into Symbian.

As is often the case with market transformations, the new device category took longer to materialise than had been anticipated. But eventually smartphone sales exceeded all our expectations. It's as computing pioneer Joseph Licklider, stated back in 1965:

"People tend to overestimate what can be done in one year and to underestimate what can be done in five or ten years."

However, the concept of palmtop computing devices has not gone away. It keeps re-emerging, with new names, such as subnotebooks, UMPCs (Ultra Mobile Personal Computers), and MIDs (Mobile Internet Devices), or in new variants such as PNDs (Personal Navigation Devices) or Kindle-like mobile e-book readers. On the LinkedIn forums discussing the forthcoming 2008 Symbian Smartphone Show, Malik Kamal Saadi of Informa raises the following question:

What OSs will be addressing Mobile-Internet-Devices and UMPCs?

Operators and vendors are now looking to extend their opportunities beyond the traditional mobile handsets market by adding new device categories to their portfolios: MIDs and UMPCs. Silicon suppliers such as Qualcomm, Intel, and TI see these devices as the next big convergent device segment. However it is not clear yet which OS type will be more suitable for this type of devices: ARM based (e.g. Symbian, mobile Linux such Android, maemo, etc)? or X86 based (e.g. light version of Microsoft Windows, or Apple MAC)?

Symbian is more suitable for mobile phones but I was wondering if , with Symbian Foundation, this OS could be upgraded to address the MID and UMPC market?

For simplicity, for now, I'll use the term "MID" to cover all of these emerging categories of smart handheld devices which major on functionality other than phone communications (in other words, they aren't smartphones). As I see it, the question of MIDs breaks down into three:

1. After many previous false starts, are there reasons for us to take MIDs seriously as a device category in the foreseeable future?


2. Even if the market for MIDs grows in absolute terms, will it be significant enough to warrant distracting resources onto that market, away from other growth areas that might be even more significant?


3. What operating system is the likely winner in the MID space?

1. The history of false starts with MIDs

The ill-fated Palm Foleo (which was cancelled before it came to market) and Sony mylo are but two of many examples of devices in this same general space:

• Announced with a lot of fanfare
• Pitched as finding an exciting new "sweet spot" in between laptop computers and smartphones
• But failing to live up to the vision - achieving at best lack-lustre market success.

As another example, it's no secret that Nokia's maemo-powered Internet Tablet devices, although providing a great learning experience for working with open source, make only a limited contribution to Nokia's overall revenues.

However, I see the delays with market success of MIDs as being temporary - akin, in fact, to the delays before the eventual market success of smartphones:

• The declining cost of key items of hardware, which has led to smartphones becoming ever more affordable, will likewise move many types of MIDs inside the budget range of larger and larger pools of potential purchasers;


• Some specific technical and ergonomic problems needed to be solved, before the appeal of a device can extend beyond the early technology enthusiasts; these include better screens (for mobile e-book readers), improved GPS fix technology, and better mobile internet browsing;


• Just as smartphones grow in numbers as a result of increased word-of-mouth recommendations by users of these devices, various MIDs will benefit from similar crescendos of user endorsement;


• An industry that is dedicated to the creation and marketing of these devices takes some time to come into being and establish itself (in the analysis of Bhaskar Chakravorti, this takes roughly twice as long to happen, as you might expect from just looking at Moore's Law technology curves) ; but virtuous cycle effects do eventually emerge.

I have one other reason for believing in the commercial future of MIDs - particulary those which are PDAs. I've personally derived great utility from the Psion Series 5mx that I've been using virtually every waking hour for the last nine years. The device supplements my memory, keeps track of my appointments, gathers my thoughts and ideas, marshalls my to-do items, and much, much more. There's no doubt in my mind that there are many other people who would, similarly, benefit from the highly useful PIM (personal information management) capabilities of such devices:

• A proportion of users will be satisfied by the PIM capabilities of a single multi-purpose smartphone device. These users will just carry one smart mobile device.


• But a significant proportion of users will prefer to carry a separate PDA-like device, in addition to a smartphone. They'll value the additional benefits from a device with a larger screen and larger keyboard.

2. Other directions beyond smartphones

MIDs are one potential direction of market expansion beyond existing smartphones. But they're not the only one. Indeed, there are two other directions which have consistently held higher importance in Symbian's thinking:

• The drive towards mass-market smartphones - in which smartphone technology is used inside ordinary-looking phones used by larger and larger numbers of consumers;
• The drive towards super-smartphones - in which additional computing powers, new peripherals and sensors, and other hardware and software enhancements combine to provide new experiences and services for sophisticated and demanding users at the always-fluid yet lucrative top end of the market.

It would have been a major strategic error for Symbian to lose focus on either of these two growth areas. What merit an additional 10-20 million units of sales of PDA-like devices, if this diversion of attention caused us to miss the chance of the next 200-500 million units of smartphones?

On the other hand, these markets (MIDs and smartphones) are not separate. They've had elements in common in the past, and they're becoming increasingly connected. An important meaning of the word "convergence" that is (rightly) oft-applied to the smart mobile device industry, is that the technology and solutions applicable to one type of smart mobile device will increasingly be applicable to all other types of smart mobile device. There's less need for highly optimised distinct solutions: Moore's Law and faster network speeds mean there's less need to worry over every jot and tittle of hardware and network capacity. Even though various devices look quite different from each other and are operated differently by users, the underlying hardware and software can be similar.

In other words, it can be argued that the days when hardware and software had to be uniquely tailored to each different mobile device category are receding. If that's true, then benefits of scale, in developing the same technology solution for different kinds of smart mobile devices (both smartphones and MIDs), may outweigh the advantages of having the best solution for each different device. And if that is true, we can expect the same mobile operating system to take the lead in all these different areas. So Symbian can no longer stand aside from the general MID category.

Happily, the creation of the Symbian Foundation come at exactly the right time, changing industry dynamics to make it much more likely that Symbian platform software will be adopted, not just in standard smartphones, mass-market smartphones, and super-smartphones, but also in various kinds of MID. What Symbian itself could not do, the newly enlarged and newly empowered Symbian ecosystem will take in its stride.

3. Picking the winning operating system for MIDs

In selecting the software system for their devices (MIDs, smartphones, or otherwise), manufacturers generally have four kinds of criteria in mind:

• Technology factors: which software delivers superior performance, battery life, security, low defect count, improved user experience, etc?
• Commercial factors: which software results in low total cost of development, manufacture, deployment, and maintenance; and which provides good opportunities for value-adding differentiation?
• Political factors: which software is least likely to have its evolution controlled by corporations or organisations that fail to share common goals with the manufacturer?
• Reliability factors: which software is likely to be delivered on schedule and to pre-agreed quality levels, in fulfilment of a multi-year evolutionary roadmap of changes?

An operating system will need to score well on all four counts, before it is adopted for any large ("bet the farm") projects in commercially mature companies.

The planned creation of the independent Symbian Foundation, with royalty-free licensing of the Symbian platform software, increases the attractiveness of this software to manufacturers considering MIDs:

• The commercial and contractual barriers of entry will be lowered
• If a manufacturer finds a need to change some part of the software system, to address a specific niche device need, that will be much easier than before, given the open access to the source code
• The improved openness will attract a larger ecosystem than before, which will in turn be able to assist with the development and customisation of MID-specific distributions of Symbian platform software.

These changes allow the various technical merits and reliability merits of Symbian software to shine through more clearly, freed from any cloud of uncertainty over commercial or political questions:

• These technical merits include long battery life, platform security, networking bearer mobility, real-time services, and support for multiple different models of application development;
• The reliability merits include an admirable track record of shipping software on time.

Both these sorts of merits count for a great deal, even in a world where the hardware and network capabilities have increased substantially from just several years ago. That applies for MIDs as well as for smartphones. Indeed, these increases in hardware and network capacity bring more stress and strain onto the software, and make it all the more important that the software is fully fit for purpose. For all these reasons, I believe that Symbian can be the winning operating system for MIDs, as well as for smartphones.

Revealing secrets

I'm increasingly looking forward to the unveiling of lots of secrets about Symbian software. The more I hear about specific ideas third party developers have for add-on and plug-in software for Symbian devices, the more I realise that their needs will be better served once the Symbian secrecy kimono is swept away.

Take one example, from my browsing of the Forum Nokia Developer Community Discussion Board. User "jas76" asks a question:

Hi, I need to mute downlink audio (i.e. from remote end) during call; and play music on music player. Remote voice is currently mixed with music and couldn't find a way around it with any public API/SDK plugin. All discussion thread finaly result in to microphone mute. (mute mic is possible though via SDK plugin)

Is this possible from any private API that we could request? or there is no API that could achieve it? Any experince from Nokia partners in this area?

Less than 90 minutes later, there's an answer on the Forum, from one of the Forum Nokia Experts, "symbianyucca":

I'm rather sure there are not such an API available.

Needless to say, jas76 had been hoping for a different kind of answer. He followed up:

Hi Symbianyucca, Thanks for your inputs. So disappointing that such a simple functionality/requirement and Nokia made it not difficult but impossible. If this is because of security reason they could lock it under some capability. But making it impossible is really really disappointing.

Thanks anyways for your response. Anyone else tried to get API from Nokia for this purpose?

And the thread goes cold.

Is the answer on the Forum correct? Is the particular aspiration of the third party developer one that is reasonable, from a technical point of view? The point is, it's really hard to tell, without gaining access to information that is currently not available to the majority of participants of this kind of forum.

By the way, before going further, I must say that I am impressed by the helpfulness, knowledge, friendliness, diligence, and upbeat humour shown on these forums by the Forum Nokia champions - who are generally providing answers on a voluntary (unpaid) basis. These individuals do a fine job, oiling the wheels of discussion, and making lots of useful suggestions, to nurture and expand a spirit of community self-help. However, there are often limits on the help that can be provided in this way. That's because of current restrictions on distributing the source code of Symbian OS and S60. Without access to this source code, many discussions become stalled.

Take another example. Significant numbers of developers (including researchers at universities) are keen to explore the interesting possibilities of the information known to the phone about its location. The phone itself is usually in contact with several different cell towers. If applications could access this full set of information, it would allow them to determine the position of the phone more accurately than is possible by just using information from a single cell tower. However, I'm told that no APIs are available that provide this richer set of information. On the other hand, internal Nokia applications do seem to be able to benefit from this information. (Note: I understand that this information will be available to third parties in Symbian OS v9.5 - but that's of little comfort to developers who are trying to develop location-aware applications on existing Symbian phones.)

That's two examples. There are many more. I probably not have picked the best examples. I'm not sure about the details of each example, and I may got some of the details wrong. However, the general points seem clear:

• Developers will in principle benefit considerably from being able to delve into currently restricted information on Symbian and S60 APIs, once the code is placed into open source;
• This will avoid the situation where, at present, too many interesting discussion threads become stalled, and enthusiasm withers away before it has the chance to create an important innovation.

On the other hand, there are of course drawbacks to this kind of openness. There are often good reasons why internal APIs have not been publicised.

For example, as soon as they are published in official SDKs, APIs become subject to tight compatibility change control. This change control is vital, for the stability of add-on and plug-in applications that depend on these APIs. But it also restricts the freedom of internal Symbian and S60 developers to evolve and improve these APIs. Especially while APIs are at an early stage in their life, there can be compelling reasons for developers to completely change their design. So there will need to be a careful education campaign, that explains that internal APIs (and many other pieces of information which developers obtain by browsing the source code) can change without warning - and may even change between two apparently similar versions of the same phone (distinguished, perhaps, only by a minor build number)!

• For this reason, I expect that discussion forums will collect and publicise information about the ways these internal APIs change between different phones.

Secondly, some part of the code of a phone will not be made public. Like it or not, the owners of some parts of the code may decide that the code would allow leakage of knowledge of commercially sensitive algorithms, data structures, or whatever. However, the good news is that, in the world of the Symbian Foundation, the extent of this kind of withheld code will be very much less than at present. Whereas the current bias often seems to be, "in case of any doubt, withhold", the new bias will be, "release the code, unless there's a very strong specific reason not to do so".

So we can look forward to moving from a situation where developers are often constrained by lack of information, towards one in which the primary constraint will be their own ability. That's a much better situation.

That leaves the question: how long will we need to wait? Given that it may take up to two years (from the initial SyFo announcement on 24th June) for the completion of the exercise to move Symbian platform code into open source, it may seem this is a far-off future vision. But many things will be happening before the end of that two year period. Parts of the source code will be released, in a staged manner, at various phases during 2009. We'll be moving as fast as we can, subject to due care and attention - and subject to continuing to meet our very important "business as usual" commitments of interim deliveries of technologies and customer support.

Open source coexistence with marvellous non-free add-ons

"Has Symbian thought open source through?" That's the question David Meyer of ZDNet asks this morning. David explains the context of his question:

Last week I visited Symbian's labs here in London. The assembled hacks were shown some very interesting stuff, such as what could be done with a quad core mobile chipset... There was also some cool stuff with mobile-based audio EQ, which always pleases me.

We also got shown some of the fruits of Symbian's work with Scalado on the graphics front. The engineer demonstrated very quick loading of and zooming into a 21-megapixel picture, which was very impressive but raised ... unanswered questions: ... what precisely is to happen with this valuable work once Symbian goes open source?

Given that [going open source] will involve stripping out all the third-party, proprietary stuff that can't go open source, why is Symbian still bothering with such partnerships?

Here's my answer. First, I'm sure that there are aspects of going open source which we in Symbian have yet to think through properly. Moving some 400,000 files of source code into open source is bound to pose a whole host of unexpected problems. However, this particular question is one that has received considerable thought.

The highly impressive Scalado mobile imaging software which Symbian licensed earlier this year is only one of a large number of add-on or plug-in solutions which are available, either as part of Symbian OS itself, or as a pre-integrated supplementary solution. For obvious reasons, I won't say anything more about Scalado, but I'll address the general question of an add-on solution A from vendor V, which may be included in a phone created by customer C of Symbian. Suppose that A is currently subject to a license fee F, which is payable:

• Either from C direct to V,
• Or from Symbian to V, with the costs in this case currently being covered as part of the Symbian OS licence fee paid by C to Symbian.

So what happens to this licence fee F once the Symbian platform becomes open source, and there's no longer any licence fee for Symbian platform?

It turns out there are quite a few options available.

For example, the Symbian platform may exclude A, but may instead include a more basic version A0. This will be good enough for many purposes - and will allow customers to build many kinds of successful phones. But customers who want particularly responsive or feature-rich behaviour in the area covered by A will be able to pay fee F directly to V, and will apply A in place of A0 in their phones. So long as the code for A is independent of the Symbian platform code for A0 (in legal terms, so long as A is not a derivative work of A0), there's no obligation on V to licence their code using the EPL applicable to the Symbian platform itself. That is, they won't need to make their source code available.

Is this somehow at variance with the motivation of Symbian in creating an open source platform? It depends what you think the primary motivation is for this move. If you think that motivation is to drive out all cost from phones, you may be surprised by this option. However, once you realise that the main drivers are actually to lower barriers of entry and experimentation, to boost innovation, to deepen collaboration, to raise quality, and to accelerate time-to-market, you won't be so surprised. Open source does not imply low-value! And nor does open source imply that anything which builds on top of it, needs to be zero cost.

Another option is that vendor V will make A available royalty-free as part of the open source platform, but will earn revenues:

• From consultancy work in the area of A
• Or, from making available a chargeable new version A1 that provides even better performance and/or new features.

In short, there will be plenty of ways for creative partner companies to continue to earn handsome income from their add-on and plug-in solutions to Symbian platform software.

I'll close by returning to the last part of the initial question: "...why is Symbian still bothering with such partnerships?" It's because these partnerships collectively generate a huge quantity of impressive add-on and plug-in solutions, which allow our customers to customise and optimise their phones in numerous ways. And that's good for everyone.

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

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.

Google says OHA operators must agree to user choice on apps

Mike Jennings, Android Developer Advocate for Google, faced a range of questions about security from attendees at the OSiM (Open Source in Mobile) conference here in Berlin this morning.

He confirmed, several times that, for Android phones:

• "Users don't need anyone's permission to install apps"
• "Developers don't need anyone's permission to deploy apps".

This vision is all the more attractive, given the further point that

• "All apps can integrate deeply with the system".

The model, as Mike Jennings explained, is that each app needs to tell users what capabilities they will use - for example, to make a phone call, or to access the address book - and the user will decide whether to permit the application.

Questions from the audience tried to drill into that point: won't network operators seek additional control, to protect their network, to prevent malware, or to avoid revenue bypass?

The answer is, apparently, that all operators who sign up to the OHA (Open Handset Alliance) need to agree to allow the degree of openness described above.

According to this report from TechRadar, similar questions arose in a session in London yesterday morning:

When quizzed about operators by a keen developer who branded them 'bastards' for hating VoIP apps and the like, Jennings replied "there's been a lot of technological advances with Android, but there's a lot of political advances that have taken place for [some] carriers to go with our vision of being more open," adding that carriers were now seeing that more development was needed.

I suspect we haven't heard the last of this. It seems implausible to me that operators will be comfortable in trusting users to this extent - including those who may be inebriated while in the pub, or who fall into an over-trusting "yes, yes, yes" rut while installing apps.

The practicalities of producing open source software

I've been reading books and articles about open source software since at least June 1998 - the first time the famous phrase "The cathedral and the bazaar" (*) made an appearance in Symbian's principal internal discussion database (which was, at the time, still called "Psion Software General"). However, I remain keen to keep on testing out my thinking and understanding of open source issues.

After all, there are many different angles to this subject. There's potential huge upside to taking full advantage of the best principles of open source methods - but there's also many risks from applying some of these ideas in a misguided manner.

For that reason, I continue to pick up books on open source software and think hard about what they say. Recently, I accepted the advice of several of my Symbian colleagues, and started reading "Producing open source software" by Karl Fogel.

I'm very pleased that I listened to that advice. In my view, this book is in a class of its own.

It has the great merit of being an intensely practical book. It's clear from numerous examples in the book that the author has extensive real-world experience at the heart of development teams of open source projects that are both significant and successful - including CVS and Subversion.

Some of the chapters contain ideas that have been covered before - like the history of free and open source, advice on how to choose a licence, and aspects of the technical infrastucture of open source projects. However, other chapters delve into material that (to my knowledge) has been covered much less often:

• Social and political infrastructure of successful open source projects;
• "Money": Working in open source projects in which companies are sponsoring parts of the work;
• "Money can't buy you love" - excellent advice on how to avoid corporate sponsorship dampening the enthusiasm of volunteer contributors;
• Communications - including how to communicate with "difficult people";
• Packaging, releasing, and daily development - including dealing with different kinds of codeline, and the special considerations that apply to integration and to making releases;
• Managing volunteers- including the typical roles that probably need to be filled in projects.

Several times while reading a chapter, I found myself thinking: "Yes, this is highly practical material - and interesting too. But I can see there's still another 20+ pages in this chapter. What else is there to say about this subject?" But then as I turned over more pages, I thought, "Oh yes, this is something that really belongs here too - it's what happens in real projects!"

The writing style was pleasant and clear throughout - with an engaging mix of actual examples (both good and bad) and a discussion of the broader lessons to be drawn from these examples.

My recommendation is that project teams should regard this book as a kind of "bible" - it's something that should be regularly dipped into, and the many salient points shared and debated in group discussion. The lessons will make sense on several levels - some apply during early phases of projects, and others as the project becomes more complex.

(Many of the same principles apply in non-open source projects too, by the way! I felt lots of resonance with my own observations over the years about successful software projects inside the "community source" world of Symbian OS development.)

Perhaps the most sobering part of the book is contained in its introduction:

Most free projects fail...

... it's impossible to put a precise number on the failure rate. But anecdotal evidence from over a decade in open source, some casting around on SourceForge.net, and a little Googling all point to the same conclusion: the rate is extremely high, probably on the order of 90–95%. The number climbs higher if you include surviving but dysfunctional projects: those which are producing running code, but which are not pleasant places to be, or are not making progress as quickly or as dependably as they could.

Happily, the introduction continues:

This book is about avoiding failure. It examines not only how to do things right, but how to do them wrong, so you can recognize and correct problems early...

If that whets your appetite, note that you can read the entire book online, by following the links above. Alternatively, check out the reviews on Amazon.com.

(*) Footnote: The June 1998 "Psion Software General" discussion contained a link that is, sadly, now dead. I'd like to belatedly thank Symbian lead Software Engineer Joe Branton for coming to my room, on several occasions, and encouraging me to pay more attention to the ideas in The Cathedral and the Bazaar.

De-fragmenting the mobile operating system space

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.

Addressing the fragmentation of mobile operating systems

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

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

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

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

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

That ought to reduce the number of software platforms in the market, but more are still arriving, including several based on the open-source operating system Linux.

This same topic of there being too many mobile operating systems came up this week at the Symbian Foundation roundtable discussion held alongside the CTIA show in San Francisco. During the Q&A, several of the press and analysts in attendance pressed panellists on this point:

As the number of mobile operating systems increase, will fragmentation become a major issue for customers and developers?

As reported by Brad Smith in Wireless Week,

Christy Wyatt, vice president of Software Platforms and Ecosystem for Motorola, said there is always the danger there could be a complete fragmentation of operating systems, especially with the growing varieties of “open source” operating systems. But she said the reality is that companies involved in software services will work to focus on a few operating systems.

Marin Perez in InformationWeek takes up the story:

Additionally, Wyatt said she expects to see a "sharp contraction" in the number of mobile platforms in the future, including one consistent version of mobile Linux.

At the same time, the roundtable panellists suggested that resourceful and determined developers would find ways to ensure that their applications can run on the platforms with significant market share and revenue potential:

Because of the diversity in hardware, there will never be one unified language, said Oren Levine, product market manager in Nokia's S60 group. But Levine thinks developers will have significant incentive to make their applications work on multiple platforms due to the size of the overall mobile market.

So how much trouble is being posed to developers, in practice, by this diversity of mobile operating systems? Will a multitude of different operating systems continue in existence (contrary to the request of Arun Sarin), each driven and supported by its own factors? Will the mobile ecosystem as a whole find ways to smooth across the differences and fragmentation caused by this variety?

Just one day after the Symbian Foundation roundtable took place, one of the CTIA keynote speakers initially sounded bleak while addressing this same set of questions:

"Developing applications for the fragmented mobile ecosystem is a Herculean effort that often results in developers creating an application that serves the least common denominator of mobile devices with a poor user experience, and an inability to effectively scale," said Marco Boerries, executive vice president, Yahoo! Connected Life.

But then he unveiled a potential solution:

"Yahoo! Blueprint solves the most challenging problem plaguing today's mobile landscape -- now with one click, you can write once and have mobile services run across a critical mass of devices and operating systems, potentially reaching millions of users. We believe Yahoo! Blueprint is simply the best way to create mobile Internet services -- and we expect will change the world of mobile development moving forward."

Cade Metz of The Register recorded the message from Marco Boerries as follows:

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

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

"You can write a Blueprint service, and with one click, you can generate a standalone application that runs on hundreds of Java devices, on Windows Mobile devices, on Symbian devices and that you can freely distribute. Never has it been so easy to build mobile applications that are this powerful."

Of course, this sounds very similar to the oft-repeated promise of "Write Once, Run Anywhere (WORA)" (sometimes also expressed as "Write Once, Run Everywhere"). Back in January 1996, Sun's press release covering Java 1.0 stated,

"Java's write-once-run-everywhere capability along with its easy accessibility have propelled the software and Internet communities to embrace it as the de facto standard for writing applications for complex networks," said Alan Baratz, JavaSoft's newly appointed president. "We're delighted to invite developers to download Java 1.0 immediately and start building the next killer application."

Twelve years later, after a history of (at best) mixed success with runtimes that aim to provide WORA, the prospect of a real implementation of this promise remains alluring. And it's not just Yahoo! that are proclaiming new implementations of this ideal. Another product announcement at CTIA, this time by the Frisco, Texas-based software company Recursion Software, used similar language:

Recursion Unveils Universal Android, .NET CF and Symbian Platform

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

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

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

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

But whilst these intermediate platforms address issues in the market for add-on applications, they provide less help in the arguably even more important market of "device creation software". That's the market of software components that are built into mobile phones:

• Filling gaps in the operating systems themselves
• Providing special optimisations for particular hardware or particular networks
• Enabling low-level differentiation between different devices.

Software at this level tends to need to be written in the native language (usually C or C++) and to use the native APIs of the underlying software platform. Intermediate platforms can't be used for these purposes, as they don't provide sufficiently intimate connections to the device firmware.

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

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

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

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

• Pete Barr-Watson, Senior Business Development/Deployment Manager, Microsoft Silverlight
• Andreas Constantinou, Research Director, VisionMobile
• Antony Edwards, VP Developer Product Marketing, Symbian
• Matt Millar, Director of Mobile Devices EMEA, Adobe
• Simon Nicholson, Director Operator Engagement, Client Software Group, Sun Microsystems
• Jürgen Scheible, Author of "Mobile Python".

Mobile web browsing wide open

While the blogosphere has, understandably, been paying a lot of interest to one new web browser - Chrome, from Google - I've unexpectedly found myself paying a lot of attention to a different web browser: Opera Mini.

Opera Mobile was, for several years, my mobile web browser of choice. Whichever smartphone was in my pocket - eg Sony Ericsson, Samsung, Nokia... - I would download the latest Opera Mobile, and make heavy use of it.

This changed when Nokia started shipping the Webkit browser on their S60 3rd edition phones. Although I kept, for a while, both Opera Mobile and Webkit installed, I found myself using the Webkit browser more and more. The attraction was that, with its intelligent scrolling and "complete page" view, it served up web pages in very similar fashion to how they appeared on desktop browsers. It has been described as "bringing real PC web-browsing to the smartphone".

However, I confess that I've been having occasional problems with the Webkit browser on my Nokia E61i. Pages often take quite a long time to load - and then re-load, with more text, once the stylesheet has been downloaded - but with an awkward gap in between, when the screen is blank. Worse, the S60 Webkit browser crashes rather too often for my liking - sometimes (causing real frustration) at the end of a lengthy process while I've been navigating to a page I particularly want to view. Whilst it's a great piece of software, it's not perfect.

Last week, I decided it was time to update the device software on my E61i. Using the Nokia Software Updater (as prompted by the Nokia PC Suite), I moved up from ROM version 1.0633 to 2.0633. The process went smoothly. At the same time, I cleaned out lots of add-on software that I no longer used. So my E61i was looking fresh and new. Alas, after the upgrade, the Webkit browser software let me down again - with an Odeon cinema webpage disappearing just as I was about to check possible film times for later that week.

My son - who at the age of 17 going on 27 is already a smartphone veteran - took the opportunity to offer me some of his well-honed teenage wisdom: he told me I should switch to Opera Mini. That's Opera Mini, not Opera Mobile - it's a free app that is funded (like Firefox) from a share of advertising revenues via links with Google.

It wasn't the first time my son had given me that advice. I'd been resisting it, because:

• The "Mini" in the name made it sound to me like the application was underpowered
• I knew it was written in Java, and I thought its performance would, therefore, be less than that of an app written in C++.

However, I noticed a lot of praise in internal Symbian discussion databases for Opera Mini, so I decided to take the plunge. Downloading and installing the app was simplicity itself: I googled "Opera mini", and the very first site offered a download link. The download was surprisingly quick - reflecting the fact that the app itself is quite small. Although there was a slight delay when the app started running, the subsequently performance was pleasantly fast. I can well believe the claim in Wikipedia that, with Opera Mini, data transfer is "about two to three times faster".

The next surprise was how well the browser coped with sites that, previously, required me to wait until "the re-load after the initial load", before displaying text in (for example) right-hand columns on the screen. For example,

• Recently the BBC news page changed over to this kind of layout scheme
• Similarly an upgrade to the Atlassian Confluence engine used for various wikis at Symbian also changed over to this kind of layout scheme.

With a fast connection and a strong CPU on a desktop, web pages like those above load quickly enough. But on my E61i, I had been used to having to wait quite a while, before text in right hand columns on the screen finally became visible. However, because Opera Mini uses a very different mechanism (assembling the page server-side, before compressing it and sending it down to the client), this text is now available to me much more quickly. That's an unexpected bonus.

And I keep finding other UI features and application functionality in Opera Mini that, likewise, pleasantly surprise me - such as an optimised interface to search on Wikipedia or on Amazon.

After a couple of days, I did the previously unthinkable, and re-assigned one of the E61i application hot keys, away from Webkit, to Opera Mini. And I still haven't looked back.

The morale of this story, for me, is that the mobile web browsing competition is still wide open. It's another reminder of one of the central characteristics of an open platform: an application which looks like being the #1 in its field at any given time, might be overtaken in the future - provided the underlying platform serves up a level playing field. And the real winner of this kind of open competition is the end user. In order to remain #1, an application has to keep on providing quality innovations - quickly!

Of course, there's not just Opera and Webkit in the mobile web-browser space. There's also Netfront and Skyfire, among many others, and we can expect mobile versions of Chrome and Mozilla to make entrances too at some stage.

More TechCrunch reality-distortion on iPhone vs Symbian OS

Following fast on the heels of the recent attention-grabbing declaration by TechCrunch's Michael Arrington that "Nokia and Symbian are irrelevant companies at this point", TechCrunch has published another piece of contentious analysis on iPhone vs. Symbian OS market share. On this occasion, the author is Don Reisinger.

The piece starts with the graph which I've reproduced above. The red line at the top shows six figures for Symbian OS quarterly sales - five of which are as already published by Symbian, and the sixth, for July through September this year, is speculation from TechCrunch. The blue-line projections of sales for iPhone in that period are similarly speculative. (Interestingly, the filename for this graph on the TechCrunch site is "iphone-v-symbian-real". Real, that is, apart from the future projection.)

Don reassuringly writes, "I assume Symbian OS will only grow at 5 percent each quarter, since it is a mature technology". Then he goes on to have some fun and games by considering what will happen if iPhone sales grow steadily, for the next few years (in some cases looking all the way out to 2012), at either 300% per annum, 100% per annum, or 50% per annum.

The article ends on a decidedly duff note:

But one thing is certain: the Symbian OS is simply not selling nearly as well as the rest of the industry and the iPhone 3G is outpacing every other smartphone on the market.

No. Symbian OS is currently outselling all other smartphone operating systems added together. This piece of the article makes explicit a confusion that lies under the surface of much of the rest of the article - a confusion between growth and actual value. (Mathematically, the difference between dy/dt and y itself.) It's true that the recent growth in Symbian OS sales has slowed down, and that the iPhone, starting from a much lower base, has achieved higher growth percentages. But that's a very different thing.

In the past, I've done a bit of sales growth projection myself. In November 2004, I wrote the following words as part of Chapter 1 "At the heart of the smartphone revolution" in my book, "Symbian for software leaders: principles of successful smartphone development projects" that went on sale the following year:

It’s no surprise that the commercial market for smartphones has grown by at least 100% in each of the last three years. There are good reasons why this growth should continue throughout at least the next three years – reasons grounded in technological progress, networking dynamics, and market evolution:

• Moore’s Law means that, for the same cost, more and more powerful hardware can be supplied; tomorrow’s smartphones will have as much computing power as yesterday’s PCs
• New generations of phone networks (3G, 3.5G, 4G, and so on) will allow the speedy transmission of ever larger amounts of data, both satisfying and whetting still more user demand
• More powerful devices and more powerful networks jointly enable the provision of attractive add-on services, created by third parties, which in turn increase the market pull for devices capable of supporting such services
• The cumulative operation of software means that new services and applications can piggy-back on the functionality and power of previous services and applications, with striking, innovative results
• Many of these services are community-oriented: the more people who take part in these services, the more valuable these services become (this is sometimes called Metcalfe’s Law)
• As people discover the benefits of mobile online gaming, mobile commerce, and so on, they will spread this message by word-of-mouth, so that the communities of smartphone users swell in size
• Phone network operators have a strong interest in ensuring that phone users
  are attracted to make regular use of services that involve greater amount of
  data transfer (and which therefore attract higher fees).

Sales of Symbian OS phones up to the time I wrote these words had in fact been increasing, annually, at greater than 100%. Sales of 2.0 million units in 2002 had soared to 6.7 million in 2003 and again to 14.4 million in 2004. Similar percentage growth rates continued after that - for a time. Sales were 34 million in 2005, 52 million in 2006, and 77 million in 2007. Past performance (ie growth over 100% per annum) is no sure guide to future results! On the other hand - just to reiterate the point - declining sales growth is not the same thing as declining sales!

A better guide to future sales prospects is probably the number of active phone projects under development. Symbian reports these figures quarterly too. As stated in our press release, there were 92 Symbian phone models (to our knowledge) in development at the end of June. That's a 48% increase from the same figure last year - 62 models. It's also by some way the largest value this figure has been.

Another sign (admittedly, again imperfect) of potential increased volume sales is in the increased revenues earned by Symbian's professional services department. To quote from the press release,

76% growth in consulting services from £5.1 million in H1 2007 to £9.0 million in H1 2008 driven by a demand for Symbian services resulting from a broader and deeper range of customer mobile phone products in the pipeline.

What factors will, instead, govern future sales of iPhones? I've previously discussed some of the potential breakthrough features in this device. But what prevents these features being emulated by products from competitors - including some of the 92+ new products under development using Symbian OS?

Steve Litchfield of AllAboutSymbian has just published a thought-provoking article that touches on this topic, "Joined-up applications and The Way Ahead". Steve is a high-integrity, thoughtful, and immensely knowledgeable writer, with deep all-round hands-on knowledge of numerous smartphones, so I have a lot of respect for his opinions. Steve writes:

Now there are four good reasons why [the iPhone] platform is relatively novel:

1. - the iPhone has a large (320 by 480, 4"), patented capacitive display that's touch-sensitive and yet has super visibility in all light conditions, something that was previously impossible.
2. - the iPhone is almost always on a flat rate, all you can eat data tariff, which means applications can assume full Internet connectivity, bandwidth no object.
3. - the iPhone has a built-in, callable version of Google Maps and a good YouTube client.
4. - the iPhone is fully location aware, using cell towers, Skyhook Wi-Fi location (this works exceptionally well in towns) and (in the 3G model) full GPS.

(I'm tempted to add a fifth reason - that the Mac-loving, iPhone-loving crowd have more imagination and creativity than their equivalents in the Windows and Symbian worlds).

Then Steve reviews some of the particularly attractive ("jaw-droppingly well conceived") downloadable applications which have become available for the iPhone. Finally, Steve comes back to the four points he made earlier:

...here's the kicker - there's no reason why similar levels of imagination and integration shouldn't happen on S60 and Symbian - with Maps/Chat/Ovi, progress is being made. But if I'm honest, Apple's iPhone platform has already seized the technological high ground - in this area, at least.

What about my four reasons (above) why the iPhone has engendered this sort of enthusiastic solution? How can they apply in the Symbian world?

1. - the unusual E90 aside, the largest screen sizes in common use in the S60 world are 2.8", half the size of the iPhone's display (in terms of area) and many phone displays are 2.4" or even 2.2" (which works out as just over a quarter the area of the iPhone's). Bigger displays are needed and of higher resolution. No doubt these will come, and at least outdoor contrast is very good on most S60 devices, but in the meantime it's again advantage iPhone.
2. - flat rate data tariffs are the exception rather than the rule for most S60 phone owners. I'd like to see every contract come with unlimited data and
   every pay-as-you-go SIM allowed unlimited data for a day for a nominal fee (e.g. £1). Until people reach the point where they don't worry about how much Internet is costing them on their mobiles, they'll be suspicious and, again, at a disadvantage to the more expensive, but worry-free, iPhone.
3. - Google Maps is already native S60, which is good, although it's not as slick as the iPhone implementation. But YouTube playback is a toss-up between the low resolution official Java client or the third party and slicker (but often unreliable) S60 app Mobitubia. Yet again, advantage iPhone.
4. - with almost every S60 device now coming with built-in GPS and an OS that allows positioning to be accessed from any application, location useage is simply down to the skill and imagination of developers. We're starting to see S60 apps that use GPS, but it's still early days, it seems.

I don't want to sound too negative - I love my S60 phones and I love the high performance, high speed nature of Symbian OS. But credit where credit's due - hopefully you'll agree that the above two iPhone application examples are nothing short of inspiring - whichever platform you use or develop for.

The killer question is: can the successes of the iPhone indeed inspire similar applications, services, and devices from competing platforms? Can other platforms support devices that have a similary gorgeous screen, a first rate web browser, flat rate data tariffs, and rich callable middleware? If this is possible, the TechCrunch sales projections are dubious.

Personally, I don't think these successes can be fully emulated by in-house proprietary operating systems - but the answer changes when the underlying software system becomes sufficiently sophisticated, flexible, and robust. That is, feature phones cannot compete with these devices - but smartphones can. With these complex products, innovation requires underlying strength. Maturity, as Don Reisinger calls it, doesn't need to mean sales stasis: it can mean the basis for very significant new innovation and new sales spurts - especially when coupled with the kind of restructuring that will follow from Nokia's planned acquisition of Symbian and the formation of the open source Symbian Foundation.

Restrictions on the suitability of open source?

Are there restrictions on the suitability of open source methods? Are there kinds of software for which closed source development methods are inherently preferable and inherently more likely to succeed?

These questions are part of a recent discussion triggered by Nokia's Ari Jaaksi's posting "Different ways and paradigms" that looked for reasons why various open source software development methods might be applicable to some kinds of project, but not to others. As Ari asks,

"Why would somebody choose a specific box [set of methods] for their products?"

One respondent suggested that software with high security and high quality criteria should be developed using closed source methods rather than using open source.

Another stated that,

I firmly believe 'closed' source is best route for targeting consumers and gaining mass appeal/ acceptance.

That brings me back to the question I started with. Are there features of product development - perhaps involving security and robustness, or perhaps involving the kinds of usability that are important to mainstream consumers - to which open source methods aren't suited?

Before answering that, I have a quick aside. I don't believe that open source is ever a kind of magic dust that can transform a failing project into a successful project. Adopting open source, by itself, is never a guarantee of success. As Karl Fogel says in the very first sentence of Chapter 1 in his very fine book "Producing open source software: how to run a successful free software project",

"Most free projects fail."

Instead, you need to have other project fundamentals right, before open source is likely to work for you. (And as an aside to an aside, I believe that several of the current attempts to create mobile phone software systems using open source methods will fail.)

But the situation I'm talking about is when other project fundamentals are right. In that case, my question becomes:

Are there types of software for which an open source approach will be at odds with the other software disciplines and skills (eg security, robustness, usability...) that are required for success in that arena.

In one way, the answer is trivial. The example of Firefox resolves the debate (at least for some parameters). Firefox shows that open source methods can produce software that scores well on security, robustness, and usability.

But might Firefox be a kind of unusual exception - or (as one of the anonymous respondents to Ari Jaaksi's blog put it) "an outlier?" Alternatively - as I myself believe - is Firefox an example of a new trend, rather than an irrelevant outlier to a more persistent trend?

Regarding usability, it's undeniable that open source software methods grew up in environments in which developers didn't put a high priority on ease-of-use by consumers. These developers were generally writing software for techies and other developers. So lots of open source software has indeed scored relatively poorly, historically, on usability.

But history needn't determine the future. I'm impressed by the analysis in the fine paper "Usability and Open Source Software" by David M. Nichols and Michael B. Twidale. Here's the abstract:

Open source communities have successfully developed many pieces of software although most computer users only use proprietary applications. The usability of open source software is often regarded as one reason for this limited distribution. In this paper we review the existing evidence of the usability of open source software and discuss how the characteristics of open-source development influence usability. We describe how existing human-computer interaction techniques can be used to leverage distributed networked communities, of developers and users, to address issues of usability.

Another very interesting paper, in similar vein, is "Why Free Software has poor usability, and how to improve it" by Matthew Paul Thomas. This paper lists no less than 15 features of open source culture which tend to adversely impact the usability of software created by that culture:

1. Weak incentives for usability
2. Few good designers
3. Design suggestions often aren’t invited or welcomed
4. Usability is hard to measure
5. Coding before design
6. Too many cooks
7. Chasing tail-lights
8. Scratching their own itch
9. Leaving little things broken
10. Placating people with options
11. Fifteen pixels of fame
12. Design is high-bandwidth, the Net is low-bandwidth
13. Release early, release often, get stuck
14. Mediocrity through modularity
15. Gated development communities.

As Paul says, "That’s a long list of problems, but I think they’re all solvable". I agree. The solutions Paul gives in his article are good starting points (and are already being adopted in some projects). In any case, many of the same problems impact closed-source development too.

In short, once usability issues are sufficiently understood by a group of developers (whether they are adopting open source or closed source methods), there's no inherent reason why the software they create has to embody poor usability.

So much for usability. How about security? Here the situation may be a little more complex. The online book chapter "Is Open Source Good for Security?" by David Wheeler is one good starting point. Here's the final sentence in that chapter:

...the effect on security of open source software is still a major debate in the security community, though a large number of prominent experts believe that it has great potential to be more secure

The complication is that, if you start out with software that is closed source, and then make it open source, you might get the worst of both worlds. Incidentally, that's one reason why the source code in the Symbian Platform isn't being open-sourced in its entirety, overnight, on the formation (subject to regulatory approval) of the Symbian Foundation. It will take some time (and the exercise of a lot of deep skill), before we can be sure we're going to get the best of both worlds, rather than the worst of both worlds.