Search Results

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

[SonyEricsson is promoting a new Application Environment mixing Java ME and Adobe Flash Lite: Capuchin. Blogger Thomas Menguy tries to describe it and evaluate what “yet a new” development platform means to the industry ]. 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 transcriptFlash  Lite from an SEMC perspectiveJava ME from and SEMC perspectivePros Tools Community books, forums, tutorialsPros Wide platform access: JSR’s Security: MIDP protection Distribution infrastructure using JAR Wide adoption languageCons Limited system services access No security solution Lack distribution channel memory/cpu consumptionCons Lack of designer oriented tools no rich UI framework difficult to keep separation between presentation and service layer Designers dependent on programmers in UI dev 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: Packaging pure Flash Lite content using jar Java Midlet using Flash Lite for the UI layer 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: iPhone native/iPhone SDK iPhone Web Apps S60 Nokia Qt UIQ (oups, RIP) LIMO Maemo Motorolla WebUI Android J2ME (and all its flavors …) Capuchin Flash Lite Flash/Flex/Air Brew WinMob PalmOS BlackBerry …and so on… 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!

[Intel is moving fast toward MID: Mobile Internet Devices, and just bought an open-source mobile centric company: OpenedHand… blogger Thomas Menguy looks at the current Intel strategy to establish a share in the mobile market]. 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…): httpv://www.youtube.com/watch?v=XcN_9vZ7j20 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: httpv://www.youtube.com/watch?v=AYGp6iBmCyM 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!

[Flash, Web Runtime, OSX, widgets, Java engines, Python.. the array of software platforms is chaotic to say the least. Research Director Andreas Constantinou digs deeper into application environments, explains who’s what and identifies 5 clear market trends]. Talk in the mobile industry is often peppered with software mega-brands; Google, Adobe, Microsoft, Linux (see earlier article on the 7 centres of gravity). After a long 7 years since the introduction of smarter mobile phones, software brand names like these are making a splash into the mobile phone scene. But the array of software platforms for mobile phones keeps growing.. and gets more and more entangled by the month, as new platforms surface. Of particular interest are Application Environments (AEs), the software layer which enables developers to develop, deploy and execute their applications on a mobile phone. Here I attempt to shed some light into the darker corners of the AE space, based on a similar presentation I gave at Informa’s Handsets World conference in Berlin in June 2008. For access to the full presentation see the end of the article. A very diverse range of application environments is available today: – Java ME, Flash Lite and BREW  (and their implementations) are the most well known  application environments. Silverlight has made a lot of noise recently as a Flash Lite competitor licensed by Nokia. Microsoft’s .Net compact framework and Red Five Labs’ Net60 are also noteable. – Google has introduced the much talked about Android operating system which in most part is a well designed application environment for Java SE-like apps. – decending from the web ancestors, the WebKit core and Nokia’s Web Runtime are also suitable for running lightweight apps with HTML  elements and in some cases access to native device APIs. – on the scripting front, a diversity of scripting engines exists such as Lua, Bling’s ECMAscript engine, Sun’s JavaFX and ActionMonkey (the merge of Mozilla’s Spider Monkey and Adobe’s Tamarin). – SVG player vendors like Ikivo and Bitflash are actively evolving their software into application environments for custom operator and OEM applications. – Smartphone operating systems (Symbian/S60/UIQ, Windows Mobile and OSX) are often portrayed as ‘open’, where in reality they offer  yet another application environment, which exposes (some) phone internals to application developers. -Linux-based operating systems like MontaVista, WindRiver, PurpleLabs, Azingo and Access ALP all encompass some form of application environment – traditional real time operating systems (RTOS) also feature proprietary application environments – including Mentor Graphics’ Nucleus, ENEA’s OSE and lesser known OSes like OpenPlug’s ELIPS. Naturally every tier-1 OEM has multiple, proprietary in-house application environments. Clearly, this makes for a huge choice of platforms to write mobile software with. So who’s who ? who’s what? Understanding Application Environments In this post we introduce a basic framework for comparing and contrasting application environments. To start with, AEs have four main properties: – Develop: open, simplify, manage and support mobile application development – Deploy: tools and processes for marketing, distributing, installing and monetising from applications – Execute: the client runtime that interprets or compiles and executes the application; the runtime in many cases ensures interoperability (consistency of execution across devices) and also integration into internal device APIs. – Deliver: help connect the application to the online world via web, widgets, as well as provide synchronisation and remote management APIs. Traditionally, the focus of AEs has been on opening the phone to application developers, installing the application and ensuring interoperability across devices (lovingly referred to as write-once-debug-everywhere). Little attention has been paid to critical issues for application developers such as marketing, distribution and device integration (BREW is a bright exception here). Order from chaos To make sense of who’s what out of the 50+ application environments we introduce 2 key criteria for AEs: – whether an AE is designed for 3rd parties (i.e. any developer out there) or 2nd parties (handset OEMs, network operators and their partners). This design goal makes a huge difference to the ease of development, ease of access and overall number of applications. – whether an AE is designed for core applications (e.g. dialler, idle screen, main menu, inbox, camera, album, mp3 player) or downloadable applications (e.g. games, messaging and VoIP utilities). This design goal makes a major difference in terms of the commercial relationships required, application frequency of use and impact to the user. The slide below provides more detail. If we attempt to classify application environments across these two axes (core vs downloadable and 2nd vs 3rd party focus), we end up with the following very interesting chart. Two key observations emerge: 1. AEs for developing core apps are restricted to 2nd party developers only. This means that innovation for the most critical applications used more often in the phone are available to only a few 100s of software houses forming the inner circle of trusted partners amidst OEMs and MNOs. Conversely, 3rd parties only have access to a limited range of APIs and in most cases no opportunity to write applications with high impact such as addressbook and inbox applications. 2. Android is the first application environment to allow 3rd parties to develop core applications. Google’s OS offers a well thought-out architecture allowing applications to tap into system events (e.g. incoming calls and messages) and access user data. However, the true test of Android’s openness will be in the OEM’s implementation of the phone security policy; it is plausible that an OEM will restrict application rights to a circle of certified (read: trusted) developers in order to manage and mitigate liabilities from the threat of malicious applications. Wrapping up, there are five clear trends emerging in the evolution of AEs: – Android is leading the trend to open more parts of the phone to more developers – the iPhone dashboard is leading the way to simplifying the discoverability of third party applications – JavaScript and Lua are leading the way for the simplification of the development environment – BREW and Nokia’s Web Runtime are leading the way for integration of the AE with the device internals. – BREW and Apple’s AppStore are leading the way for streamlining go-to-market channels and offering financial incentives to application developers. The next slide offers more detail into these five trends. Clearly an interesting space to watch. Comments welcome as always. – Andreas [a full version of the presentation with additional content is available through Slideshare]

