We ‘ve just released the updated version of our 100 million club: the watchlist of software companies whose products have been embedded on more than 100 million mobile handsets.

In this H1 2008 update we ‘ve identified 25 software products from 23 companies which have shipped on more than 100 million handsets cumulatively as of June 2008. The watch list  provides the basis for three key observations (especially in comparison to our 2007 update):

- Firstly the 100 million club is a testament to the commercial and technological complexities inherent in the mobile industry; there are over 6 billion handsets having been shipped up to June 2008 and around 1.2 billion handsets estimated to be shipped in 2008. Yet our research shows that only 4 software products have reached the 1 billion deployment mark, 9 products have exceeded the 500 million mark and 25 products in total have shipped in more than 100 million handsets. Considering that there are 250-300 companies that license embedded software products - not to mention the circa 30,000 mobile software developers - this is clearly a tough market in which to achieve scale. Indeed, the revenues and developer mindshare are migrating from the pre-load to the post-sales phase of the handset lifecycle, as we ‘ve covered in an earlier article (mobile software is dead.. long live mobile software).

(click for the download page)

- Secondly, the results of the research point to the de facto standards that are emerging with regards to software components. Adobe’s Flash Lite has been embedded on 723 million handsets as of June 2008. Adjusting for seasonal variations, Flash Lite is being deployed on over 500 million handsets per year in 2008 - phenomenal numbers and close to challenging the penetration of Java ME implementations which are generally estimated to around 80% of the global sales base. On the other hand, browser shipments are slowing down (see earlier article on Bye Bye Browser). The Openwave (now Purple Labs) browser was shipped on 180 million devices in H1 2008 and Opera Mobile shipped on just under 20M handsets in that same period. The de facto standards here are under the radar for the time being; WebKit (which should make it into the 100 million club in H2 2008 thanks to Nokia’s S60 and S40 pre-installs) and Opera Mini which saw over 95 million downloads in total as of August 2008. Nuance is also a company to watch, given that it tops our 100 million club with a clear margin to the second runner, and is expanding across multiple forms of text input technologies.

- Thirdly, the watch list points to some surprising observations on mass-market software. The industry talks too much about smartphone software - Symbian, S60, Windows Mobile and Android - yet these are overshadowed by the volume deployments of feature phone operating systems. Mentor Graphics’ Nucleus and ENEA’s OSE have been deployed on well over 1 billion handsets, in many cases as the single OS powering both the applications and the modem stack. Nokia’s S40 has been embedded on an estimated 730 million handsets, while Qualcomm’s BREW has been shipped on an estimated 469 million handsets in total. Both S40 and BREW expose a large part of the device capabilities to software developers and force into question the term ‘open OS’ which is typically associated with Symbian and Windows Mobile.

All in all, the 100 million club lists 25 products which have shipped on more that 100 million handsets as of June 2008, grouped into five product categories:
- Application environments: Adobe Flash Lite, Aplix Jblend and Esmertec Jbed.
- Browsers: ACCESS Netfront, Opera Mobile, Picsel File Viewer and the Purple Labs (ex Openwave) browser.
- Middleware: Beatnik MobileBAE, BitFlash Mobile SVG, Ikivo SVG Player, Nuance VSuite, NXP Software’s LifeVibes MxMedia, PacketVideo CORE, Red Bend vCurrent, Scalado CAPS and TAT Kastor.
- Operating systems: ENEA OSE, Mentor Graphics Nucleus, Nokia S60, Nokia S40, Open Kernel Labs OKL4, Qualcomm BREW and Symbian OS.
- Input engines: Nuance T9 and Zi eZiText.

For a detailed discussion of the common traits of the companies listed in the 100 million club see our 2007 update of the watch list. Note that the 100 million club is based on an original article by Morten Grauballe.

We have excluded ARM, InnoPath and Sun from the watch list as they were unable to disclose exact shipment numbers for their products, and Teleca’s Obigo browser which has been discontinued since May 2007.

Warm congratulations to the vendors who have succeeded in crossing the 100 million handset mark!

- Andreas

The success of Apple’s App Store has been well documented; more than 5,000 new applications, $30M revenues in the first 30 days of operation, 200 million downloads in the first 100 days.. the facts point to a rediscovered revenue source that the mobile industry is eager to capture. [Update: John Doerr at O'Reilly has shared some research that shows App Store applications growing by 170% each month between August and October 2008 and then plateau'ing to about 6000 apps in early November].

Many industry observers will point to the on-device storefront as the reason behind the success of Apple’s App Store. Others will point to Apple’s single OSX platform that allows developers to target more than 10 million devices globally with a single application build. But our research shows that it’s far more than that.

Mobile Application Stores (MAS) are a new solution market which promises the development of a new revenue stream for operators, handset OEMs and application developers. In the last few months here at VisionMobile we ‘ve analysed the key MAS solutions, namely Qualcomm’s BREW shop, Apple’s App Store and held briefings with Nokia, Handango and GetJar. In this article, we discuss the recipe of the mobile application store phenomenon and the movers and shakers of this virgin market.

The next figure compares five popular MAS solutions in terms of fundamentals, performance and features.

Mobile Applications Stores have been around long before the iPhone – in fact since 2001 with Qualcomm BREW offering not only an SDK for application developers, but also a complete developer-to-consumer channel for discovering, provisioning, distributing and billing applications on BREW handsets. On one hand Qualcomm’s BREW solution has been criticised for stringent application certification requirements and a cumbersome developer accreditation program. Yet it is by far the most successful MAS solution, with an average of 80 million application downloads per month in 2007 and over $1 billion shared with developers as of early 2007.

Beyond the 10-11% of the sales base of BREW-capable handsets, there have been very few, usually unsuccessful efforts at building an ecosystem for application downloads.

