[The LiMo Foundation has been one of the driving forces of mobile Linux. Andreas Constantinou goes behind the scenes to find out why LiMo is still catching up with Google and Nokia and why LiMo’s effectiveness will be limited – unless it goes back to the drawing board]
The launch of the LiMo Foundation has been one of the most important and momentous landmarks in the history of the mobile industry. It was launched by the cr̬me de la cr̬me of the handset OEMs and network operators with a Linux agenda, and marked the promotion of Linux into the commercial arena of mobile operating systems. It also seemed to not just preach, but also practice openness with a publically available 200-page documentation on its governance model. Many believed that this industry consortium would make a real difference Рincluding myself.
But that was January 2007. Things are somewhat different in 2009. Today LiMo has only achieved a minimal software denominator across its 33 ‘LiMo-compliant’ handsets, while market-leader S60 is opening up their roadmap and codebase and Android OS devices are coming out from from HTC, Dell, Huawei, Garmin, Fujitsu, Archos, China Mobile and O2.
LiMo has amassed impressive political capital, but seems to have done little in advancing mobile Linux operating systems (or fending off the Linux volume decline). At the same time, the battle for software control has moved from the middleware layer (where LiMo focuses), up to the application and service delivery layer where Android and Symbian Foundation focus.
LiMo needs to go back to the drawing board.
The foundations of LiMo
From six founding members in early 2007 (Motorola, NEC, Panasonic, Samsung, DoCoMo and Vodafone) the LiMo foundation has now grown to over 50 members. The annual fees run at $550K for board members, $275K for non-board members and $40K for associate members. The two higher price tiers allow members to ship devices with LiMo code. LiMo is thus handsomely funded to the tune of over $7M annually.
The Foundation is working on ‘commoditising’ a set of middleware software components which have been contributed by its members; the first release (R1) includes a range of components, including telephony, networking, certificate manager, media manager, ODBC drivers, HTTP/WTCP components, telephony framework, messaging framework, app launcher, GTK+ and window manager. The sum of R1 modules form 3-5% of the software that goes into a mobile handset, but LiMo compliance applies (for now) to a much smaller subset of R1.
LiMo’s common code is a set of modules being built through member contributions. This gives LiMo an advantage in selecting among several competing contributions (in some cases, up to 4-5 contributions) for each module. Indeed LiMo claims to have built a target library of important middleware building blocks through member contributions.
The common code is contributed under LiMo’s Foundation Public License and is royalty-free. The additional (differentiated) modules are can be contributed under common open source licenses or under a RAND-type (Reasonable and Non Discriminatory) license.
LiMo has garnered an impressive industry backing in its two first years. Besides the global reach of its OEM and operator/carrier members (from Japan to Europe, North America and LatAm), LiMo has subsumed the LiPS foundation and its key members (most notably Orange and ACCESS), and formed ties with OMTP’s BONDI initiative. In short, LiMo Foundation has built an impressive amount of political capital and committed resources within the short space of two years. Indeed one of the main benefits of LiMo reported by software vendor members is the visibility and awareness they gain thanks to LiMo’s industry efforts and the access to operator key execs, which would otherwise require 6+ months of business development efforts.
One of LiMo’s key differentiators is the IP safe harbour that it provides; its members agree to not assert patent claims on common code that is distributed among members or commercially distributed to non-members. According to LiMo, the patent holders of the Foundation collectively own more than 300,000 patents.
LiMo challenges and plans
2008 has been a year of teething problems for LiMo:
– LiMo Foundation Chairman and architect Greg Besio left Motorola while LiMo was still gathering momentum.
– Board member agendas have been polarised and as a result decisions have been taking too long to make
– R1 has provided a very basic platform, on top of which OEMs have had to in-source many additional components which delayed the time-to-market.
– We understand that LiMo compliance has been at a module-by-module-level; the 33 LiMo-compliant handsets feature a small subset of release 1 (R1) modules referred to as type 1 (T1).
– The barrier for third party contributions has been high, with $40K annual membership fees.
– Software vendors like ACCESS, PurpleLabs (now Myriad) and Azingo who have been champions within LiMo have all been delayed to market by at least 12 months. Based on discussions with software vendors, we believe that a significant part of that delay is attributable to their activities within LiMo, which typically involve following operators’ moving targets in baking the latest features (flexible UI, Flash Lite, WebKit, touchscreens) into the OS.
This has been a crucial setback to the Linux commercial community as a whole, while Android and Symbian Foundation have already caught up on ‘openness’ and devices launched to market.
Fortunately LiMo is making some sincere efforts to propel itself back into center-stage.
– 11 operators have made commitments to specify and deploy LiMo-compliant handsets.
– LiMo hired an Open Source manager in 4Q08 to realise LiMo’s commitment to contributing back to open source communities;
– moving forward LiMo will also be lowering the minimum participation fees (currently at a high $40K annually, compared to the $1,500 of the Symbian Foundation).
– The release 2 (R2) of the common code is intended to include many more components, such IMS, location, PIM and DRM components. The minimum compliance threshold should be increasing as well.
R2 is an intense multi-party effort; code is being contributed by at least 10 members. Integration services are provided exclusively by WindRiver, while compliance testing and certification are provided by WindRiver and IEEE/ISTO, an independent certification agency. We expect the first devices that are fully R2 compliant to launch from 1H10 onwards.
Why LiMo needs to go back to the drawing board
LiMo is making earnest efforts to revitalise the mobile Linux industry. However, I believe the issue lies much closer to LiMo’s core focus. The Foundation has been created in order to accelerate commoditisation of the middleware (core building blocks) of Linux-based OSes.
And here exists the following paradox; on one hand there are economies of scale to be gained by agreeing on a common set of middleware across Linux-based phones. On the other hand, middleware has little (if any) sale value; the control points (and sale value) has moved up to the service layer and application environment layer (read: Android and Qt). OEM differentiation rarely comes from the middleware layer, but always comes from the application layer.
Moreover, network operators may be overpromising their allegiance LiMo, but when it comes to buying LiMo handsets, they will only be doing so if these handsets:
a) come with a consumer-appealing industrial and UI design
b) support the latest operator services and
c) carry no recall risks, as often is the case with maturing software.
These purchase criteria are particularly important, as tier-1 operators are the primary drivers of the LiMo ecosystem and its commercial significance. No matter how promising are the pledges of operators like Orange and Vodafone to support LiMo handsets, we have seen such pledges face the grim reality time and time again (e.g. see past cases with SavaJe and ACCESS).
Last but not least, middleware requires hundreds of man-years to optimise, integrate and customise to each hardware platform as well as processor and memory architectures. It is not something that needs transparency or more source code. It needs more expertise. For the same reason, even if Symbian source code was widely available on introduction, it would still take a handset OEM more than 3 years to be able to produce handsets fast enough and reliably enough.
The issue with LiMo is that it focuses on standardising middleware and not the service delivery layer, unlike Android, Qt and WebKit open source efforts. While LiMo may claim that its members should be allowed to differentiate on top of the middleware, here we have another classic case of an industry consortium outpaced by technology adoption; in the space of the last three years (2006-2009), the value line has moved above the application environment and service delivery layer, most visibly with the adoption of Android and Qt application environments as well as the WebKit browser core.
I would argue that if LiMo wants to be making an impact on tomorrow’s handsets, it needs to refocus its ‘standardisation’ efforts on the browser and service delivery layer; for example, accelerating the development of WebKit-based browsers and browser-based applications (much like WebOS has showed is possible). WebKit is one of the frontiers of the mobile value line (therefore a non-differentiating feature) and can become a common substrate for the delivery of next-gen operator services, with the help of LiMo and its operator backing.
Moreover, by focusing on the service delivery and application development layers, LiMo would effectively reduce the cost and time-to-market for full application suites (what Qtopia struggled with and what Android has addressed so elegantly).
I was a huge fan of LiMo on launch, and I hope I’ll continue to be. But, for its own sake, LiMo needs to go back to the drawing board.
Comments welcome as always.
– Andreas
twitter: @andreascon
(while on the topic of market insights, make sure to check out our hugely successful Mobile Megatrends 2009 series below.)
[slideshare id=1071449&doc=mobilemegatrends2009visionmobilenew-090226011714-phpapp01]
It is no secret that voice ARPU has been on a downhill slope for a very long time; per-user voice revenues have dropping at an alarming 5% annually over the last 5 years. Yet operators have been hoping in vain that data services will over-compensate for this decline. They haven’t.
As a software vendor or handset manufacturer, your sourcing process starts with choosing your suppliers. More and more often this choice involves use of Open Source Software (OSS):