(see visionmobile.com/maps for the latest Edition of the Mobile Industry Atlas) After many months in the making, we ‘re announcing the Mobile Industry Atlas. The Atlas is a visual map of who’s who in the mobile handset industry, available in glossy A2 wallchart and PDF format. This is a comprehensive map showcasing 400+ leading companies across 30 market sectors, spanning all major players involved from handset design through retailing including development and delivery of hardware, software, SIM cards, services and content. The Mobile Industry Atlas maps the players involved in the core value chain from handset design to retailing, framed by those who participate in the pre-load and post-load phases of the handset lifecycle: Pre-load actors: the vendors involved in providing software, hardware and services to the core value chain during the design and development of the handset, and before the software is embedded into the handset. Market sectors: Input Technology, Plastics & Mechanics, Multimedia Chipsets, Baseband and Appl. Processors, Multimedia & Graphics s/w, Browsers, App Exec Environments, On-Device Portal Solutions, Active Idle Screen Solutions, UI Frameworks. Core value chain: the vendors who form the backbone of the handset design, development and retailing lifecycle, from industrial design houses to distributors and retailers. Market sectors: Industrial and UI Design, Silicon and Hardware, Reference SW and HW Designs, Operating Systems, Middleware & Core Applications, System Integrators, Handset ODMs and EMSs, Handset OEMs, Mobile Operators, Distributors & Retailers. Post-load actors: the vendors involved in providing content, services and delivering services after the handset has left the factory, and post-sales. Market sectors: Mobile Content, Games Publishers, Service Delivery Platforms, Mobile Device Management, Content Retail & Billing, Mobile Advertising, Mobile Search, Content Targeting, Software Services, SIM card OEMs & Applications Vendors. The Atlas is available to order in PDF and A2 wallchart format. Well done to all of the team for getting this out of the door! – Andreas