Nokia Download!
Nokia’s Download! on-device storefront represents a half-baked MAS solution. Launched in June 2006, Nokia’s Content Discoverer was designed to replace Preminet, the supply-side marketplace for distributing applications. Nokia’s NCD, later renamed to Download!, has been widely deployed on S60 and S40 handsets but failed to get the MAS recipe right due to a number of reasons:
- an on-device storefront with very few applications, poor catalog management, inconsistent structure and operator-dependent availability.
- installing an application presents the user with multiple confirmation dialogs, making installation counter-intuitive.
- the process of submitting an application to be featured on Download! is far from transparent with no central portal and distribution agreements done on a case-by-case basis.
- billing relies primarily on premium SMS via specific operator deals and takes a large revenue cut away from the developer. To improve the rev share balance, developers have to implement their own credit card charging mechanisms in which case they have to lure the user to their website to make the payment – plus developers have to use their own IMEI-based licensing schemes.

GetJar
Despite lacking an on-device storefront, GetJar is a successful Mobile Application Store reporting a respectable 17 million downloads per month. GetJar was started by Ilja Laurs in 2004, is profitable, and has recently received $6 million from Accel Partners.

GetJar started as a community site, connecting developers with beta testers, where users can download and test applications. It has since evolved into a distribution channel for application developers including brand-name applications like Opera Mini and Google Maps. GetJar reports 26,000 registered developers and 10,000 hosted applications.

GetJar features mostly free and ad-supported applications. Developers can upload applications to GetJar for free, and get downloads for free. Developers monetise through four revenue models:

1. Free applications with no advertising
2. Ad-supported applications, where the developer monetises through GetJar’s in-house ad-injection (CPM) system, or other ad systems (e.g. Greystripe, Smaato) for interstitial ads.
3. Trial applications, where the activation or upgrade takes place via the developer’s own website.
4. By the end of 2008 GetJar plans to add a centralised billing facility via credit card to support paid-for applications, according to Bill Scott, GetJar’s SVP.

GetJar allows developers to promote their apps on GetJar website for a fee of circa $4,000 per month per application. According to Scott, Google Maps downloads jumped from 20,000 downloads/week to 90,000 downloads/week thanks to GetJar promotional banners.

GetJar is also offering hosted application store solutions for operators. The company allows operators to build own-brand or co-branded mobile application stores in what seems like a no-brainer deal: GetJar offers the hosted solution to the operator for free and is also willing to share part of the ad revenue. GetJar operates custom portals for 11 operators and OEMs, including Three, MAXIS Malaysia and Optimus Portugal.

One downside of GetJar is that it does not offer an on-device storefront, where we may see the company partner with on-device portal providers.

Handango
Handango is one of the first application retailers and bills itself as the largest cross-platform smartphone application distributor with over 140,000 applications (including variants) in its online stores and over 100 million applications downloaded to date.

Handango offers application developers three channels of distribution:
- Direct, via handango.com
- Via channel partners such as Verizon Wireless, AT&T, T-Mobile, Alltel, Nokia, RIM, Sony Ericsson, Samsung and AOL. Handango has recently expanded with distribution through physical retail stores, namely BestBuy and Carphone Warehouse.
- Via Handango’s commerce engine web-shopping infrastructure used by over 1,000 content providers.

Handango offers InHand, an on-device storefront which features ratings, recommended and best seller apps. InHand can be freely downloaded from the Handango site and in some cases comes pre-loaded on handsets - in the order of ‘low millions’ of handsets according to Handango’s Alex Bloom, VP Content and International.

Another provider who has entered the MAS scene is US-based mPortal, best known for having powered Disney Mobile’s on-device portal. The company has now turned to offering a client and server infrastructure for application stores. mPortal offers a white label client-server product that combines an on-device storefront, application provisioning, aggregation of 3rd party application catalogs and integration with operator billing – in other words key elements for helping operators take a Mobile Application Store to market. mPortal already powers the branded application store of a tier-1 operator and reports being deployed on 50 device models (SKUs) as of the end of 2008.

Naturally, there are a number of other vendors offering partial MAS solutions, namely Motricity, Jamba, Buongiorno and Handmark.

The recipe behind Mobile Application Stores
At the end of 2008 we are clearly seeing a turn towards complete Mobile Application store offerings in the footsteps of Apple’s App Store. There’s been plenty of blogoshere coverage on Google’s Android Market, RIM’s Application Center and Microsoft’s SkyMarket.

This new wave of MAS solutions encompass the complete recipe for a developer-to-consumer channel, contrary to the previous half-baked efforts. The next figure lists the five key ingredients of Mobile Application Store solutions; single marketplace, centralised billing, global distribution, provisioning and on-device discovery. The ingredients of the recipe are far from simple to put together – requiring not only the right ingredients, but also the right cook - which is why Apple and Qualcomm are the only two successful, complete Mobile Application Stores as of the end of 2008.

New market = new opportunities
We are already seeing a number of software vendors, OEMs and operators planning to offer Mobile Application Stores, many of them still in stealth mode as of the end of 2008.

We expect the most successful MAS solutions to come from handset OEMs, particularly the top-10. OEMs can manage the distribution, provisioning and on-device discovery elements of the recipe, while partnering with billing and retailing vendors to complete the picture. Operators will find it harder to put together successful MAS propositions, as they control a much smaller percentage of the recipe.

The few players who have developed vertical ecosystems are also in a very strong position – specifically Google, Microsoft, Adobe, Qualcomm, Nokia, Intel and RIM (see earlier article on the 7 centres of gravity in mobile). It will also be interesting to see if Qualcomm is willing to export its very successful MAS solution outside the narrow realm of BREW-capable handsets.

We expect handset OEMs and network operators have gone for shopping early this Christmas, as they try to piece together the key ingredients of a MAS solution. Supply of these ingredients is in abundance: billing (Tanla, Bango, Qpass), distribution and retailing (July Systems, Motricity, Jamba, Handmark), on-device storefronts (mPortal, SurfKitchen and the dozen or so ODP vendors) and provisioning (InnoPath, Red Bend as well as many software services outfits).

Comments welcome as always.

- Andreas

We ‘ve been shortlisted in the top-10 blogs for the Mobile Communications category by Electronics Weekly Magazine. We ‘ve been listed next to Engadget Mobile and Mob Happy - and we ‘re honoured.

