Open Source Symbian and the Inescapable Truth of Product Lifecycles

The announcement one year ago
that Symbian will be open sourced under a license free platform in
1HCY10 was heard around the world. If we are to believe game theory,
the motivations behind this move are not a non-zero sum game but rather
one of rational choice by its major stakeholders. But what does Open
Source Symbian really mean for all of the players involved?  Recent press commentary on the announcement might
suggest that the leading ascendant contenders for the unifying Open
Source platform – Android, Moblin, and LiMo – will somehow be
cannibalized by a resurgent Symbian platform that is "free."

Indeed,
in the mobile industry, invariably, there is always that big
announcement that gains mindshare from industry pundits who can see the
future (I recall WCDMA handset launches enjoyed similar attention
in 2000). However I believe the opposite is true in the case of
Symbian, that its demise as it nears an end to a natural product
lifecycle will only be accelerated when it is made available under an
open source license next year.

Here are 7 reasons why I believe this to be the case:

(1) Shifting of costs to device makers: A recent tour of OxMs
in Japan pointed to the possibility that, although Symbian will not
charge royalties per unit, development, support, upgrade, and
maintenance costs in the Symbian program will likely be shifted to each
respective manufacturer as the Symbian Foundation finds that funding a
staff of hundreds of Symbian engineers is unlikely to be offset by
membership fees. Indeed, by all indications an Open Source Symbian will
require considerably more sweat equity and costly out-sourcing by OxMs
to keep the platform viable in the face of accelerated competition and
technology change. This means that droves of device makers depending on
Symbian today will either need to pay more to play or consider
investment in alternative open source stacks.  Importantly these costs
are not variable license fees but hard and fast personnel costs that
are independent of shipped volumes.

(2) Developers are flocking elsewhere: Although the best of
its generation, developers still generally consider Symbian an
inherently buggy software, and there is no reason to believe that this
will change with an open source release of the platform.  Indeed, with
the recognized limitations in the Symbian OS, developers are choosing
other open source platforms three times as often.
Ultimately, Symbian must be able to attract more developers via a new
open platform or it will continue to dramatically lag communities like
Linux, Apple, and RIM. This dilemma may be even more important for the
Symbian Foundation to solve – there are many competitors luring (and
funding) developers to new mobile platforms, and innovation driving
differentiation is the key to an operator's embrace.

(3) No signs of a future proof architecture: If we move
beyond smartphones, Symbian simply is not architected for next
generation larger screen mobile devices and runs neither easier
nor more cheaply. To make matters more complicated, Symbian will
attempt combine MOAP, S60 and UIQ to create an all-in-one platform
based on old foundational technology, whereas true open source
platforms were architected as service delivery platforms from the
start. Indeed, bridging the gap between Symbian today and Symbian
tomorrow will require the kind of careful architectural planning that
is rare in a new open source consortium that is based on a
fundamentally non-open platform, and mitigating the risk of migrating
to a platform that substantially contains legacy code while hopefully
enabling new services is anyone's guess. Any claim to the contrary is
pure Symbian Foundation defensive marketing fluff.  

(4) Symbian is on a decreasing volume precipice.  Although
Open Source volumes are significantly smaller than that of Symbian, the
unit shipment momentum around foundational Linux platforms appears to
be the bane of Symbian. In addition to reporting a 12% year-on-year
decrease in volumes in the quarter the Symbian Foundation was
established, Symbian now shows a whopping 15 percentage points of lost
market share versus other high-end OSs. This is strongly reminiscent of
Microsoft’s recent announcement that Microsoft expects fewer Windows Mobile-powered handsets.
I am not suggesting "game over" for Symbian, which is still the market
share leader, but these are indicative numbers. Added to the dip in
shipment growth, turnover has been falling rapidly and I believe the
highly competitive market will make it more difficult for Symbian’s
owner to indefinitely subsidize the Symbian Foundation for
other  manufacturing players who will have access to source code under
a zero royalty license.

(5) Barriers to Symbian roadmap assurance for all members: it
remains to be seen if the Symbian Foundation platform will offer a
roadmap that allows for continued feature convergence, service
delivery, innovation, and differentiation. Indeed, the cost of keeping
a stack and platform current with ever-changing technology standards is
immense, and it is unclear who will invest in this process in the Open
Source Symbian platform. At the same time, the question of who
ultimately will control the Symbian roadmap – with one owner
essentially contributing most of the engineers to the new Foundation –
is a valid one that underscores the fact that this Tier 0 ships circa
70% of Symbian phones. This could result in a Microsoft mobile philosophy of "you get what we ship you" and translate into limited maneuvering room for customization and differentiation for the rest of
the crowd.

(6) How long will Helsinki hang on to Symbian? Rumors that Qt
technology from the Trolltech acquisition is being architected in as
part of a post-Symbian new platform generation (with Maemo as the testing vehicle which gave the company its first grounding in Linux)
are likely far fetched, especially given the enormous new role Ovi and
other initiatives will play in any future software architecture. Yet
the fact that technology from the former Trolltech was excluded from
the Symbian Foundation might suggest that Symbian is not the future
software platform to solve the truly hard problems, and that value
creation is going on somewhere else in Helsinki. Indeed, a roadmap
where the S40 platform (proprietary technology) serves the feature
phone market (with advanced features creaping down into devices such as
the 6260 Slide) and where current generation smartphone
software (Symbian) is replaced by a next generation is almost certainly
in the works.

(7) The devil in the Symbian Foundation governance details:
Finally, there remain a thicket of open questions around the operation
of the Symbian Foundation and open source, not the least of which is
what the exact support burden manufacturers will need to take on in
both creating new designs and supporting legacy platforms using
Symbian. Also, questions such as how will co-development take place
when most Symbian engineers belong to one owner will likely accelerate
manufacturing gravitation to alternative open source platforms.  Also,
as indicated above, quetions about how to align on a common Symbian
roadmap in the brave new world of Open Source, who ultimately owns
contributed intellectual property, how will code be contributed, and
who manages Open Source governance on behalf of the device maker are
ones that device makers are keenly waiting to be answered.

While I applaud the continued commitment to the open source
movement, it is obvious that the pressure from the success of other
proprietary handsets from Apple and RIM and open source models like OHA
's Android platform, Moblin and LiMo must weigh significantly to have a
market leader turn its leading software product over to an open
community.  Contrary to the Symbian Foundation’s marketing
campaign, however, I for one, do not think that the open sourcing of
Symbian will encourage increased adoption of the platform as customers
and partners seek out fresh options for differentiation and support. 
If history is a guide, I am betting that the market will migrate to
new, sooner rather than later.