Welcome to the 133rd edition of the Carnival of the Mobilists! This week’s Carnival is hosted by VisionMobile. This week there are quite a few thought pieces and observations worth reading. The iPhone 3G has kept most bloggers busy, but it’s refreshing to see the diversity of topics covered, from challenges in modelling mobile broadband subscriptions to axioms of user interface design. This is trully mobile biodiversity! Starting with the iPhone posts, Justin Oberman at the MOpocket blog recounts his experiences on the appaling battery life of the iPhone 3G… so appaling that to save battery life Apple suggests you can turn off 3G, location services, push email and 3rd party applications. That’s when technology innovation fails – you buy a new iPhone 3G, not to use any of the new features. C. Enrique Ortiz at his Mobility Weblog reflects on last week’s news that the iTunes Apps Store saw 10m downloads in just 3 days and makes a very sharp observation;  people WILL download applications, if the problem of discovery is solved.. local applications are not RIP, as many have argued.. ease of discovery must always be part of the mobile solution: be it a search box, an icon on the home page of the handset, a mobile widget, or side-loading. Is everyone listening ? Ian Wood makes another good observation at his Digital Evangelist blog: the iPhone still has a long way to go; for one, it is only available in two colours and two storage sizes, whereas with iPods there is a choice also in terms of form factors with the Shuffle, Nano, Classic and iTouch. Moving to mobile strategy posts, Ajit Jaokar at his OpenGardens blog makes a good point: every player in the value chain will have to make the choice between being a Pipe (e.g. IP networks), a Software (e.g. WebKit, LiMo) or a Platform (Nokia and Google). It’s a choice certainly most operators are reluctant to make. Continuing with another thought piece Andrew Grill writes at his London Calling blog: we’re all an impedance to the brands and advertisers getting their message to the consumer. I couldn’t agree more; the mobile industry overemphasizes technology and mobile operators (the main route to market) are especially profficient at stiffling innovation and blocking long-tail opportunities. Dean Bubley at his Disruptive Analysis blog ponders on the intricacies of mobile broadband subscribers and whether there is really an accurate model for quantifying mobile broadband adoption & device usage. Barbara Ballard, one of the few voices on mobile user experience writes about design principles at the Little Springs Design blog. Barbara illustrates some cardinal points on user interface design, namely simplicity, progressive disclosure of information, and how invisible interactions are not always a good thing. Which makes me wonder – why is it that so few mobile software companies employ UI design specialists ? This needs to change. Finally, Martin Sauter at the WirelessMoves blog writes about how wireless internet is now becoming available for the masses. And while there is software (e.g. Opera Mini) and hardware (e.g. EUR100 phones off contract) available, what’s missing is the proliferation of fair use, prepaid data plans, training of sales people, device auto- or pre-configuration and advertising of compeling services. Well said. The post of the week honours go to C. Enrique Ortiz for his thesis on why discoverability is what’s stalling the take-up of mobile apps. It’s always great to see such thought leadership in the mobile industry. Next week tune in to MOpocket for the 134th installment of the best of the mobile blogging- and please keep those thought pieces coming! – Andreas