If you are one of the 1500+ regular readers of our blog, click here to send an email to Electronics Weekly and vote for us. The closing date for voting is end-of-play Friday 21 November.

Thanks for your support!

- Andreas

OK, I ‘m exaggerating. Mobile software isn’t dead, and it will never be. You need software to turn an expensive brick into a walking talking phone. Mobile software is critical to the function of both the handset itself and the mobile industry as a whole. But the revenue potential of mobile software is changing in a very symmetrical way: it’s migrating from embedded pre-load software, to downloadable, post-sales software.

The business of software
The business of embedded mobile software is a very tough one and it’s getting tougher. There are 100s of vendors that have emerged in the last 10 years offering embedded software like multimedia & graphics engines, operating systems, browsers, middleware and core applications, application environments, on-device portals and active idle screen solutions (see our Mobile Industry Atlas for who’s who). These vendors have based their business on a built-it-and-it-will-scale model. The assumption here is that by shipping your software on millions of handsets the business model of per-unit royalties will easily scale, as in the simple equation.

Revenues $$$ = high-per-unit-royalties * many millions of devices

However, revenue scalability is far harder to come by for two reasons.

1. Embedded software has been commoditising - meaning that handset OEMs are willing to pay less, even though they recognise software as indispensable; much like the FM radio feature in your car. This is the case for operating systems - see Android which is available to license for a price tag of $0 and the effect it had on Nokia’s acquisition of Symbian. Same applies to application environments (Flash Lite will now come with a zero royalty under the OSP project). Web browser royalties have dropped from an estimated $0.75-$1 per unit in 2005 to $0.05 to $0.25 per unit in 2008 in large volumes. WebKit and the tough browser economics have signaled dire consequences for Teleca’s Obigo and Openwave’s browser.

On-device portal vendors are suffering from a similar fate; ODP pure-play software should be selling for $0.10 or less per unit today. A handful of pure-play ODP vendors have survived to late 2008: Cibenix, Communology, Crisp Wireless, INSPRIT IntroMobile, Streamezzo, SurfKitchen and weComm. Most ODP software is offered as a loss-leader, acquired or developed into OEM channels (Nokia Download!), media brand channels (Yahoo! Go), tools companies (Adobe FlashCast), social networking services (Xumii, Reporo), content publishing channels (Cellmania, Handmark, ROK, OnMobile),  Service Delivery Platforms (NewBay, Qualcomm uiOne) and software services providers (MobUI). Numerous ODP products have been very quiet, namely Airmedia, Comverse ODP, EveryPoint, Infusio, Tricastmedia and U-Turn.

Only vendors with unique intellectual property (IP) have been able to resist commoditisation - ranging from input technology to graphics acceleration and multimedia software companies. As a result embedded software vendors are now settling for uncapped pre-licensed royalty bundles and NREs (non-recurring engineeering aka professional services fees) in place of running royalties. The smarter vendors are repackaging their assets into a service delivery model where they can charge for the more popular per-active-user model.

2. Deployment challenges: As ironic as it may sound, in a market of 1 billion devices sold per year, it is very difficult for any single software vendor to become embedded on more than 1 million mobile devices. Our 100 million club charts just over 20 companies (out of an estimated 250-300 companies in the inner circle of the mobile industry) which have had any single product embedded on more than 100 million cellular handsets.

Deployment challenges arise as handset OEMs are reluctant to ship 3rd party software on a platform-wide basis, but are rather trying to accomodate specific channel requirements for a relatively small volume of handsets. Moreover, tier-1 operators who in theory can mandate (read: request) that certain software is embedded on the handset have been challenged with time-to-market delays for customised handsets and so are  acutely aware of the opportunity cost of deep handset customisation.

Overall, both per-unit-royalties and deployment volumes have been reducing, signalling the down-spiralling revenues of the embedded software business. So what options do embedded software vendors have? Some are favouring professional services fees for software integration, customisation, certification and indemnification (WindRiver is a good example here). Others are repackaging their assets in the form of vertical service delivery platforms, where the embedded software is the loss-leader (see list of ODP vendors earlier).

Pre pre-load to post-sales monetisation
What is most interesting is that as the embedded software market is spiraling downwards, a new mobile software market is being re-ignited, that of downloadable software. In essence, the revenue opportunity is moving from the pre-load phase of the handset lifecycle to the post-sales phase (see our report on Mobile Software Management for definitions and a perspective on the handset lifecycle).

Open OS platforms and application stores have existed at least since Qualcomm’s BREW platform and Shop launched in 2001. Handango reports 140,000 applications on its stores and BREW has generated more than $1B for developers as of March 2007, averaging 80 million downloads per month in 2007. Yet applications sales haven’t really picked due to the *commercial* challenges in connecting developers directly to end users. Outside the BREW ecosystem (accounting for 11-12% of the global device sales), very few application developers have been making money, at least until the advent of Apple’s App Store.

The App Store has near-perfected the five key elements of a direct developer-to-consumer channel: a single marketplace for application submission and testing; centralised billing; global distribution; application provisioning; and on-device storefront. Apple’s App Store has broken down most commercial barriers (save for the stringent application selection criteria) - the success speaks for itself:  100 million application downloads in the first 2 months of launch and $30 million in revenues in the first month.

Google, RIM and Microsoft are launching their own Appstores, while a number additional of Appstore initiatives are under development in stealth mode. We ‘ll compare and contrast Apple’s App Store with Nokia’s Download, Qualcomm’s BREW, GetJar and Handango in a next article.

Update: To clarify, the core argument of this post is that the revenue opportunity (future market size) of the embedded software market is shrinking while the revenue opportunity of the post-sales market is growing - in this sense market value is migrating from pre-load to post-sales. We estimate there are 250-300 software companies active in the pre-load phase of the lifecycle, and about 30,000 developers in the post-sales phase. Naturally, the average 3rd party developer revenue is going to be tiny in the post-sales phase. We should also see increasing importance in the promotional and marketing channels for 3rd party developers and consolidation of such providers.

