[Adobe just released and new way to package Flash Lite Applications for S60 and WindowsMobile: this announcement, if linked to the announced Google native client, the Adobe Alchemy product and other industry initiatives is an indication of where the desktop and mobile development are going. Blogger Thomas Menguy tries to bring some coherence to these seemingly uncorrelated initiatives].

At one time application developers were targeting OSes: Windows, MacOS, Unix.

At one point the target began to move towards runtimes (or Application Environments as discussed in this earlier article): the web browser, Flash player (inside the web browser), Java VMs, .NET, and more recently Java FX, Silverlight, AIR…

In all cases each runtime is imposing its own development environment, tools, SDK and above all a development language (Java for the Java VMs, Action script for Flash/Air, Javascript for the web browser, C# for .net).

And of course the runtime has to be installed on your final target, BEFORE deploying your application or content.

But the lines between tools, languages and runtimes are now blurring, as evidenced by several industry moves:

• Mobile Open OS are all offering solid and robust application and content management (the Mobile Application Store syndrome). A runtime sandboxing its dedicated content from the rest of the system is seen like an unnatural way and bad user experience for handling content.
• Google has a framework (GWT: Google Web Toolkit) to develop for the web browser runtime … except that the development language is NOT javascript
  • You develop in Java
  • In Eclipse or NetBean
  • You can use a RAD
  • The Java code is compiled in Javascript and will run in a browser not a javaVM (except for development)
  • This brings a kind of unified approach for the client and the server
• OpenLaszlo is a great RIA development platform …without a specific runtime :
  • You develop in the OpenLazlo language : LZX, a specific XML + Javascript
  • You compile your code for flash or DHTML (a Java version exists but doesn’t seem to be supported anymore) so you can select your runtime!
• .Net /Silverlight
  • You can choose you development language VB#, C# or action script
  • All are compiled to the .NET bytecode runtime
  • Microsoft is releasing its “Expression” line of tools to bring ease of development to the designer/developer
• Adobe AIR
  • You can develop in Flash/Flex/Action Script or … in AJAX (Javascript)+HTML
  • The Air runtime is in fact an aggregation of a Web Runtime (Webkit) and a standalone Flash player
  • Your applications are deployed …nearly like any other application on the underlying platform. The ‘nearly’ is important because the AIR runtime installation is still visible, as is the application air packaging
  • Adobe is releasing Catalyst, a very nice WYSIWYG application prototype IDE targeted to designers with strong links to CS4
• Google Native Plugin
  • Allows to develop and reuse C/C++ code … in the browser
  • use a raw GCC toolchain (and so the browser plugin has certainly to embed an OS independent dynamic loader…reminds me something we are doing for years at Open-Plug )
• Haxe:
  • An Action script like language you can compile to … php, C++, java and of course ActionScript
  • Unification of the client and server development
• The adobe Alchemy project (for the techies, explained here):
  • Compile any C/C++ code to ActionScript byte code to be run in a flash player (examples of Doom, here,  and Quake running in Flash are now famous)
• And the announcement triggering this analysis: Adobe Mobile Packager
  • Development in CS4, with CS3 device central
  • Flash Lite Application is packaged in a “standard” .CAB file for Windows Mobile or an .SIS file for S60, with everything needed to make your application run
  • Flash Lite applications are no more second class citizens, you don’t have to open the Flash runtime anymore to launch such applications
• SonyEricsson Capuchin
  • … is at the end the way to package flash lite application in a java jar file.

All those examples are depicting underlying trends:

• We see, more and more a decorrelation between the development environment and the targeted runtimes
• Many development languages are popping out, and we won’t have a “one language fits all” : developers will tend to use
  • What they know , and it’s even easier now with all those tools
  • Reuse legacy code as much as possible
  • What fits best for a particular task
  • What can help with client/server development
• Ease of development and tooling seems to be key, especially looking at Microsoft and Adobe strategies
• The on device final Application Management is left to the underlying platform/OS and will be more and more abstracted for the developer that is targeting multiple platforms with a single application development environment.

From what I see today, I tend to think that Adobe is getting it right, little by little, especially thanks to their very strong tooling offer (CS4/FlexBuilder/Catalyst)…and we may see other initiatives from other players like Nokia or even Google to accelerate the development and deployment of services (web or not).

Interesting times for a developer!

Looking forward to your comments.

Thomas

[Android, Symbian Foundation, Maemo, Trolltech… there’s been so much talk about open source moves in the mobile industry, but so little analysis on the big picture.  Andreas Constantinou distils market noise into market sense by mapping out three dimensions of open source in mobile: the who, the where and the how.]

Without a doubt, 2008 has been the year where open source has transitioned from a status of early adoption to one of acceptance and endorsement by the mobile industry’s who’s who as a recipe for collaborative software development.

The Android launch, the Symbian acquisition and open source roadmap, Intel’s Moblin 2.0 and OpenedHand acquisition, Nokia’s adoption of WebKit as a feature of the S40 platform, the Trolltech acquisition and incorporation of Qt on S60, Purple Labs acquisition of Openwave and Sagem assets, AOL’s Open Mobile Platform… it seems that in the space of just one year open source has transitioned all of a sudden from geekware for Linux enthusiasts to a succesful commercial alternative to closed-door standards.  Moving forward, 2009 will be the year of maturity for how open source can be used as a tool for cheaper, faster collaborative software development, which reduces barriers to entry and breeds innovation.

Yet rarely do analysts, bloggers or media cover the big picture of open source use in mobile; in other words who is using open source, where are they using it and under what terms (i.e. the license and governance terms). Here I ‘ll attempt to do just that; paint the big picture of mobile open source against three dimensions, the who, the where and the what

1. The Who’s Who
Who is who in mobile open source? The following table provides a near-complete list of who’s who, from operating systems to development tools and industry initiatives. Naturally, the table excludes the 100s of smaller open source software projects that have been used in some capacity in one phone or other.

Table: who’s who in mobile open source

There are also a couple of initiatives which are associated with ‘openness’ but are not related to open source; Microsoft Shared Source is a complex array of 10s of different licenses involving access to source code for Microsoft software, only two of which have been approved by the Open Source Initiative, the gatekeeper of open source license compliance; and the Adobe Open Screen Project which does not employ open source licensing at all.

2. The Where
Where is open source software used in mobile phones ? The following table provides a 10,000 foot view of where open source licensed software is used within a mobile phone, from the kernel to applications. The rule of thumb is that the lower you go towards the base of the software stack, the more open source software you ‘re likely to find.

Table: where is open source used in mobile phone software

Open source licensing is also used in server software; most notably in Funambol’s email synchronisation server and Volantis’ Mobility Server, a device identification and content adaptation framework. Network infrastructure vendors like Nokia Siemens sell Linux-based boxes and software, but that doesn’t really imply an open source product.

3. The How
How is open source used in mobile? In other words, what are the licenses and the governance models employed in open source projects?

Several major mobile open source projects use a weak copyleft license (e.g. EPL, LGPL or MPL). Generally speaking, weak copyleft licenses carry some obligations for publishing source code modifications if distributed, but clauses around derivatives are less strict so can be used with proprietary software. The APL2 (non-copyleft) license is also popular – it is used in Google’s Android, Motorola’s planned MIDP3 release and AOL’s Open Mobile Platform.  Note how the GPL license, by far the most popular license in PC and Internet OSS projects is rarely used in mobile. This is one of the reasons for the zero adoption of Sun’s Java phone ME by handset OEMs and the same reason why Qt will have to be re-licensed under a more permissive license if Nokia wants to see it adopted by other handset OEMs.

Governance models vary widely; from Funambol’s moderator-based incorporation of contributions, to a single-company control over contributions, as is the case with Apple’s popular WebKit browser core. There’s lots more parameters to a governance model – particularly control over the release schedule, membership-only access, membership fees and IP ownership, but this a lengthy topic that deserves a separate discussion.

The next table summarises the license type and governance model (how contributions are managed) for popular mobile open source projects (see also earlier article on community dynamics).

Figure: comparing community governance models and licenses for popular OSS projects

Here it’s worth shedding some light over a common misperception; an open source license does not imply a zero licensing cost.

For example many Linux-based OS vendors like Wind River, Azingo and Purple Labs are charging per-unit royalties for the software. As another example, the Symbian Foundation has vowed to release Symbian OS code under an EPL license, while members of the Foundation will have access to source code under a zero royalty license, for a flat membership fee of $1,500 per year. However the Symbian Foundation hasn’t publicised the fees members will have to pay for shipping handsets with the Symbian Foundation code; if the Foundation is to support is sub-500 staff (numbers according to Lee Williams), then the effective license fees should be in the region of millions of dollars per year per member.

Comments welcome as always. And thanks to LinuxDevices and the O’ Reilly Radar for covering this article.

- Andreas

[If you ‘d like to find out more about open source in mobile, check out our 360 degree workshop, a one-day deep-dive into everything and anything that is mobile open source, from economics and business models to license best practices, software management guidelines and 20+ case studies of real world lessons from open source use in the mobile industry.

You can also download our free research report on GPL2 vs GPLv3: The two seminal open source licenses,  their roots, consequences and repercussions.]

Update: We ‘ve been voted as the best blog in the Mobile Comms category by  Electronics Weekly Magazine!

[Research Director Andreas Constantinou, discusses the latest update to VisionMobile's 100 million club, and the bigger picture that emerges from our research, including de facto standards and software that's truly mass-market]

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

[Apple's App Store, Android Market, RIM Application Center.. application stores are the latest fad of the mobile industry. Research Director, Andreas Constantinou, analyses the recipe of the mobile application store phenomenon and the movers and shakers of this virgin market]

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.

[Updated: The official BREW figures from QIS state "80M+ average monthly transactions during 2007", so that number should include content downloads as well as application downloads. It's also worth mentioning that BREW's download system offers one of the most advanced range of billing models, including subscriptions and prepaid credits that can be used for purchasing  applications or content.]

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 Cellmania, 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, Microsoft’s SkyMarket and Adobe’s Appzone.

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

Updated: We ‘ve been voted as the best blog in the Mobile Comms category by  Electronics Weekly Magazine and we ‘re thrilled!. We managed to rise to top spot despite competing with very popular blogs such as Disruptive Wireless, Engadget Mobile and Mob Happy.

Thanks to all those who voted for us and to the 1500+ regular readers of our blog. Here’s to an even more exciting year in 2009 with lots of smart moves in the industry chess board. We ‘ll be watching, analysing and, as always, distilling market noise into market sense.

Thanks for your support!

- Andreas

[Mobile software has always been a tough business and is getting tougher. Research Director, Andreas Constantinou, explores how the value is migrating from embedded to downloadable software].

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, WebKit, Java ME, Silverlight, Qt, Lua, Python… Research Director Andreas Constantinou takes an analytical look at the new battleground for mobile application runtimes and the struggle for dominance.]

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

[Why did Nokia really acquire Symbian for? Research Director Andreas Constantinou digs beyond the surface to analyse why the Symbian deal is about far more than just Ovi and Android].

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]

[Will Symbian learn from the iPhone as it transitions to open source? Guest blogger Roger Nolan looks at the challenges iPhone presents to Nokia and its OS strategy.]

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]

[Can an open Android result in a closed phone? Research Director Andreas Constantinou explains why this will not be the exception, but the rule]

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!]