[The first half of 2008 took the mobile industry by storm.. Nokia+Trolltech+Symbian, Android, BREW+Flash, Adobe Open Screen, LiMo devices.. As the dust settles, Research Director Andreas Constantinou looks at how the mobile landscape is shaping around 7 centres of gravity]. As the dust is clearing after the storm, a new landscape is unveiling in the mobile industry; one where the balance of power is concentrating around 7 centres of gravity: Adobe, Apple, Google, LiMo, Microsoft, Nokia and Qualcomm. In other words, the industry is transitioning from a horizontal structure of operating system offerings circa 2002 to a vertical structure of complete offerings circa 2008 (as all industries do, based on the double-helix management theory). The seven heavyweights share a common vision: to become the dominant way of building phone software and thus control how services are delivered onto mobile devices in the future. Their gravity pull means that they also influence a large part of the value chain making software vendors, handset OEMs and network operators dependent on them. There are two more common elements in these 7 forces: the move to use open source licensing so as to share software development costs and the formation of industry consortia to accelerate commercialisation efforts and reduce time-to-market. The next diagram analyses the fundamentals, components and commercials of the 7 centres of gravity, and comes from our forthcoming research report on Android vs S60 (click to enlarge). Google’s Android is in essence an application environment for opening 3rd party Java developers to access 100% of the operating system capabilities (see earlier analysis on the significance of Android). It is backed by the Open Handset Alliance, a closed consortium of  technology and commercialisation partners. The UI customisation capabilities are also notable, offering system-wide customisation and extensibility of built-in controls. The open source license (as of version 1.0) and the zero royalty fees have been largely responsible for the cascade of announcements in 1H08. However, the real test of Android’s openness will be the security policy implementation that will be chosen by the handset OEMs as they balance developer openness with their liability exposure (imagine the irony.. open Android, closed handsets). LiMo is a consortium led by mighty operators Vodafone and Orange who are seeking to commoditise the OS and facilitate deployment of their own services via rich clients and container programmes. However, LiMo has yet to prove its credibility; the 18 devices announced to be LiMo compliant should in effect have little in common. LiMo’s practical impact is in having lead integrators WindRiver, Azingo and Purple Labs provide a common-ish Linux-based stack to lead operator requirements and accelerate mobile Linux shipments. Nokia‘s Symbian acquisition (see earlier analysis) marks the resurgence of the S60 licensing strategy, providing a means for Nokia to more easily deploy its Ovi umbrella of services to non-Nokia devices (and non-S60 devices thanks to Trolltech’s Qt). Nokia’s plan to use the open source EPL license for Symbian+S60 cements the impending commoditisation of the operating system. BREW has been a complete vertical ecosystem since its foundation, thanks to Qualcomm’s foresight. The BREW application environment  ships on about 1 in 10 of today’s mobile devices, making that more ubiquitous than S60 (see our 100m club analysis of shipments). However BREW is facing persistent challenges in expanding beyond its US and Japan strongholds and has been in the last year competing with Windows Mobile on its home turf (given that QCT chipsets also ship with Windows Mobile). Clearly BREW needs to continue out-innovating the other centres of gravity if it wants to stay ahead of the game – and the recent announcement of embedding Flash onto BREW should prove a step in this direction. Apple is an industry wonder, and the only player to succesfully, single-handedly  create a vertically integrated offering spanning from hardware to industrial design and services. The AppStore is the developer-go-to-market program that is the latest addition to its vertical offering. Microsoft has been achieving a near-doubling of Windows Mobile shipments between 2007 and 2008. More importantly, it has loosened its restrictions on the UI customisation, enabling OEMs like HTC, Philips, nVidia and Sony Ericsson to replace the quintessential Start button with trully innovative UIs that matter to consumers. Microsoft’s Danger acquisition should also help the Redmond giant to spearhead its consumer push with innovative industrial designs from the designers of the innovative SideKick. Last but not least, Adobe has been extremely succesful at penetrating the mobile industry, and will soon be claiming the position of the de facto application environment as Java has failed to achieve consistency of implementations. Adobe’s thinness of its offering (compared to the other centres of gravity – see chart) is balanced by the comprehensiveness and penetration of its developer tools. As to the second half of 2008, I expect Microsoft to follow with a more open policy towards code sharing and contribution (in the footsteps of Symbian Foundation).  And lots more announcements that the crystal ball is too hazy to reveal at this moment.. – Andreas

[Purple who? Research Director Andreas Constantinou analyses the recent acquisition of Openwave’s client business by Purple Labs and how a relatively unknown French software vendor is becoming a key player in the new world of open source software  for mobile phones.] acquired the client business of Openwave, bringing together a Linux-based software stack with a browser and messaging suite. The acquisition brings Purple Labs in head-to-head competition with the Access Linux Platform (ALP) and Azingo, a US-based vendor of Linux-based operating systems for smartphones. It also makes mobile open source one of the main battlegrounds of the mobile industry today, following close on the heals of the Symbian Foundation announcement (see full analysis here). Based in France, Purple Labs has transitioned from a little known design house arm of Vitelcom (a Spanish ODM) to a well-funded 100-strong OS vendor boasting the only commercial single-core 3G Linux software stack and three Linux mid-tier phones shipped in Europe since 2006. The transformation has been led since late 2007 by Sofinnova Partners, Earlybird Venture Capital, and Partners Group who have invested $15 million in addition to supporting the $30 million acquisition of the Openwave client business. This puts Purple Labs on a level playing field with Access Linux Platform (backed by ACCESS, a billion-dollar valuation company) and Azingo (funded with $30 million to date) and should help Purple Labs build its professional services team which is a critical element of a Linux-based OS business. It’s also worth noting that Purple Labs is so far the only vendor with a commercial 3G stack, and one which has been integrated on a single core handset, both of which are major engineering achievements. It is also the only vendor of licensable software stacks (alongside Mizi who had shipped its OS on 3 Samsung phones) and the only Linux-based software stack which has shipped on European phones which come with demanding requirements for GCF certification and operator (incl. i-mode) customisation. Too good to be true ? The next six months will tell, as ALP, Azingo and Purple Labs are preparing to launch their next handset projects and OEMs are being called to choose between S60/Symbian, Android and Linux stacks. Purple Labs is led by Simon Wilkinson and the ex-Magic4 management team who led Openwave’s client business. The same team has now effectively led the acquisition of Openwave’s browser and client messaging products including all code, patents, customer contracts and the engineering team. Bringing Openwave back from the ashes Opewave has suffered a major decline in the last year. In May 2007 it was announced the business was up for sale, it’s looking for a new CEO and its share price (OPWV) has dropped to less than a fourth of what it was one year ago. This is the same company who had shipped software on more 1.4 billion handsets with 50 device manufacturers (as it still mentions on the ‘about’ page). In its heydays in 2005 Openwave was celebrating 1 billion handsets shipped with its browser and launching MIDAS, a then-visionary service delivery framework, the same strategy that underlines today’s widget adoption by OEMs and operators. The Openwave browser business has been perhaps one of the first victims of the open source phenomenon (alongside Obigo); it was open source development practices which allowed the likes of Apple, Nokia and Google to build next-generation browsers by pooling development costs through the WebKit project – see our seminal article Bye Bye Browser for a full analysis of the story. Since MWC 2008, Openwave has refocused its business on network service management products – including content optimisation, mobile advertising and personalisation. The $30 million that Purple Labs paid for the acquisition is peanuts compared to the valuation of Openwave’s client business circa 2005, considering that browsers typically command $1 per-unit royalties (volume dependent) and Openwave had around 50% market share of browser shipments. [update: For 1Q08, Openwave had reported $11.1 million in revenues from its client business, including software license fees and related engineering services]. Purple Labs also inherits the WAP browser business where WebKit competition is not yet relevant, as well as the MIDAS scripting framework, which can be assumedly be repurposed into an on-device service delivery platform. If this doesn’t sound familiar, on-device platforms for service delivery are what Qt, Silverlight, Java FX Mobile, Qualcomm’s Widgets, Flash Lite and Tamarin are all about. I would assume Purple Labs plans to reuse Openwave technologies to help address the requirements of LiMo Foundation members such as Vodafone and Orange. The open source battleground is consolidating and intensifying. Watch this space! – Andreas [want to know more about open source use and best practices in the mobile industry? Check out our 360 degree workshop on mobile open source.]