Comments welcome as always.

- Andreas

Flash Lite and Java have been quietly penetrating the mobile handset market. Both application runtimes have in a sense shown that openness is not an exclusive privilege of open operating systems, but of the majority of mobile handsets.

A new set of application runtimes have also surfaced in the form of WebKit, Silverlight, Qt and Lua - shifting the battleground for software platforms from the OS level in 2002 up to the application runtime level in 2008.

We have explored the wide range of application runtimes before - but we have recently analysed how the key contenders compare and contrast. The next table lists the commercial, product, licensing and technology terms for seven leading runtimes. I will be discussing this analysis with a panel of industry execs at the Symbian Show on October 22nd in London.

Java ME is the most pervasive application runtime, installed on approximately 8 out of 10 handsets shipping in 2008/9 by most analyst estimates. Java’s proliferation looks set to continue as Motorola plans to release the MIDP3 source code under an APL2 license by April 2009, which should reduce both fragmentation and the costs of implementing Java ME for handset OEMs.

Adobe’s Flash Lite reached the 500 million installed base mark in May 2008 and looks set to penetrate even further thanks to the zero royalty fees that Adobe has pledged. The exposure of the underlying Flash Lite device integration layer should enable OEMs to develop more tightly integrated and more consistent FL implementations. Nokia has already integrated Flash Lite 3 on the latest S40 6th Edition platform; note that the S40 operating system is on more than half of Nokia’s 40% share of annual handset shipments. The Finnish OEM also plans to integrate Flash Lite more tightly on S60 through Platform Services. Sony Ericsson has also been pushing Flash Lite integration into Java apps through project Capuchin (see earlier analysis).

WebKit has been a surprise in the making during the last 5 years. Although initially developed as the engine to Apple’s Safari desktop browser, the software has been evolved and optimised significantly; Nokia’s mass-market S40 6th edition OS features WebKit, as do Nokia’s S60, Motorola’s WebUI, Adobe’s AIR and Google’s Android.

Silverlight is a newcomer from Microsoft, aiming to compete head-to-head with Flash Lite, and initially expected to appear on Nokia S60 handsets.

Qt presents an interesting riddle. We believe that Qt is Nokia’s technology platform for deploying Ovi services across mobile devices and consumer electronics. Longer term Qt should be forming a platform for Nokia to deploy their own apps and a consistent signature UI environment, although the transition will take 2-3 years to materialise.

Lua is an interesting new contender; it is a scripting language optimised for embedded environments and is known for both its simplicity and flexibility compared to JavaScript. It’s also licensed under the permissive MIT license, which has resulted in it being adopted and embedded into games SDKs and most notably as part of the BREW platform and Qualcomm’s uiOne SDK 2.0 (see details here).

I will be moderating the panel ‘Who will win the Runtime race?’ at the Symbian Show on October 22nd in London. joined by well-respected representatives from Adobe, Microsoft, Nokia, Sun and Symbian:
- Jürgen Scheible, author ‘Mobile Python - Rapid prototyping on the mobile platform’
- Pete Barr-Watson, Senior Business Development/Deployment Manager, Microsoft Silverlight
- Terrence Barr, Senior Technologist and Community Ambassador, Sun Microsystems
- Antony Edwards, VP Developer Product Management, Symbian
- Matt Millar, Director of Mobile and Devices, EMEA, Adobe
- Benoit Schillings, CTO, Trolltech/ Nokia

If you are attending the Symbian Show, do join – I do expect an intense and stimulating debate as we discuss which application runtime will win.

Thanks to Erik Jacobson, Timo Bruns and Terrence Barr for their feedback on the comparative table of application runtimes.

Update: The keynote panel session went well. I did not expect any revelations, especially in front of an audience of 1,000+ people attending the panel. But there was one very interesting announcement at the Show; the role Qt will play for Nokia’s applications, devices and Ovi.

This slide, originally from Nokia’s analyst webcast on Qt on Oct 28, is quite revealing. Nokia is planning to use Qt, its cross-platform application environment, to port its own core applications and Ovi services across a broad range of devices. Qt will then be ported onto S60 (as Nokia announced) as well as across the Nokia device portfolio - which includes S40 - as this slide reveals. Naturally, Nokia’s Ovi services should expand to non-Nokia phones and desktop PCs. We predicted this strategy for Qt in earlier research notes here and here, but Nokia is moving much faster than we were expecting.

Another interesting quasi-announcement was that WebKit will be one of the key pillars of the Symbian Foundation efforts, as announced by Lee Williams, the newly appointed head of the Foundation. WebKit is already integrated on Qt, so we should see the Qt + WebKit stack penetrating mobile devices very fast very soon. In the light of these announcements, we have upped our estimates of Qt embeds in 2009 to 50M handsets, assuming S60 starts shipping with Qt from 2H09.

So which application runtime will win? If Google searches is anything to go by, then WebKit is clearly the ‘runtime of the year’ for 2008. As for the foreseeable future, one thing is certain; there will be more runtimes supported by mobile devices, before real consolidation settles in.

- Andreas

The Finns are behind the smartest, longest-reaching strategies the mobile industry has ever seen. Nokia’s pending acquisition of Symbian is no exception. We ‘ve covered the Symbian acquisition in detail before, but here we ‘re piecing together more pieces of the puzzle.

Industry observers will often point to the Ovi strategy as the reason for the Symbian acquisition, i.e. that Nokia wants to control the service delivery layer on top of Symbian handsets (incl. ones from competing OEMs), on top of which Ovi will sit. But’s there’s lots more to it than Ovi.

Others observe that the acquisition and Symbian’s new open source (EPL) roadmap and zero royalty pledge are Nokia’s response to Android. I would argue, that Android is not the reason WHY Nokia is moving to acquire Symbian, but WHEN it chose to do so; Royalty levels and governance of source code access is something the Symbian board can change anytime it wishes to, and it has in the past. The timing of the acquisition announcement (six months after Android was unveiled) may be why many details on the governance rules of the Symbian Foundation were not finalised at the time of the press release - including IP ownership, who has the right to commit to the codebase, the plans on S60 phones for Japan and the membership fees for OEMs.

