This a guest post by Tim Ocock who first worked at Symbian when the consortium was created in the summer of 1998. Returning in 2001, he worked in a dual commercial/technical role that necessitated almost unrestricted access to both the ‘shopfloor’ engineering teams and upper tiers of Symbian’s management. He left in 2004 to found Symsource, one of the few dev houses specialising in Symbian still in business today. He is currently Technology Director at Steely Eye Digital Media, a full service digital agency in London’s Soho, leading the webification of mobile and appification of desktop web.
Symbian is the biggest smartphone operating system by market share, the oldest smartphone platform still in use, used by almost every major OEM at one time or another. Yet one could be forgiven for thinking Symbian is dead and buried, with news of layoffs at Nokia, management departures at the Symbian Foundation and rough reviews of the latest flagship N8 device. How does a platform powering 9 million new devices every month have almost no credibility with developers, analysts and press alike? This is the story of one of the most successful failures in tech history.
To this day Symbian benefits from better battery life and lower hardware requirements than its competitors with similar features. Symbian is, arguably, the best phone Operating System there has ever been, and the original standard bearer for the smartphone concept.
But it’s no longer competing to be the best phone OS, or the best smartphone OS, it’s competing to be the best OS for internet phones. When Apple launches a new product, it might look like something you’ve seen before. But they define totally new categories, it just takes a while for everyone else to realise. Call it a superphone or an internet phone, the only platform that actually comes close to offering the same experience as iPhone, is Android. Internet phones include better web browsing, better multimedia, and apps of all shapes and sizes (and by implication ease for developers to make those apps), as well as a better UI to make all that content accessible, even at the expense of traditional phone features. They are something different from smartphones.
Symbian has never been an OS for internet phones. The Symbian definition of a smartphone was a phone with PDA functions. The browser was always a second class citizen, a third party component – Opera by default in the early days, but freely replaced with a licensee’s preferred option. Perhaps where Symbian started slipping in quality was the need, caused by the appearance of iPhone, to compete in the internet phone space too, a space Symbian thought it was in and thought it was winning without realising iPhone was something all together different. With neither enough time nor talent to make a competitive internet phone, that was enough of a distraction to let even those things that Symbian did well, slip too.
And things do take a long time when it comes to Symbian. Long before it was made open source, the platform had a well earned reputation for being hard to program. With its origins in Psion’s EPOC PDA Operating System, its peculiar form of C++ predated the ANSI standards of 1998, and in any case STL, ANSI exceptions and other features of the language in their semi-official forms were not conducive to writing lean software for battery powered PDAs. In their place, constructs such as the notorious Descriptor (like a string, but less useful) and the egregious chore of managing the memory cleanup stack, causes of both much frustration for newcomers to the platform, and Symbian’s code verbosity.
Yet the difficulty of writing good Symbian code was hugely beneficial to Symbian as a business in the early days. For many years, 80% of Symbian’s revenues were earned through consulting for licensees. Most telephony platforms today are off the shelf and Linux supports them all (because who else is going to write your Linux drivers for you if you don’t do it yourself?). Symbian’s licensees on the other hand each had their own proprietary telephony chipsets that needed to be integrated and their own customisations to the platform in mind. There was simply no incentive to provide an out of the box distribution, not until Android came along, enabling former Symbian licensees such as Motorola and SonyEricsson to put together new phones in mere weeks not years. Despite talk of Symbian enabling differentiation, the reality was licensees’ budgets were squandered on hardware porting and making the core platform fit for purpose. Both operators and OEMs alike kidded themselves that they wanted a platform they could differentiate on. In reality, Android and now Windows Phone 7 proved that to be mere lip service, that they really needed someone who knew software to do it for them.
It’s tempting to conclude then that Symbian simply chose to focus on short term consulting revenue (or had no choice to avoid going cap in hand to licensees more often), leaving engineering to deliver a half finished product. The appointment at that time of the consulting division’s accountant to head that department supports this argument. In theory changes made by the consulting teams were supposed to be folded back into the platform so it would become closer to a finished product over time. This almost never happened. Symbian attempted several times in later years, as telephony hardware became less bespoke, to address the problem, setting up teams specifically to create fully integrated distributions on various reference platforms, but usually done half-heartedly, outside core engineering and without enough resources. The leadership did not have the will to make it work.
But the consulting business was if anything just a nice side effect. The real root of the development problem with Symbian was that the APIs and tools roadmap were driven by the needs of kernel engineers and system integrators. It was not unusual to hear it spoken by senior staff that there would never be a market for after-market apps and games so why support third party developers? “Easy API” projects, to make phonecalls or send messages in less than 20 lines of code, were started and never finished. The Psion OPL language was briefly resurrected as it’s BASIC like syntax had led to a thriving third party apps ecosystem on the original Series 5. A suggestion to extend Java beyond the usability constraints and limited API of J2ME was shot down without a second thought. Each died quickly. Symbian’s engineering department forbidden to put resources on activities not authorised by product management. In turn, unlike at Palm, or Android today, there was no product manager representing the needs of third party developers.
More recently, the addition of standard C and C++ support, as well as the web runtime and even Python did at least get a dedicated ‘runtimes’ product manager. But even then, these were second class citizens on the platform, incomplete, poorly supported with tools, examples and documentation and most significantly not consistently available across all current devices. Contrast that with Android where Linux drives the core phone technology, everything else, including the application suite, is developed for the Java runtime. iPhone too uses FreeBSD at its lowest level but apps, including Apple’s, use the Cocoa developer-friendly APIs. Palm’s WebOS uses Linux for the phone and their browser based runtime for everything else.
Qt finally addresses this need but nearly 3 years after acquisition it is still unfinished. For Nokia now, the whole application suite for Symbian and for Meego needs to be migrated to Qt as quickly as possible because this will drive the discovery of new API requirements and improvements to the tools. Nokia has hundreds of developers working on Ovi Maps, successfully commoditising the SatNav market in a short space of time. But Ovi Maps is done. Those developers should be flat out on building out the whole application stack in Qt. It’s time that Qt was no longer a thin portability layer but a rich and powerful API for application development in its own right.
As for the user interface, work at Symbian for any length of time and you would have heard that “Symbian doesn’t do UIs”. So it’s no wonder every pundit has some witty comment to make about the current UI. But it wasn’t always that way. The Psion Series 5 won design awards and many remember the P900 fondly, while the UIs of Japanese Symbian devices made European phones look positively prehistoric until the iPhone came along.
By 2001, Symbian had recruited a world class design team, including experts from Apple, Psion, Ericsson and many other talented mobile UX designers. Symbian planned to build out 3 Device Family Reference Designs – Pearl for candybar smartphones, Quartz for touch screen PDA phones, and Crystal for keyboard equipped communicators. Technologies such as universal messaging (AKA visual voicemail), voice search, location sharing, augmented reality and context sensitive widgets were running in that lab years before other platforms
popularised them.
Yet having assembled this team, Symbian was suddenly forced by its owners to abandon the notion of providing DFRDs at all and adopt the “Symbian doesn’t do UIs” policy. Nokia already controlled Crystal anyway. The embryonic Pearl was abandoned (it did not, as many suppose, evolve into S60). Quartz was spun off formally as UIQ. The UI design team were mostly laid off. Internally, Symbian used the old Series 5 UI for testing with Nokia later merging this together with Crystal to make the aborted S90 touch screen variant.
Of course, with the line between S60 and Symbian so blurred, as far as the user is concerned the user experience is a Symbian attribute and again the difficulty of development can take some of the blame. S60 in particular was written in a hurry by developers new to Symbian for the Nokia 7650 and its UI API, Averell, did not adhere to the elegant design design followed by Quartz and Crystal. In the interests of backwards compatibility, bad design decisions were never fixed preventing developers from having the time to iterate and refine their UI designs or even just to concentrate on the value adding features of their apps instead of fighting the platform.
So, a UI twisted into knots resulting from bad management and technical decisions made years ago and at the root of it all a stubborn refusal to meet the needs of developers because Symbian’s idiosyncracy created customer lock-in and generated short term revenues, and to its credit, also an OS that didn’t need 1GHz processors and 512MB of RAM.
But how does Nokia fit into all this? They were often said to be pulling the strings behind the scenes. When they finally bought Symbian it was because the threshold at which it was cheaper to buy it outright rather than continue to pay license fees had been met. The open sourcing of Symbian, it could be speculated, simply made it more palatable for the other licensee-shareholders and for regulators who had so carefully considered the creation of Symbian by, at the time, some of the world’s most competitive companies. It might have made sense then since many open source companies make money through customisation and support for Symbian’s consulting division to be part of the Foundation, to take the platform in new directions – set top boxes, in-car computers. But Nokia didn’t allow the Foundation to employ any developers itself and the consulting division spent their last months cross-training onto Android.
It wasn’t Nokia’s larger share of the original Symbian that gave them so much influence either. It was their spending power. Nokia outspent the other licensees all together by something like 4 to 1 in terms of license fees for volumes sold and in terms of consulting. Of course, it wasn’t Nokia’s fault their competitors weren’t building successful devices. But it influenced the behaviour and decisions made within Symbian all the time. It was after all a business and looking after your biggest customer is good business sense.
Symbian was supposed to be an equally balanced organisation. Licensees generally played by the rules, more afraid of antitrust and losing their place in the value chain to Microsoft. Except for one. Nokia were in a 5 way game of Chess that the other players didn’t know they were supposed to be playing.
Nokia blocked inclusion of a standard camera API in the Symbian product roadmap claiming it would be years before anyone built a cameraphone, weeks before the launch of the 7650, the first GSM cameraphone. They insisted on Symbian’s adoption of Nokia controlled components, the TCP/IP networking stack, the WiFi, Location services, SIP stack for VoIP calling, and probably the worst example of this sort of tactical interference occurred with Symbian’s move to support CDMA ‘out of the box’. With CDMA technology a defacto monopoly for Qualcomm, the obvious solution would be to build the reference software stack on Qualcomm hardware. But when your biggest customer was in the middle of suing and being sued by them, it’s not so easy. Symbian went to great lengths to build in support for CDMA, even setting up a secret team in North America but with their hands tied they had to use Nokia CDMA hardware for whom the only customer was Nokia. Nokia, in turn, proceeded to cancel several CDMA devices late in the development cycle during their frequent retreats from North America.
Symbian’s unique position caught between so many competitors made it difficult to appoint experienced leaders who had not already worked for one of the shareholders who could get people working for a common goal. As Symbian grew, the visionary creators of the platform were sidelined as ‘grown-up’ industry veterans were brought in to supervise the rapid expansion of the organisation. Thus did Symbian become an organisation in which anyone could say no but no one but Nokia could say yes.
So to the future. Despite comments from their management lately committing to the open source Symbian Foundation, Nokia already maintain their own internal Symbian codeline, occasionally releasing changes to the public mainline. With no other licensees (the Japanese also forked years ago), there is no reason to keep the Foundation going. New CEO Tim Holbrow is a great guy known to everyone who ever worked at Symbian, not one of whom would have a bad word to say about him, but there’s only ever one reason you put the finance guy in charge, while a skeleton crew is all that would be required to distribute the recently won EU funding to ecosystem suppliers.
Other licensees will never return to the platform unless a huge effort is made to provide a totally off the shelf, ready to run build of the platform supporting all popular hardware platforms. It’s almost certainly too late for that now.
Qt, however, is the right strategy for the application suite and for third party developers, it just needs to be finished and soon! It needs to be core to the Nokia software operation not a fringe activity.
Analysts are starting to understand that Symbian is a platform only for phones not for internet phones. Nokia needs to continue to educate the market to remove the risk of perception becoming fact. If they do not, they remain a company with tremendous assets but depressed market cap based almost purely on perception, and therefore a prime takeover target.
The problem for Symbian itself is that Nokia already has another phone OS, the increasingly creaky NOS/S40. The indirect costs of maintaining two ‘low end’ platforms easily outweigh a couple of dollars on the BOM for the ever so slightly lower hardware requirements of S40 and that difference is only going to get slimmer. Nokia needs to ditch S40 now even though that seems like short term suicide when it’s propping up the market share. But 38% market share is not worth having if that’s the 38% of the market who buy phones which only have a 1% profit margin.
The lesson for Meego, and other pretenders to the crown is, perhaps to look after your developers with useful APIs and powerful tools both inside and outside of your organisation. Find the right balance between efficiency and ease of development. Look after all of your developers and your developers will look after you.
Tim would like to thank @dw2 for giving him his big break into the industry.