[Nokia celebrates Symbian’s 10 year anniversary with an acquisition and a royalty-free, open source roadmap for S60. Research Director Andreas Constantinou distills the ramifications of this major industry announcement] Symbian Foundation in celebration of the company’s anniversary since its foundation in 1998. Exactly ten years later, having shipped 200 million devices across 235 models from the top-5 OEMs and built an ecosystem of 4 million developers, Symbian now undergoing a major transformation process. The facts – Nokia is to acquire Symbian Limited with closure expected by the end of 2008, subject to regulatory approval. On closure, all Symbian employees will become Nokia employees. – Nokia will be spending  EUR 264 million to buy the remaining 52% of Symbian shares from Sony Ericsson, Ericsson, Panasonic, Siemens and most likely Samsung. This is about 2.5x of what Nokia paid to acquire Trolltech and about 20x less than what it paid to acquire Navteq. Symbian makes about GBP177 million a year (calculated as 7% increase over 2006 revenues, in line with 1H07 y-o-y growth), so in Nokia’s share offer, Symbian was only valued at just over two times its annual revenues (!). [Updated: ARCchart has a good analysis of how Symbian’s valuation has remained pretty much constant of the last 5 years despite have shipped its OS on 200 million devices.] – A new, complete operating system is to be formed by merging Symbian OS and S60 in 1H09. Sony Ericsson and Motorola intend to contribute technology from UIQ, while DoCoMo intends to contribute MOAP-S assets (the Japanese flavour of a Symbian-based application platform). – The platform will be managed by a new entity, the Symbian Foundation. The foundation will be formed in 1H09 from Nokia as well as several partner OEMs (Fujitsu, LG, motorola, Samsung, Sony Ericsson), network operators (AT&T, DoCoMo, Orange, T-Mobile, Vodafone), hardware platform and chipset vendors (Broadcom, Ericsson, Freescale,  ST, Texas Instruments), system integrators (Digia, Teleca, Wipro), content providers (EA Mobile) and software vendors (PlusMo). – The Symbian Foundation platform will be available a royalty-free license to all foundation members – starting in 2H09 and to be completed in 1H10 – Platform assets will be available  under an open source license gradually over the next 2 years, with the intent to use the Eclipse Public License (EPL) 1.0. EPL is a weak copyleft license which means that source code modifications/derivatives created must be published if distributed but can be combined with proprietary software. There is also an explicit patent grant in the EPL which implies that IPR-encumbered code from third parties is unlikely to find its way into the Symbian Foundation platform. – The foundation will operate as a meritocracy. Device manufacturers will be eligible for seats based on number of Symbian Foundation platform-based devices shipped, with the other board members selected by election and contribution. – The foundation will provide a single point of access for developer support, offering SDKs, documentation, samples, knowledge base, application signing and tech support – The Symbian Foundation platform will be backwards compatible with Symbian OS 9, S60 3rd Edition. Note that this backwards compatibility warranty isn’t offered by either Android (which may suffer from fragmentation by design) or by LiMo (which effectively standardises middleware and kernel, less so the application environment) – The foundation will be open to all on a low $1,500 yearly fee from 1H09. Being a foundation member gives you rights to access, modify and contribute foundation source code, access meeting minutes and documents, participate in working groups and annual member meetings. What this means for the industry So what does this mean for the mobile industry ? The repercussions of this announcement are rather disruptive: – Nokia will increase its control over Symbian OS, not through ownership, but through the governance model of the Symbian Foundation the sheer weight of its contributions (an estimated 1,000+ Nokia engineers working on the S60+Symbian OS). Previously Nokia was shipping around 70% of Symbian-based devices, but only had just under 50% of ownership. Share of shipments and control (board seats) are now aligned. [update: Nokia gets only one board seat out of five manufacturer seats initially – board seat assignment is volume based and this allocation may change long term. In effect control comes not through board seats, but through the weight of Nokia’s engineering efforts and share of code contributions relative what other OEMs can dedicate to the project.] – This is a logical move for Symbian, which was crippled without control of the UI, application stack and the core OS under the same entity – The current Symbian OS license will be extremely simplified into EPL, a popular weak copyleft license that’s been tried and tested across 10s of commercial projects by the Eclipse Foundation. – Sony Ericsson and Motorola (whatever its fate is) should be adopting S60 and dropping UIQ. That’s a major change, especially for Sony Ericsson who had built 6+ current phone models on UIQ. It’s also a sign for lay offs at UIQ who had been building a team of nearly 400 people in Ronneby and Budapest [update: UIQ will be laying off 200 out of 375 staff] – DoCoMo should be replacing MOAP with S60, again a major undertaking for Fujitsy, Sharp and Mitsubishi who had shipped over 60 models to date on MOAP. – Unlike LiMo, the Symbian Foundation will be controlled by a single player, Nokia, based on the weight of its code contributions its ownership of Symbian and the shipment-based assignment of board seats. This governance model is effectively similar to the Open Handset Alliance which is controlled by Google and the WebKit browser core development, which is owned by Apple (although the underlying mechanisms are quite different) – Windows Mobile is the only licensable OS for mid/high-end phones which doesn’t have a consortium-based contribution model and an open-source-like license (apart from selected parts of the Windows CE kernel source code which are under varying Shared Source licenses). I would expect Microsoft to react in the next quarter by open sourcing more of Windows Mobile – If Android signalled the commoditisation of the mobile operating system business, the Symbian Foundation platform is the nail in the coffin. This will make things rather challenging for many Linux stack vendors (especially those targeting the smartphone market) who charge on a royalty basis. I expect to see revenue models move towards professional services fees from certification, customisation and productisation (see earlier post on open source business models). What triggered the disruption The announcement surprised almost everyone in the mobile industry. It was hard to predict, but is not too hard to rationalise. It may be argued that there are two reasons for Nokia’s acquisition and open source roadmap: Firstly, as a royalty-free, open source licensed OS, Android was too hard to resist for any OEM. Nokia’s acquisition of Symbian is essentially the answer to Android, resonating the same core principles which are a) royalty-free b) open source licensing for pooling costs of maintaining a commoditising OS and c) majority ownership by a single player [Update: Nokia (via Michael Mace’s blog) clarified that they only own one board seat out of 5 OEM seats in the Symbian Foundation. Which implies that Nokia would have comparatively little control over the Symbian Foundation – however in reality Nokia will be dedicating an estimated 1,000+ engineers to the S60+Symbian project, far more than any other OEM can, in effect biasing the roadmap of the OS towards its own agenda. This works in much in the same way that Apple control open source browser project WebKit.] Secondly, Motorola was bleeding heavily in a financial sense and so it would have been keen to sell out its UIQ shares, which Sony Ericsson could not assume the burden of as UIQ was a long way from being profitable. With UIQ out, S60 was the only Symbian-based alternative for Sony Ericsson and a strategic choice in keeping Google from becoming the Android-inside of the mobile industry. First reactions The Nokia+Symbian disruption is now creating three centres of gravity around licensable mobile software: LiMo, Android and the Symbian Foundation (one could also add Qualcomm BREW for specific markets). Besides layoffs at UIQ, the repercussions to the industry will be far-reaching, but the full story will take time to unravel – after all the first Symbian Foundation devices are not expected until 2010. Interesting times indeed! – Andreas [want to know more about open source use and best practices in the mobile industry? Check out our 360 degree workshops.]