But there’s many more benefits that Nokia reaps from the Symbian acquisition:

- Nokia reduces the cost of developing the Symbian OS. We know that the Symbian Foundation will be responsible for “coordinating development projects and managing the master code line”. Estimating that the Symbian Foundation may need 200 staff for managing membership and babysitting the codebase, this implies $20M OPEX, which shared being the 5 OEM members means $4M annually for Nokia. Assuming Nokia will also inherit another 500 Symbian employees (i.e. the rest of Symbian minus non-overlapping functions) from the acquisition, this makes another $50M million OPEX. In total, Nokia’s OPEX costs should be around the $60M mark, or about 50 percent of the royalty fees ($2.5per unit) it was paying to Symbian to for 60+ million S60 phones a year. So Nokia’s OPEX for developing Symbian drops to about half with the acquisition. This is largely dependent on how many Symbian engineers Nokia will retain, and 500 is a large number, knowing that other OSes need 100-200 engineers to develop a core OS (Rubin’s Android team had 100 staff back in 2007, according to a VC - note: the post has been retracted, but you can still find it within Google Reader).

- to further its S60 strategy. Nokia’s S60 has always been about extending the Finns’ control of mobile service delivery beyond its own 40 percent of the market - albeit a strategy that hasn’t bore fruit, given that LG and Samsung have released very few S60 models at low volumes compared to Nokia. The Symbian acquisition displaces UIQ and MOAP, since the majority of the Symbian Foundation code will be formed from S60 and Symbian with “selected UIQ and MOAP(S) technologies integrated” (see whitepaper). The result: Nokia’s own S60 will be used as the UI layer by SEMC, Motorola, who were previously using UIQ and MOAP(S).

- to further outpace other OEMs in producing smartphones. As explained, SEMC and Motorola will have to switch from UIQ (which was only selling circa 1M phones a year) to S60. This means it’s going to be 2-3 years before they can compete with Nokia’s speed of launching new handset models in the market. No doubt, both SEMC and Motorola will be looking at alternatives. Nokia essentially outpaces the rest of the OEMs in producing more smartphones to market, with more models, more quickly and more cheaply than anyone else.

- to more effectively control the Symbian roadmap. Symbian’s past governance structure meant that the software roadmap is controlled by the board of directors, with Nokia having just under 50% share of ownership. Boards tend to be very process-heavy and time-consuming vehicles for software governance, so I ‘m assuming that Nokia did have a strong say, but in a coarse and long-winded manner. Instead with the Symbian Foundation, Nokia will be contributing the Symbian+S60 codebase, to be licensed under an EPL open source license. Our experience with sponsored open source projects is that control is granted to the commercial entity who dedicates the most engineers to code maintenance. Even if participants can fork the code, they are not incentivised to do so, given that a centre of gravity of contributions forms around the biggest contributing entity; for example, Nokia went on record to say that they shouldn’t have forked WebKit from Apple’s codebase. Assuming that Nokia will be putting most engineers to work on the Symbian Foundation code (way over 1,000, if you add the internal S60 staff), there will be little incentive for any OEM to fork (even if the Foundation governance model permits this, which is unknown at this time).

- to cement Nokia’s economies of scale in producing differentiated handsets. In open source projects, the commoditised software base is licensed under an OSI license, while differentiation remains closed source (Maemo, Eclipse and WebKit are good examples). Applied to the Symbian Foundation this implies that SEMC, Motorola, LG and Samsung will still have to differentiate on top of S60, but Nokia will no longer have to manage this differentiating layer on their behalf (it would have limited incentive to do so). Therefore Nokia will have much better economies of scale at producing differentiated handsets compared to the other tier-1 OEMs who will need to develop and manage a UI differentiation layer on their own.

- to marginalise Microsoft away from consumer phones and ODMs. The zero price point for running royalties also makes Windows Mobile way more expensive (based on $6 per unit price according to Nomura), for both consumer phones, and especially for ODMs who have tiny margins. With Nokia recently licensing Exchange server connectivity across all of its S60 phones, this makes Nokia a credible competitor for the enterprise segment, too.

Clearly, the Symbian acquisition has been a very smart move by Nokia indeed.

- Andreas

[We 've recently launched our Mobile Industry Atlas, a visual who's who of 400+ companies in the mobile industry classified into 30 categories. Download a low-resolution sample or order a glossy wallchart]

Symbian’s EVP of Research, David Wood, posted a well-written response to TechCrunch’s rather ill-founded claims about iPhone and Symbian’s relative market shares. Nonetheless iPhone sales have been surprisingly rapid. The queue to buy iPhones outside the San Francisco Apple Store was something any retailer would dream of, and certainly nothing the mobile phone industry has ever seen.

So what is it about the iPhone that caused this frenzy? Why is the iPhone selling in the US when Symbian handsets do not? Why is the iPhone popular in US whilst it seems to have trouble in other markets?

To understand this, I think you need to understand exactly what Apple have built and what their customers want.

Comparing iPhone to Symbian OS is a little like comparing apples and oranges - or perhaps an apple tree to an apple pie sitting in the baker’s store. Symbian is an operating system without a UI built into many many handsets where iPhone is a single device and set of services. Still we can look at the underlying technologies of iPhone. Many of the initial reviews were quick to point out that iPhone didn’t support MMS - something Apple didn’t even bother fixing in the recent major upgrade to the software. This pattern repeats itself in nearly all areas. Consider that iPhone:
- does not have MMS
- only supports a limited set of multimedia formats
- does not have a forward facing camera
- initially shipped without 3G support
- does not have a unified inbox
- support for camera and Bluetooth is at best utilitarian
- does not have a unified inbox
- shipped without multi-addressing of SMS

The only areas where iPhone software excels are the interface. The use of transparency and animation, the physical size of the screen and UIKit, the fluid multi-touch user interface. iPhone is also backed up with a first class range of services requiring little or no set up before they are used - iTunes, the App Store and (less) mobileMe.

This speaks volumes about how Apple approach their product design and underlines the difference between Apple and Symbian/Nokia. Nokia are fundamentally driven by technology and led by engineers. They drive their products from a list of standards. This approach in turn drives the rest of the handset industry - including Symbian. Apple on the other hand are driven by design and ease of use.

When I see the iPhone I’m reminded of another product that sells surprisingly well in the US; the Sony DCR-DVD108 and it’s predecessors. The DCR-DVD108 is a camcorder that records directly to DVD - unlike the iPhone it is pretty ugly. Like the iPhone it is very easy to use - most of the time. You shoot your video and pop the resulting DVD straight into your DVD player; no tape adapter, no editing on a desktop, just one step. So the iPhone and the DCR-DVD108 both focus on ease of use. They make what 80% of the population want to do quick and easy but abandon the more advanced remainder. For the DCR-DVD108 that means no editing, audio overdubs, colour-correction or title sequences. For the iPhone, no MMS, video conferencing or Bluetooth headphones.

The key here is that US, mass market consumers value convenience and ease of use over pretty-much anything else. Conversely, Japanese consumers are happy to work their way through a poor UI to get at the esoteric functionality they just have to have. I believe that in-general consumers the world over are becoming more like US consumers - and that the amount of functionality in a modern smart-phone increases this tendency.

Symbian’s advantage is also it’s problem
On paper, Symbian OS is much better than the middle-ware and OS of the iPhone. The trouble is that on paper is one thing - in the handset, you just can’t access all that functionality. I assert that the problem is Series 60. It’s not to say that Nokia don’t understand interface design - they went to great efforts to unify the core of their hardware designs and to have S60 software support this. Moving to a Series 60 phone from a Series 40 phone is relatively easy. It is not absolutely easy though. Worse, it’s not easy to find and use all the functionality you paid your N Series tax for. The huge depth of technology in Symbian OS is buried in an ageing and inadequate UI.

It’s a shame because Symbian OS could make a much better iPhone that OS X does. It performs better, has better power management and a robust security model. A Symbian OS iPhone would not have to implement the ridiculous “no background apps” rule nor would Apple have to vet every app quite so closely.

The irony of this is that Psion, the company which developed the foundations for Symbian OS, had enormous focus on UI. David [Wood, EVP Research] himself used to quote Pareto’s 80/20 rule with respect to UI design and functionality - do the 20% of the functionality that 80% of the population want (but spend 100% of the time on it). I.e. focus on making the common uses elegant and easy to use at the expense of more esoteric functionality. “Delightful” was a word you used to hear around Psion when describing what their customers should feel.

Can Maemo show the way?
I’d like to say that Maemo is different. Nokia made a clean start and built a new software stack. Sadly Maemo is also driven from a technology soapbox. This time, it’s not a features arms race, it’s open-source-or-die. The Maemo team did not sit down and say “Let’s build a great UI for an internet tablet” they sat down and said “What can we do with open source” - open source is the religion, not ease of use and making great devices that are delightful to use.

As Symbian becomes the Symbian foundation and transitions to an open source model, I hope that the open source community will take some of the burden of implementing every last codec and piece of middle-ware and the Symbian foundation can focus on UIs and ease of use. Unfortunately, I fear that they will be overcome following Maemo’s open-source religion.

The Opportunity
Nokia are obviously aware of this challenge - they have produced a touch device bearing an uncanny likeness to their new rival and touting an advanced touch UI. In reality, I do not have great hopes for “Touch Series 60”. Or rather, no matter how good this UI is, I do not believe that Nokia will have strong enough product management discipline to leave any of the more esoteric Symbian OS functionality out - or even leave it in but without a UI so that a third party developer can expose it for the 20% who want it.

I’d like to say that there is an opportunity for a new entrant to take the initiative and develop a real competitor to UIKit and a “delightful” set of applications on top of Symbian. Something that uses the great foundations Symbian have built to make phones that are actually better that iPhone. Unfortunately, I doubt this will happen - if anyone fancies a try though, I’d be glad to help out…

- Roger

[Roger has been using phones nearly all his life and making them for nearly on third of it. He has worked at Psion, Symbian, Texas Instruments and Sonopia. He can be contacted on rog at hatbat dot net]

The G1, the first phone to carry the Android OS has been discussed extensively across the blogosphere. Those expecting an iPhone killer have certainly been disappointed. So have those who expected Google’s first phone to be “truly open” as Google pledged for the Android OS.

The HTC smartphone is locked to the T-Mobile network binding eager fans with a two year contract. T-Mobile won’t allow VoIP applications running on the handset either. Plus you need an GMail account to use the G1, prompting concerns about whether Google is tracking phone usage (neither confirmed nor denied at present). The phone is also pre-packaged with Google services: search, YouTube, GMail, Calendar, Maps and Streetview, as well as access to Google’s Market and Amazon’s mp3 download service.

The source code for Android will be out in Q4 under an Apache 2 license, hopefully shortly after the October 22 launch of the G1. Yet an open source operating system doesn’t mean an open phone.

The darker side of Android
Google’s Android has plenty of unique features to rave about, as we ‘ve covered earlier. But Android also has a ‘dark side’ - aspects which Google doesn’t want to talk about too much. Here’s a short list:

- Not a market-ready operating system. While Google provides the source code for the entire application environment to OEMs, it leaves the hardest part of cellular stack integration to the OEM and the hardware platform providers. Stabilisation of 3G stacks is notoriously difficult and involves testing 1000s of corner cases of telephony stack integration (something which is believed to have caused significant delays for Motorola’s L-J platform).