[True, there are no textbooks on making money from open source, so how do you go about it? Research Director Andreas Constantinou explains the key revenue models used in mobile open source] Bill Weinberg says. We ‘re delivering our mobile open source workshop on June 12th in Berlin, as part of Informa’s Handsets World conference. There’s still places left, so if you can still sign up if you hurry (check the product datasheet for the agenda). Building the workshop has been a huge learning experience over the past two years – from interviewing tens of insiders involved in mobile open source to developing our understanding of the intricacies of open source with each workshop that we deliver – intricacies such as business models, community governance models, licensing best practices and the hard realities of building a Linux OS. Here I ‘ll explore the revenue models that make mobile open source tick; in otherwords how can a new product strategy make or save money by open source as a key element of the business model. The following slide is taken from our 360 OSS workshop: Revenue models for creating a product from FOSS: 1. Per-unit royalties. Who said open source was free? While the Linux kernel may be accessible to anyone with a web browser (subject to GPL terms), there is a huge leap between a kernel and a fully integrated, optimised, customised, certified and stable operating system. That’s why vendors like Azingo, ALP, Purple Labs and Mizi Research do charge royalties for the Linux-based software stacks. 2. NREs (non-recurring engineering fees) for integration & productisation. Most open source projects are designed to be 90% complete.. but the remaining 10% of pushing a project to ‘shrink-wrap’ product status requires an entity with commercial interests to the deliver the project to the finishing line. As such, system integrators and software vendors such as MontaVista and WindRiver will happily engage in integration and productisation project for Linux-based OSes, in exchange for professional services or NRE fees. 3. Subscriptions for product updates & support. This revenue model is common with dual-licensed open-source products, where the product is branched into a version that’s available under GPL non-commercial terms and one that’s available under commercial non-copyleft terms. Companies like Funambol, Volantis, and Trolltech offer paid-for subscriptions to product updates as a service to customers of the commercial product branch and an incentive to move from trying the GPL branch to to buying/licensing the commercial branch. This revenue model presents a growing opportunity for any system integrator involved in the mobile industry, as both device-side and network-side software products based on open source are becoming increasingly used, while at the same time lacking support contracts and service level agreements (SLAs) that customers have come to rely on. 4. Certification and compliance testing fees. In the case where open-source-based products need to be certified or pass a compliance test – as is the case with Java JSRs – an additional fee may be leveraged for undergoing these tests – as is the case with the TCKs for Sun-owned JSRs, specifically the phoneME MIDP2 implementation. 5. Hardware sales. A more subtle revenue model is that of making the software available for free, but charging for the hardware. Taiwanese manufacturer FIC practices this model for OpenMoko, the distribution which is almost 100% open source. Here customers have a reason to go to FIC to build OpenMoko-based devices for them, so as to leverage from the product know-how and hardware integration expertise that the manufacturer has on OpenMoko. 6. Insurance for product liability and indemnification. This is a straightforward insurance service that software vendors often provide as a premium, which indemnifies or insures the customer of an open-source software product against liabilities. 7. Sharing development costs. Last and certainly not least, open source licensing can be used as a modern approach to shaving costs off software development, by pooling that development effort across multiple industry participants. Companies participating for example in Eclipse, Webkit, Maemo and Android projects seek to share their development costs of a commoditising software base with other peers (even competitors), while leveraging on that base to build essential value add. For anyone attending Handsets World next week in Berlin, you can catch us at the event (Timo, George or myself) and sign up to our mobile open source workshop on Thursday 12 June. – Andreas