- Fragmentation by design. Android uses an Apache 2 license which allows handset OEMs to modify and ship the code without any obligation to share their modifications. At last week’s mobile open source conference in Berlin, Mike Jennings said that the Dalvik virtual machine source code would also be released under APL2. If the virtual machine is open to optimisation changes, this is sure to result in fragmentation by design and interoperability breaks. At the same time it should be noted that software licensed under non-copyleft licenses (e.g. WebKit) is known to resist forking as contributors are incentivised close to the branch where the gravity of contributions are made (Apple’s branch in the case of WebKit). Google offers an API test tool, but clearly what we need is not testing for compliance, but enforcing compliance.

- Liability concerns will result in locked handsets. Android source code is promised to ship under APL2. We assume that this is the license under which the Android OS ships to OEMs. Interestingly, APL2 license explicitly disclaims any and all warranties and liabilities. In the world of mobile software, warranties and liabilities are common practice, offering OEMs to ability to pass on liabilities which result from defective software. In plain English, if an OEM needs to recall a few thousand handsets due to a software fault, they need someone to blame. With APL2, Google steers clear of the liability game and passes the burden onto the OEM to self-indemnify or seek third party insurance with expensive premiums. Moreover, OEMs who ship Android phones will not leave any liability holes open; if a third party application interferes with the handset operation, the OEM will be unwilling to pick up the tab. Which means that Android handsets will move access to several APIs off limits to developers. When I asked Mike Jennings about this at last week’s conference he declined to comment, saying he had not been briefed on this issue.

During several months of testing of Android development on the m5 (pre-beta) release, we had uncovered several additional omissions; the emulator left a lot to be wanted (incl. phone call, battery, Bluetooth and other hardware emulation) while the tools for creating UIs were rudimentary.

A key message here is that an open source operating system does not result in open phones. Google’s ‘built it and they will come’ approach does not readily apply to mobile devices for the reasons described earlier.

Clearly, Google has set the expectations too high.

- Andreas

[Update: this article was awarded 'best post of the week' honours at the Carnival of the Mobilists, hosted by Xen Mendelsohn - thanks Xen!]

Sony Ericsson had a nice webinar last Thursday, interesting held through Adobe E-Seminar:

"Flash Lite meets Java ME on Sony Ericsson phones with Project Capuchin".

At least now we have some information about Capuchin, and I’ll sum it up for our beloved busy executives:

• A technology that allows developers to make the UI using Flash Lite and code the business logic and access to the platform services with Java (ME).
• A development environment with PC based tools (Adobe CS plugin for flash and Eclipse plugin for Java), simulators and a specific runtime embedded in SEMC phones.
• The deployment is done using the well in place Java deployment environment (jar are used, same signature, etc).

Here is first a transcript of the capuchin webcast, then as a conclusion I’ll throw out my thoughts about this and its impact on the industry (if you are still there…).

Project Capuchin Web Cast transcript

Capuchin is about mixing those two worlds, and enforce UI designers and developers relationship.

Why the Capuchin name : it is a monkey like tamarin…the name of the Adobe Action Script VM.

Here is a high level architecture presentation of Capuchin:

Flash content is embedded into a .jar and can be launched by some Java code, then, thanks to the Capuchin API the Flash Action Script can access the various JSR or any other Java class of the project.

Here is below how an accelerometer API may be available in the Flash Action Script of a Capuchin Application:

The Capuchin API works both way: flash to java and java to flash.

What Capuchin is bringing:

Flash development:

• Extend current limited APIs with the use of JSR
• Secure Flash application
• Deploy flash as java games, distribute Flash content through existing java distribution infrastructures

Java Development

• Clear separation between business code and UI
• Nice development tools
• Professional UI tools

How to use Capuchin:

3 main ways to do:

1. Packaging pure Flash Lite content using jar
2. Java Midlet using Flash Lite for the UI layer
3. Java Midlet using Flash Lite for PARTS OF THE UI

Adobe has a nice technology: mxp, format for packaging extensions. Capuchin use mxp to package the APIs that will be mapped into the Action Script.

There is an Eclipse Capuchin Plugin to create those APIs declaration (see above) as they will be usable in the Action Script written in CS3. This tool outputs an XML file which will be used to output Java Classes for the java part to be implemented …. and Action Script classes to be used in CS3.

Everything is then packaged in a .mxp installation package. SEMC will provide some mxp already (Bluetooth , others…)

Demo time:

The webcast then featured a demo:

swf2jar :

Goal here was to show the tool to convert a swf to a jar, swf2jar: very useful for packaging because a flash game today…end up in the image folder when deployed in a SEMC phone :-)….

Calendar component:

Project Capuchin plugin for CS3, with mxp packages. The intent here was to show how to use Java services in a Flash Lite content

There are some "Platform components" in the library:  in the AS editor, it is possible to import for example the package com.sonyericsson.capuchin.calendar.Calendar

… to import the Platform classes,  so it is now possible to use the Calendar class as a normal Action Script, even if it is a Java Service.

One word about the toolchain future:

In gray: Not done today:

• Flash Emulator will be connected to Eclipse to use java services directly and not only stubs
• UI library: a flash widget library will be developed
• Connect everything to the existing SEMC phone emulator
• Work with adobe so that in device central, when a SEMC phone is selected the list of available mxp would be provided.

What will be published soon:

• First phone : C905, compatible with capuchin APIs
• Capuchin APIs,Java Classes
• swf2jar tool
• Capuchin API generator , eclipse plugin
• mxp packages with source code
• capuchin test and video tutorials
• demos applications

=>check here http://developer.sonyericsson.com

(final: October)

SEMC Capuchin will be present at Adobe MAX in San Francisco and in Italy in December!

Some Q&A with no major questions…mine were not answered:

• What is the implication of Adobe in this project?
• What is the implication of Esmertec in this project?
• Is there a roadmap to have Capuchin on other platform than SEMC ones?

Some points about this initiative:

• SEMC has already done a large part of their applications in their feature phones in Java, and they have a strong Java commitment with Esmertec, so on SEMC phones Java is the preferred development method internally….and now with Capuchin, externally as nearly all the platform services are already available in Java.
• With the point above, and knowing that some part of the SEMC feature phones themes are already in Flash, merging Flash Lite and Java was a natural choice for SEMC