We ‘ve just launched a new survey for mobile application developers. If you ‘ve programmed for BREW, S60, UIQ, Android, Windows Mobile, Java, Palm, Linux or Flash Lite, we want to hear what you have to say. The survey spans across a wide range of topics, to gauge how mobile developers feel about IDE features, ease of debugging, emulator glitches, support forums, documentation & sample code available, application portability, pains of going to market and desirability of new features like scripting and POSIX support. We have announced a prize draw for each developer who completes the survey – a $1,000 Amazon voucher, more than enough to get hold of a snazzy new phone to test your applications on! The survey will run for four weeks (closing on Friday 27 June) and the $1,000 winner will be announced on Friday 4 July 2008. Are you are a mobile application developer ? Love or hate your mobile OS ? Have your SAY and a chance to win $1,000. – Andreas

The iPhone has created a revolution and has changed the mobile landscape significantly more than any other handset. Surprisingly, it is not its amazingly user-friendly UI, ultra cool design or the ease of integration with iTunes. It is the revenue model that redefined the business dynamics between handset manufacturers and mobile operators. Other manufacturers are now trying to follow the same path. Apple has been offering the iPhone exclusively through four selected mobile operators in Europe and US, after having negotiated revenue share agreements. Mobile operators have agreed to give much more to a handset manufacturer than they usually do: AT&T has been rumoured to be giving $150-200 back to Apple for each iPhone plus a percentage of monthly revenues from the subscribers that have signed up for an iPhone contract. Orange, O2 and T-Mobile are expected to have signed similar agreements. A back-of-the-envelope calculation yields the following:Addressable market (1Q 2008):153 million usersMarket penetration:3-5%Shipped iPhones (1H 2008):4.02 millionRevenue per iPhone sold:$153iPhone Published revenues (1H 2008):$619m Apple is the only manufacturer that could demand this from mobile operators and get recurring revenues. By doing so, mobile operators have access to high spending customers (in essence, this is a form of negative Channel ARPU – read previous post). So can Apple do the same with the new version of the iPhone? First of all, lets look at how you could, can and will be able to get your hands on an iPhone. How you could get an iPhone From its launch until April 2008 and if you lived in the US, France, UK or Germany, you could walk in an operator retail outlet and sign up for an agreement and get an iPhone. Or you could go to an Apple store, buy an iPhone (the 16GB version was sold in both operator and retail shops for the same price) and activate it through iTunes, where you had to enter a contract to activate your iPhone. How you can get an iPhone From April 2008 until today (May 2008), Apple stores list all iPhones as unavailable (in all countries where it has been previously sold). If you currently want an iPhone, you can only get one from an AT&T store (but you need to be an AT&T customer or sign up). How you will be able to get the iPhone 3G Instead of having exclusive agreements with few operators, Apple has signed blanket deals with operator heavyweights: Vodafone, Orange and several others. In parallel, Apple is expected to be selling the iPhone 3G in retail shops without getting mobile operators involved (yes, this has happened in Germany but the iPhone has been selling there at €1000 – just to conform with legislation). What has changed? Apple may have realised that exclusive deals with mobile operators may provide sustainable high-margin revenues but at the same time this limits the scale of volume shipments due to the smaller number of exclusive agreements possible. The original iPhone revenue model has been disrupted by unlocking and shipping to grey markets (1 million iPhones are reported to have bypassed the activation process) which has deprived Apple of its recurring revenues. Nevertheless, the iPhone ecosystem includes iTunes and even unlocked iPhones can generate revenues for Apple when a user buys content through the online shop. Why has Apple changed its strategy? Apple may have realised that singular, exclusive agreements cannot provide significant revenues. In order to bring in more revenues, higher volumes are necessary and possibly smaller revenue shares in order to lure mobile operators. By doing so, Apple can get access to a much larger addressable market, have a larger market share even if the profit margins are not as high as those of the original iPhone. Apple may have learned its lesson: restricting user choice is not a good thing and users are most likely to find a way to get their hands on an iPhone. A sign of the new strategy is that the iPhone is not available in Apple Stores (where a user can buy it and unlock it) but only in AT&T where you need an agreement with the operator to buy one. Apple may have ran out of stock but I find it quite unlikely that the manufacturer goes out of stock before the mobile operator. Apple may be creating a new market for its new iPhone 3G – the retail environment where anyone can just walk in and buy an iPhone with no strings attached. I suspect that the iPhone 3G will be selling in many markets without a contract – or with a contract and subsidized. Lets assume that Apple will make a modest $50 on each iPhone 3G sold and that iPhone penetration will remain at 3-5% (both are likely to be higher). Total revenue from iPhone sales for 2H 2008-1H 2009 can be estimated as:Addressable market (2Q 2008):575 million usersMarket penetration:3-5%Expected shipments (2H 2008-1H 2009):23 millionRevenue per iPhone 3G sold:$50Estimated iPhone 3G revenues (2H 2008 – 1H 2009):$1.15bn I would argue that the iPhone 3G will cause a bigger revolution in the mobile market: it will expose its design, UI and software to a much larger audience and increase pressure on other OEMs to develop more advanced software and UIs (see the S60 Touch UI, Sony Ericsson XPERIA, Nokia Tube, Philips X800, HTC Diamond). I guess we will all have to wait for WWDC for Steve to pull one of his usual product releases. The iPhone 3G is suspected to be made available shortly after, so I will hold my breath until then. – Dimitris