• Flash Lite choice is the only one possible for today mobile phones (CPU/Memory)…but is really not a complete and efficient UI application frameworks, it lacks …widgets! So SEMC plan to develop some new ones, hum wait, Adobe Flex is not about that? Bringing application development to Flash?

• Not sure about the porting of such a technology on other platforms than SEMC … but from my knowledge only another one has made the Java choice: Google Android where all the platform services can be accessed through Java, but I don’t see any incentive for SEMC to port it to Android

Conclusion

So we have a new Application Environment, with its own SDK, that will certainly be only available on SEMC platforms….Capuchin one will complete this never ending list:

Are we still talking about cross platform development? About consolidation and standardization?  NO

The industry is pushing the other way, and really this is NOT AN ISSUE.

Services and applications developers have learnt how to reuse code across platforms, how to architect their code and services so that it is easy to change only the presentation and the adaptation to the platform: after all developing a UI for a 800*480 screen and a 176*220 is just something completely different, and really not a big deal if your UI is uncorrelated from your services; Capuchin helps that, as many other technologies.

All those new Application Environments are bringing to Mobile Platforms  great core value for services deployment :

• openness
• great tools, ease of development
• focus on user experience and UI
• deployment/packaging/distribution strategies
• security

And we don’t want a "one size fits all" environment, it is simply not true in an industry where the forms factors, capabilities and designs are so vastly different. Differentiation is key in this market, just open the platforms with nice and open development technologies, it is enough!

One big trend we can foresee also is that the platform vendors have no more software complex, and when you look at the list above, nearly all the initiative are coming from OEM, and not really from pure software companies (notable exceptions: Android and WinMob)….PC based paradigm seems soooo far away!

For years Intel has repeatedly failed to get a piece of the Mobile phone 1 billion devices a year cake.  The latest known attempt was the infamous XScale processor.. too big, too slow (albeit a high MHz count) for the smartphone application processor market, which has been trounced by the usual suspects ARM based manufacturers (TI, Samsung, …).

Yet Intel is coming back to its roots: x86. And their weapon is the ATOM processor.

At first it was designed to be a very power and simple x86 core to be used in multi core processors (with a lot of core) … but its strength was fully applicable to a nascent market: the UMPC. And from a UMPC to the MID ( like the Nokia 770/800/810 Tablets)  there’s not a lot of differences. Anyway ATOM is not competing against archrival AMD, but… with ARM manufacturers (Nokia Tablet, ipod Touch are ARM based), with an important edge: not so because of the performance (even if it is faster), but because it can run windows! It’s a full x86 chip. Ok, power consumption is still faaaaar from an ARM based system, but Moorestown will lower this barrier:

Intel has publicly committed that Moorestown will have at least 10 times less idle power consumption than the previous-generation Menlow platform.   (source)

Even if running windows may help convince some manufacturers and users, there is currently a trend for “exotic” software platforms that are well, simply doing their job. An MID is NOT a generic PC: Nokia Tablet OS, MacOS X mobile ( ipod Touch/iPhone), Linux based UMPCs, Samsung latest smartphones…upcoming Android and Limo…are all “windows” decomplexed interesting platforms. Intel decided to become more than a silicon vendor: they want to go the system provider route, and for that of course they need their very own software platform (yes a new one…):

The video above is simply a mock up of what it would look like….This software platform is called Moblin. Moblin 1.0 is (was) a sister project of Nokia Maemo (foundation of Nokia Tablet OS): same Application Framework (Hildon), nearly the same API’s, same UI framework. However, according to Intel’s own words:

Moblin has “failed to generate much interest” among developers. “Moblin 1.0 wasn’t successful in creating this community push,” Hohndel (Intel’s Dirk Hohndel, director of Linux and open-source strategy,) was quoted as saying. “Having a vibrant community push is the winning factor.”   (source) 

So Intel needs a differentiator: Intel and its OEMs will now compete with Nokia, Android, Apple… Intel needs some fancier software, so here it is: Moblin 2.0 - still Linux based for the lower layers, but with a new graphical interface based on Clutter and Compiz. Clutter is a “modern” (ok still some glib ugliness in it) 2.5D widget framework, and Compiz a very nice 3D window manager, both based on OpenGL (ES). Here is an example of a Moblin Clutter application:

Around this Intel is planning a lot of services and Applications, like the Contact Epicenter, or a Mozilla based browser, Fennec (incidentally same choice as Nokia for its tablets…all the other platforms being webkit based). And with the announcement of Intel acquiring OpenedHand, the company inherits all of OpenedHand’s projects:

• Clutter : You know it now
• gUPnP : UPnP library
• Matchbox : Window Manager + application used….in Nokia Tablet, OLPC and OpenMoko!
• Pimlico : set of Mobile PIM Applications
• Poky : An open source software development environment for the creation of Linux devices

So basically OpenedHand brings to Intel some key pieces for its platform, especially Clutter ….and the tools ALL the Linux vendor are missing: a Platform Builder to help OEMs put their platform in place! (Only Microsoft has it with the Windows Platform Builder, designed to adapt WinCE and WinMo to various hardware platforms, bring the necessary modules together, etc.). But perhaps the key OpenedHand assets for Intel are the people behind OpenedHand; Kudos to them to be there since 2000, and now part of Intel! Intel is serious about this platform, beware Symbian, Limo, WinCE, MacOSX mobile and Android, here is a new credible platform to look at!….Anyway Intel is  first a silicon fab, down to its DNA, so the open points will be:

• Is Intel able to commit long time efforts to software?
• How about software support to its OEMs?
• And the most important point: Is Intel able to design a software platform with a great user experience? .

The last point is crucial; WinMo and Symbian have failed in this regard, even if they have been designed by software companies. Putting open source technologies together is really not enough to make a consumer product.. I’m eager to see if Intel has, or is hiring some usability and design experts (and not only software engineers). Anyway having a new credible, deep pocket actor in the industry is always good news… and with the gap from MID to smartphone really blurring, we may expect some great devices!