Is Symbian dead? And if so, who killed it?

"We should declare victory and go home."
--Apocryphal quote attributed to George David Aiken

I hesitate to write anything about Symbian, because it's a great way to get branded a parochial American, or an Apple fanboi, or a "member of the US-protectionistic mobs braying for blood," to paraphrase a comment from a tech discussion forum in the UK this month.

But there's been a huge cloud of smoke and very little light in the recent online discussions of the changes at Symbian. Is Symbian dead? Is it stronger than ever? What's really going on? I wanted to see if I could make sense of the announcements. Besides, there are some important lessons from the Symbian experience, and I'd like to call those out.

Here's my take on what's happened: The business entity called Symbian was originally designed to prevent Microsoft from controlling the mobile OS standard, without having Symbian itself seize control over the mobile phone companies that funded it. In that task it succeeded. However, as a company run by a consortium, Symbian's governance was politicized and inefficient. This left Symbian woefully unequipped to compete with Apple and Google. A different approach was needed, and Nokia's new management has finally come to terms with that. As a result, Symbian as an organization is now defunct, and Symbian as an OS is becoming background infrastructure that has little relevance to the mobile platform wars.


To explain why I reached that conclusion, I have to start with a quick refresher on Symbian's history, for readers who haven't been following it closely...

There are two things named Symbian: Symbian the company and Symbian the OS. Some of the confusion this month was caused by people mixing up the two things. Symbian OS began as EPOC, the operating system used in Psion's handheld devices. EPOC was spun out of Psion in 1998 as a separate company called Symbian, co-owned by Psion and most of the leading mobile phone companies of the day, led by Nokia. The idea was that all of them would use the renamed Symbian OS in their smartphones, enabling them to put up a unified front against Microsoft, which they feared would rule the smartphone market.

Over time Nokia came to be the dominant manufacturer of Symbian OS phones outside of Japan, largely (in my opinion) because the Symbian phones made by other mobile phone companies didn't sell well. Eventually the other mobile phone companies no longer wanted to pay for a joint venture that was mostly just supplying software to Nokia. Linux was gaining momentum as a free, open source mobile OS, so the Symbian partners, led by Nokia, decided in 2008 to convert Symbian OS into an open source project. Nokia hired most of the Symbian engineers, and gave away their code through the foundation.

Symbian the company was replaced by the Symbian Foundation, a nonprofit tasked with managing the open source process and encouraging other companies to sign up to use the software. The idea was that Nokia, the other Symbian licensees, and a growing hoard of academics and developers would work on various parts of the OS, contributing back their modified code to the shared base. The move to open source kept some level of engagement from several other mobile phone companies, most notably Samsung and SonyEricsson.

But both companies continued to have poor sales for their Symbian phones, and this fall they announced that they had no further plans to use the OS. That left DoCoMo in Japan as the only other major user of Symbian. Nokia was stuck with an open source foundation that mostly just supplied its own software back to it. That wasn't going to be viable. So earlier this month, Nokia and Symbian announced three significant changes:

--The Symbian Foundation is being dramatically scaled back to "a legal entity responsible for licensing software and other intellectual property, such as the Symbian trademark." (link). In other words, it's just a shell. Symbian is now truly Nokia's OS. Nokia will plan, develop, and manage the Symbian code base, and distribute it directly to anyone who still wants it (presumably DoCoMo). You can read a biting commentary on the changes here.

--At the same time, Nokia reaffirmed an announcement it made in October that it is focusing all of its application development support on the Qt software layer that it purchased several years ago (link). Qt will now apparently be Nokia's one and only application layer, deployed on both Symbian and the upcoming MeeGo OS being codeveloped with Intel (link).

--The EU is putting 11 million Euros into a new organization, called Symbeose (which stands for "Symbian – the Embedded Operating System for Europe"), which will help fund the development of advanced Symbian OS features, including asymmetric multiprocessing, dev tools, memory management, image processing, video acceleration, speech to text, mobile payment, multimedia formats, and embedded systems beyond mobile. There are two semi-conflicting explanations of what Symbeose is all about. Some people say it's aimed at turning Symbian into an embedded OS that can run in all sorts of devices (why Europe needs that instead of Linux is unclear to me, but you can hear some discussion of the wrongheaded North American mobile paradigm here). Others say the intent is to resurrect Symbian OS as a smartphone OS used by companies other than Nokia. In a presentation, Symbian Foundation said the investment is intended to "combat mobile device and service homogeneity exemplified by Android and iOS" (link). Apparently taxpayer support is needed because Nokia isn't willing to pay for some infrastructure needed by other phone companies (link). A Symbian Foundation employee explained: "I would say that the main focus of the developments will be advancing existing, as well as building new tools and services relevant for smartphone manufacturing at the beginning of the manufacturing process. We want to make it easier for any manufacturer to take the Symbian codebase and develop new smartphones" (link).


What it means

Symbian isn't dead. It's just irrelevant. After the announcement, Nokia professed its strong support for Symbian OS (link). Nokia has no choice but to support the OS because it's built into the whole middle to top end of the Nokia product line. Given all of the legacy Nokia code written in Symbian OS, the Symbian-based phones still in development, and all of the Nokia development teams who are used to working in Symbian, it would probably take years to flush all of the Symbian code out of Nokia's products even if it wanted to. Symbian at Nokia is kind of like Cobol at IBM -- you're going to go on tasting that particular meal for a long time to come.

But the decision to focus on Qt for applications means that Symbian OS is effectively no longer an app development platform. It's embedded software; the background plumbing that powers Nokia's smartphones (and maybe other embedded systems, if the EU has its way). There's nothing wrong with that, but it makes Symbian irrelevant to most of the folks who talk about mobile technologies online. We don't spend much time online debating which OS kernel a device should use, and that's now the world Symbian lives in. The real competition for developer and smartphone user loyalty in most of the world is now Qt vs. iOS, Android, and RIM. Plus that Windows thing.


What it means for Nokia: Hope. Nokia's app recruitment efforts have been hamstrung for years by what I think was an incoherent software platform story. What should developers write their software on? Symbian native, S60, Silverlight, Qt, Adobe Air, Java...at one time or another Nokia romanced just about every mobile platform on the market. Nokia said that was a strength, but actually it was a sign of indecision and internal conflict. Developers crave predictability; they want to know that the platform they choose today will still be supported five years from now. By flitting from platform to platform like a butterfly, Nokia sent the unintentional signal that developing for it was dangerous.

Many developers did support Nokia anyway, especially in places where the Nokia brand and market share were so dominant that the decision was a no-brainer. But I think their loyalty did a disservice to Nokia in some ways, because it blinded the company to the shortcomings in its developer proposition. When Nokia had trouble recruiting developers in places like Silicon Valley, it seemed to think they were just biased against it. Time and again, I attended Nokia developer events in California where Nokia concentrated on telling people how big its installed base was, and showing off its latest hero device (N97, anyone?). I can see Nokia's logic -- after all, developers in Europe seemed happy. But the reality was that developers in Europe had given it the benefit of the doubt, despite its poor overall proposition.

So the decision to focus on Qt (pronounced "cute," get used to it) is a positive one, in my opinion. This is one of those cases where making any decision is better than the status quo. Qt isn't perfect, but if all of Nokia aligns behind it, any problems in it can be ironed out.

Unfortunately for Nokia, this is just the beginning of the changes it needs to make, rather than the end. Nokia's Qt development tools still reportedly need work (link). And app developers don't just need a coherent technical story, they also need a coherent business story. How do they make money? Although Nokia sells a huge number of Symbian-based smartphones, most of their users seem blissfully unaware that they can add applications. That's why Nokia has a much smaller base of applications than iPhone, even though its customer base is far larger.

To attract more developers, Nokia will need to do a lot of marketing, both in advertising and on the device, to make sure Qt users know they can get apps, and are stimulated to try them out. Nokia has the resources to do this, but once again it'll need consistent and well coordinated execution to make it happen, something that the company has failed to deliver in the past. (For example, spamming people with SMS messages telling them to try other features is probably not the right approach (link).)

To give you an idea of how much ground Nokia needs to make up, Apple iOS has 60 million users and 225,000 applications, a ratio of about 3.75 applications per thousand users. Android is close behind, with 3.5 apps per thousand users. In contrast, Symbian has 390 million users and 7,000 native apps, a ratio of about .02 apps per thousand users. (link). Yes, I know, there are additional Nokia apps written in Java, but that kind of proves the point that Symbian is plumbing rather than a platform.

All of these changes need to be carried out against a backdrop of cost cutting, as Nokia brings its expenses in line with its revenues. One of these days when I get the time I'll write more about Nokia's overall situation, but for now suffice it to say that Nokia is working off the after-effects of several years of growing expenses while revenue was stagnant. Nokia's circumstances aren't quite as bad as the California state budget (if you are in Europe, think Greece), but it's ugly enough to distract from all of the other things the company needs to fix.


What it means for developers: Wait. First, the bad news: The switch to Qt means that current Symbian OS developers who aren't already using Qt will need to rewrite their applications. This is the latest in a series of rewrites that Nokia and Symbian have forced on developers over the years. If they had more developers it probably would be causing a big ruckus right now. The fact that you don't hear a lot of screaming speaks volumes.

The good news is that Nokia may be getting its act together for developers at last. But if I were working on a mobile application today...wait a minute, I am working on a mobile application today. So here's what I'm doing about Nokia: I'm waiting. If Nokia creates a great business proposition for developers and sticks to it, our team would be delighted to support Qt aggressively. Who wouldn't want to sell to a base of 400 million users? But given Nokia's history of whipsawing its developers, we won't take anything for granted. In particular, we want to see if Qt is actually the exclusive development platform for MeeGo, rather than just a secondary option. You've got to show us the consistency, Nokia.


Oh, and ignore Symbeose. I don't know exactly how the Symbeose initiative got started, but to me it looks like the Symbian Foundation lobbied for it for a long time, prior to the recent changes in the Foundation. For the old Foundation, Symbeose made sense, because it was a clever way for a nonprofit to get some OS development done in areas that Nokia didn't care about. But with the Foundation mostly gone, Nokia has no incentive to turn Symbian into a general embedded OS, and in fact it says MeeGo is its OS for use in non-phones. In that situation, I can't picture a lot of other companies committing to build Symbian OS into their products.


Lessons from the Symbian Foundation's demise

I'm seeing a lot of interesting rationalization online about Symbian's fate. For example, Tim Ocock, a former Symbian employee, wrote a fantastic post (link) in which he argues that Symbian was very successful as an OS for phones with PDA features, but was never designed for running browsers and lots of applications. That's a pretty shocking statement, considering how many times I heard Symbian advocates boast about the sophistication of their modern, general purpose OS compared to clunky old PDA-centric Palm OS. Remember, this is a company that until very recently was bragging about its superior implementation of symmetric multiprocessing (link), hardly something you need for a PDA.

But I think Tim is dead-on in most of his analysis. He did a great job of detailing the technical and attitudinal flaws within Symbian itself, so I won't bother repeating them here. Instead, I want to talk about the flaws in Symbian's governance.

Did Symbian fail? The companies that founded Symbian had two goals in mind: to prevent Microsoft from dominating the market for smartphone software, and to prevent Symbian itself from becoming a power that could dictate to the phone companies that funded it. As a result, Symbian's governance structure was designed with a complex system of checks and balances that wouldn't apply to a normal company. To make major decisions, Symbian had to negotiate a consensus among its owners the mobile phone companies, who understood little about the management of a mobile platform and were suspicious of each other and of Symbian itself.

This bureaucratic, highly politicized oversight process repeatedly forced Symbian into blind alleys, and prevented it from doing things that a "normal" OS company would take for granted. When Symbian was founded, there was talk of an eventual IPO. The prospect of an IPO is an important recruitment tool -- it lets you use stock to hire ambitious engineers and managers. But the idea was eventually shot down by the owners; it would have made Symbian too independent.

Crippled by design. Once the threat from Microsoft receded, the owners' second goal for Symbian -- preventing it from competing with them -- seemed to dominate their treatment of Symbian. I'm not saying there was some central evil plan to hamstring Symbian; there wasn't. But everything the company planned to do had to be approved by the handset companies, and on a case by case basis they vetoed the things that sounded threatening to them. Over time, this forced Symbian away from initiatives and features that would cause users and developers to be loyal to the OS rather than the handset.

So Symbian didn't create an app store, and Symbian's developer relations were very confused because Nokia wanted to do a lot of that itself. But the most egregious example was user interface, which Symbian worked on from time to time, but was eventually forced out of by its owners. When I was at Palm, the Symbian project I feared most was "Quartz," the effort to create an icon-driven touchscreen UI for Symbian. Quartz looked very nice, and if it had survived Symbian would have had a dandy iPhone competitor on the market before the iPhone launched. But politics between Symbian's owners forced it completely out of the UI business, and Quartz was spun out into a separate company called UIQ, which went bankrupt in 2009.

You can get more details on the whole sad Quartz saga here.


Quartz circa 2001

An OS without a single consistent user interface is a nightmare for software developers, because they can't write apps that run across the installed base of devices.

Eventually, in the face of all the restrictions, the most ambitious, nonconformist people at Symbian -- the ones who drive innovation in any organization -- seemed to drift away in frustration or were forced out when they irritated the owners. Symbian itself retreated into focusing on technological esoterica like symmetric multiprocessing -- things that didn't really differentiate the platform to users, but that the licensees wouldn't object to.

From one perspective I guess you can say Symbian was a complete success, because it fulfilled the two negatives that its founders wanted: Microsoft didn't dominate mobile software, and Symbian itself didn't exercise any control over its founders.

However, the cumulative effect of the handset companies pursuing their short-term interest was that Symbian was utterly unready to respond when Apple and Google entered the market. I don't think either Nokia or Symbian really understood how the game had changed. Apple designs phones as integrated systems, with the software and hardware tightly coordinated. Nokia could never achieve that level of coordination with an operating system managed through standards committees.

And as for Android, Nokia apparently thought that open sourcing Symbian would create a level playing field with Google's free OS. But I think the structure of the Symbian Foundation made that impossible.

The fatal flaw of the Symbian Foundation. Although Android is a free product, it's supported by a for-profit corporation that has massive resources. The attraction of Android to phone companies isn't just its price, but its safety -- Google stands behind it with marketing and technical support.

In contrast, Symbian Foundation was designed as a rigorously noncommercial institution banned from any business activity. People at the Foundation told me Nokia was adamant about enforcing the ban on commercial activity because it was afraid the tax authorities might rule that the foundation wasn't a nonprofit, endangering the tax credit that Nokia got for donating its Symbian code base.

Most open source companies give away their software in order to make money from some other mechanism -- consulting, or support, or a for-fee version of the same code. Symbian Foundation was banned from making money on any of these activities, meaning it could never become financially self-supporting.

Forget about marketing support; Symbian couldn't even offer enhanced technical support to licensees who were begging to pay for it. That was especially crippling because Symbian OS is notoriously complex and difficult to program (link).

Consider this quote from Tim Ocock's article:

"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....Symbian’s licensees...each had their own proprietary telephony chipsets that needed to be integrated and their own customisations to the platform in mind....Despite talk of Symbian enabling differentiation, the reality was licensees' budgets were squandered on hardware porting and making the core platform fit for purpose."

Picture yourself as a manager at a handset company, choosing an OS for your smartphone. The Symbian option has no advertising support, requires customization, is hard to program, has few third party consultants to support it, and the company licensing it won't help you do the programming. Meanwhile, Google Android is more modern, is based on Java and Linux so it's easy to find programmers, has lots of support, and has user-friendly features like an app store. Which one seems the safer bet?

How could the Symbian Foundation ever succeed in that situation?

Although people advocating for a "European" mobile OS often complain that Android had unfair financial advantages, the fact is that Symbian was ripe for the picking, a situation that was almost entirely self-inflicted.

The lesson for other tech companies: Open source is not magic pixie dust that you can sprinkle on a struggling product to turn it into a winner. Open source is a tactic, not a business strategy. It has to be paired with a business plan that says how you'll make money and drive innovation.


This is the end, my friend, of our elaborate plans

Like an army refighting the last war, Symbian was designed to defeat Windows Mobile, but never came to terms with its new adversaries Apple and Google. There's no shame in that for most of the folks who worked at Symbian; they did the best they could to navigate the politics of Nokia and all the other Symbian licensees. But radical change was necessary. I hope Nokia's Qt strategy will be successful. And I'm sure that Symbian code will continue to serve for years as the underlying technology for millions of Nokia smartphones. But except in the dreams of a few EU officials, Symbian OS is now just legacy plumbing.

It's time to move on.

A quick history of software platforms: How we got here, and where we're going

Intuit and Stanford recently asked me to give talks on computer platforms and what makes them successful. (By platforms I mean software with APIs that third party developers can write apps on top of; Windows and Macintosh are both platforms, as is Java.) Platforms are a hot topic in Silicon Valley these days. The success of the iPhone app store in mobile, and Facebook on the web, have forcefully reminded people that you can grow a tech business more quickly if you get third party developers to help you. Almost every tech company I work with is trying to expose some sort of API or platform offering in its products.

To explain how software platforms work today, I thought it'd be good to start with their history. But I wasn't sure about many of the details myself, so I ended up doing some research. The information was surprisingly hard to find, and also pretty controversial -- for every person who claims to be the first to have done something in computing, there's someone else who begs to differ. I did my best to sort through all the claims. The picture that developed makes an interesting story, but also has some very important lessons about where the industry might go next.

Fair warning: this is a long post. But I hope you'll feel that the destination is worth the trip.

Here's what I found:


Hardware memory, software amnesia

The computer industry is often criticized for its failure to remember its own history. Supposedly we're so focused on the new thing that we forget what's come before.

In reality, though, we're actually fairly good at remembering a lot of our hardware history (for example, Apple fans are celebrating the 25th anniversary of the Macintosh this year). There's passionate controversy over what was the first computer -- was it Konrad Zuse's Z1 (link), Tommy Flowers' Colossus (link), etc. The answer depends in part on your definition of the word "computer." But it's a well-documented disagreement, and you can find a lot of information about it online, including a cool timeline at the Computer History Museum (link).

The machine most commonly cited as the first fully programmable general-purpose electronic computer was ENIAC, the Electronic Numerical Integrator And Computer. It was completed in 1946 (link).


Here's ENIAC (well, part of it, anyway)

You can find lots of histories of ENIAC online (link). There are multiple simulators of it on the web (link), and the engineering school at the University of Pennsylvania even has an ENIAC museum online (link).

But when it comes to software, our memories are much hazier. For example, I doubt there will be a 25th anniversary celebration in 2010 for Aldus PageMaker, the program that did more than any other to make Macintosh successful. And about a day after I post this article -- May 12, 2009 -- will be the 30th anniversary of the introduction of Visicalc, the first spreadsheet program. Anyone planning a parade?

Today we take it for granted that you can use a computer for a variety of business or personal tasks, but it didn't always work that way. ENIAC and Colossus were government-funded tools for solving military and scientific problems. The US Army funded ENIAC, and in addition to calculating artillery tables, it was also used for tasks like weather prediction, wind tunnel design, and atomic energy calculations.


These nice ladies are programming ENIAC, by moving cables around.

How did we end up using computers for other purposes? The UPenn site says only, "it is recalled that no electronic computers were being applied to commercial problems until about 1951."

Yeah, "it is recalled." This is where I had to start digging. Once again there are disputes (link), but you can make a very good case that business computing started in the UK, and it involved something called a Swiss roll.


The first business computer

I had never heard of Joseph Lyons & Company, but in the 1950s they ran a chain of tea shops in the UK. I have to pause here for a second and explain what the term "tea shop" means. It's not a shop where you can buy bags of tea (which is what I assumed). Instead, it is what Americans call a coffee shop -- a fixed-menu restaurant that people would come to when they wanted to have a quick meal, snack, or meeting. The closest equivalent in the US these days is probably Denny's.

In the 1950s, Lyons had the biggest network of tea shops in the UK. It employed 30,000 people and served 150 million meals a year. The company sold 36 miles of Swiss roll a day (link).

(In case you're wondering, Swiss roll is a flat sponge cake rolled around a filling. Americans call it jelly roll. In India, it's called jam roll. In Sweden, rulltårta. In Japan, "roll cake." But in Spain, for some reason it's called brazo de gitano (gypsy's arm). Don't ask me why. [link] )


A Swiss roll made and photographed by Musical Linguist on 25 June 2006

Like every other company of its day, everything at Lyons was run on paper -- tallying 150 million receipts, calculating payroll, managing taxes, and even figuring out how many miles of Swiss roll you need to make for tomorrow's customers. All of that by hand with adding machines. It was an incredibly expensive and error-prone way of running a business, but it was the best anyone could do at the time.

When the people at Lyons first heard about these new computer thingies, they wanted one immediately to help run the business. But there wasn't any way to buy one. So they donated $5,000 (about $50k today) to Cambridge University to create a modified version of a computer that Cambridge had been working on.

The result was called LEO (Lyons Electronic Computer), and when it started regular operations on November 17, 1951, it was the world's first business computer. It occupied 5,000 square feet of floor space (about 500 square meters), and its 4k memory unit weighed half a ton because it was full of mercury. LEO's lead programmer was David Caminer, who is generally credited as either the world's first business software programmer or the first systems analyst. LEO's software let it handle -- guess what -- the same sorts of tasks we handle on business computers today: payroll, inventory, financials, and so on. It cut the time to calculate one employee's wages from eight minutes to 1.5 seconds (link).


David Caminer

Pause for a moment and think about the courage and vision it took for Lyons -- a catering company -- to build its own computer. There was no guarantee the process would succeed, and indeed the process took two years, with plenty of setbacks along the way.

But LEO was eventually a big success, and Lyons eventually spun it out as a separate computing subsidiary. Caminer went on to have a distinguished career in computing. He died in 2008, unfortunately, so we just missed our opportunity to say thanks to him. If you want to read more about LEO, Caminer co-wrote a book about it (link). Naturally, it's out of print, and the cheapest used copy when I looked it up was $75.


What is software, anyway?

One interesting aspect of LEO is that although Caminer and his team wrote software for it, that software was not available separately from the computer. That's the way the computing industry worked throughout the 1950s. For example, if you bought an IBM computer there was a set of standard IBM programs that ran on it.

In fact, the term "software" didn't even exist until it was popularized by John Tukey in 1958, more than ten years after ENIAC began operation (link). He wrote:

Today the "software" comprising the carefully planned interpretive routines, compilers, and other aspects of automative programming are at least as important to the modern electronic calculator as its "hardware" of tubes, transistors, wires, tapes and the like.

So the whole idea of software as a separate entity, a concept that we take for granted today, did not exist at the beginning of computing. The concept of making computers reprogrammable came along quite early, but it took a couple of decades for software to fully separate itself from hardware as its own distinct discipline.


John Tukey

(Naturally, there's some dispute about whether Tukey was the first to use the term "software." You can read about it here.)

Tukey was an interesting guy. He also created the term "bit," helped design the U-2 spy plane, and did a lot of other fascinating things (link).

If you want to read more about the history of software technologies, there's an essay here. And the best (and just about only) book on the history of the software industry is here.


Software as a business

Once we got the idea of software into our heads as a separate discipline, the next milestone in platform history was the creation of the first independent computer program, the first one you could buy separately from the hardware. As far as I can tell, that idea didn't just spring into being all at once; it emerged as a slow-motion avalanche over a period of 15 years.

Computer Usage Corporation, founded in 1955, is often cited as the first computer software company. It focused on custom programming services (link). Another very early custom programming company was CEIR, founded in 1954 (link). After them, a number of other custom programming firms sprang up. Sometime between 1962 and 1965, California Analysis Center, Inc. started selling a proprietary version of the Simscript programming language as a standalone product (the Computer History Museum says it was 1962 here, but CACI's own website says 1965 here). The 1962 date is the earliest I can find for any sort of independent software product. To my amazement, CACI is still selling Simscript today (link).

Several other programming languages and compilers came to market in the early 1960s, but there's disagreement over how much they actually sold, or whether they were really managed as independent products (link). A file management program called Mark IV, by Informatics, is credited as the first independent software product to generate more than a million dollars revenue. It was published in 1967 (link). That year also saw the first publication of the International Computer Programs Quarterly, the first commercial software catalog, which helped small software companies get to market at low cost (link). Think of it as a paper version of the iPhone App Store.

But if you want to find the first snowball that started the commercial software avalanche, I think it was tossed in 1964 when a contract programming company called Advanced Data Research was jerked around on a business deal by RCA.


The first commercial software product

In the mid-1960s, a cottage industry of contract programming firms did custom software development. When a new mainframe was in the works, its manufacturer would sometimes hire these firms to create software to offer with it. Computer owners could also hire those development houses to write create custom software for them. The idea of off-the-shelf software didn't exist; you got it for free with your computer, had it written for you, or developed it yourself.

RCA, which at the time was a promising mainframe company, approached ADR asking them to create a program to draw flow charts of computer programs (the flow charts were used for documentation and debugging). That may not sound like a big deal today, but in the early days of computing the industry didn't have the sort of automated debugging tools it has today. A flowchart was very useful to help maintain and document a custom software program after the project was finished.

So ADR created a proposal and submitted it to RCA. Fortunately for the computer industry, RCA turned it down, as did every other mainframe company. But ADR believed in its concept, so it decided on its own to develop the product anyway. It spent over $5,000 (about $35k in today's money) and half a man-year on the project.

But RCA was not impressed. Once again they said no.

Now ADR had a sunk cost. In business school they teach you to walk away from those, but in real life companies hate to admit they made a mistake. So ADR decided to try marketing the software on its own. They named it Autoflow, and wrote a letter to all 100 RCA mainframe owners offering them the program for $2,400 on a three year lease. It was three milestones in one: the first commercial software program, the first subscription software, and the first junk mail urging you to buy a software program.

ADR sold two licenses.

That may not sound like much, but somebody at ADR did the math -- if we sold two copies to 100 RCA customers, what would happen if we offered our software to IBM's much larger installed base? So ADR ported Autoflow to IBM mainframes. In the second half of the1960s it sold more than a thousand licenses of Autoflow, and created a portfolio of other independent software programs for IBM systems.

IBM was not pleased. Nobody was supposed to mess with the IBM customer base; that might weaken IBM's control over its customers. The company created its own flow charting software, which it gave away for free to its customers, and started to copy ADR's other programs as well. This became a huge competitive problem for ADR -- even if its software worked better than IBM's, it was hard to compete with free. IBM was also able to freeze the market for ADR by promising that it would in the future offer a free version of something ADR was currently selling. Customers would delay ADR purchases until they could evaluate the IBM product.

ADR and other fledgling software companies complained to the US government. In 1969, the Justice Department, ADR, and several others filed antitrust suits against IBM. ADR collected $2 million in penalties, and IBM agreed to stop bundling free software with its computers.

And thus the independent software industry was born.



Martin Goetz (above) was the product manager of Autoflow. I wrote to him and asked for his take on which was the first software product. Here's his reply:

Autoflow was recognized as the first software product to be commercially marketed. Starting in 1964, ADR licensed its products nationally and through ads in all the major computer publications, started investing in the development of other products and became known as a software products company.

I think that's the right way to look at it: Autoflow was the first software product to be commercially marketed, which is why I call it the snowball that started the avalanche. Informatics' Mark IV also played an important role because its financial success validated the market -- reportedly it was the top-selling software product for the next 15 years (link).

Goetz says Mike Guzik was the lead programmer on Autoflow (link), and he cites ADR President Dick Jones as a strong supporter of the idea (link). I think we should credit Goetz and Guzik as the creators of the first commercial software application, although neither of them has an entry in Wikipedia.

Incidentally, Goetz also holds the first software patent:


Computerworld, June 1968

That has to be one of the most visionary headlines in the history of the computer press: "Full Implications Are Not Yet Known." Here we are 41 years later, and it's still accurate.

Goetz was named the "Father of Third-Party Software" by mainframezone.com (link) and there's a very interesting interview with him here. You can find a much longer interview here and his memoirs are here.

Advocates of open source software will probably view Goetz as a bad guy, since he helped make software a for-profit industry. But he has some pretty strong opinions about the poor quality and slow innovations that happened in software when it was only free. In particular, he says that a completely free software industry was not responsive to the needs of users (link).

An amusing anecdote complaining about Goetz, apparently written by a former ADR employee, is here. I can't verify the anecdote, but if nothing else it shows that ADR was also a pioneer in the practice of engineers making catty comments about product managers.

(I should add that there are some different interpretations of the effect of IBM's unbundling decision. One is in a very interesting interview with the creator of the ICP catalog here.)


The rise of the third party application platform

The next evolutionary step was for computer companies to see their products as development platforms -- for them to actively encourage software developers rather than viewing them as a nuisance. I haven't been able to figure out when in the 1970s this change in perspective happened (please post a comment if you know the history). It may have happened in the era of minicomputers, or it may have been a PC thing. Definitely Dan Bricklin and Bob Frankston's VisiCalc, the world's first spreadsheet program, played a role when it came to market for the Apple II in 1979. It was so revolutionary that reviewers at the time didn't know how to describe it. They just said it was a way to make the computer do things you want it to do, without writing your own program. VisiCalc established the idea of the "killer app," a software program so popular that it drove demand for the underlying hardware.

"Visicalc could some day become the software tail that wags (and sells) the personal computer dog."
--Ben Rosen, co-founder of Compaq, reviewing VisiCalc when we was still an analyst with Morgan Stanley. Nice call, Ben. (Link)

By the early 1980s, software developers were being actively courted by computer manufacturers. Apple had a developer recruitment team for the Macintosh, and apparently coined the term "software evangelism." That's where Guy Kawasaki cut his eyeteeth, although he wasn't the first evangelist. As he puts it:

"Mike Boich started evangelism and hired me, and Alain Rossman worked with me as a software evangelist. Essentially, Mike started evangelism, Alain did the work, and I took the credit." (Link)

I happen to know that Guy did a bit of the work too.

The other critical change in the 1980s was the separation of the OS from the underlying hardware. Most of the new PC software platforms had been tied to hardware, just like traditional computers. For example, you had to buy a Macintosh in order to run Mac software, or an Amiga in order to use Amiga apps. But then IBM created the PC, and through a series of business blunders allowed Microsoft to separately sell the DOS operating system used on its hardware. IBM's brand and marketing power established the PC as a standard, but the company enabled Microsoft and Intel to create a "clone" hardware market, and eventually drive IBM out of the PC business.

So now there were three layers in the industry -- the application was independent of the OS, and the leading OS was independent of the hardware.


The network strikes back

That's where the situation sat until the late 1990s, when Java and web browsers threatened to create another layer in the architecture by separating software applications from the OS. The theory was that instead of writing programs that depended on Windows, programmers could create code that worked on Java, or on the Netscape browser.

Microsoft fought back very aggressively, killing Netscape by giving away Internet Explorer, and crippling Java on the PC. Looking back, it was an impressive use of business muscle, worthy of Microsoft's tutor IBM.

But it was also a pyrrhic victory. Microsoft's actions in the 1990s forced software innovation completely off the PC platform, because investors were afraid that new software apps would just get cannibalized by Microsoft. Instead software innovation moved onto the web, where Microsoft had virtually no control. That's one of several reasons why the next generation of software is being written as web apps.

And that's where we are today.


Where we go next

As I said at the start of the post, I think all of this history is fun in its own right. I also wanted to take this opportunity to thank some of the people who built the tech industry into the fun place it is today.

But understanding computing history is also very important because, if you look across the sweep of it from the 1940s to today, it's much easier to see where we might go next.

Here's what I think that long perspective shows us: The history of software is a history of disaggregation. First the application software gets separated from the hardware, then the OS gets separated from the hardware, and so on.

I think disaggregation is a natural outcome of the maturation of the industry, because multiple companies can move faster than a single one. At the start you need everything coordinated together to make sure the whole thing will work. But over time, no single company can pursue all of the innovation possibilities, so you get a backlog of potential creativity that can happen only if control over the architecture is broken into pieces.

For example, most of the interesting innovation in applications happened only after they were separated from the hardware.

But as the industry continues to grow, each of the pieces becomes its own stodgy monolith, and eventually another subdivision happens.

The fastest growth and the easiest innovation has generally happened at the leading edge of disaggregation, because each change creates new business opportunities.



That doesn't mean that old school companies are dead. IBM still sells mainframes, and Apple still makes PCs bundled with an OS. But to succeed in an old paradigm you have to execute extremely well, and it's much harder to grow explosively. The easiest progress is made at the leading edge.

A common thread among the people working at the leading edge of disaggregation is their excitement as they recognize the opportunities created by the change:

"There was a tremendous euphoria of success. You couldn't lose. All you needed was a group of highly technical people who could create a software product and that was it. And to some degree there was some truth to that. Because you didn't have to be good sales people. You didn't have to worry about the competition. For years I used the aphorism that we were like little boys on the beach each with our sand piles. There was plenty of sand to put in our buckets. We didn't have to edge out the other little boy to get all the sand we needed. We were limited by the size of our pail and our little shovels but not by the amount of the beach that was there or the fact that there was another little boy there with his pail."

That's Walter Bauer, cofounder of Informatics, talking about the birth of the independent software industry in the 1960s (link). But you could find similar sentiments from the people who built the first computers, or the first Mac programmers, or the first web app developers. The leading edge of disaggregation is where the action is; it's where the fun happens.

So, if you're looking to succeed in the software industry, it's extremely important to figure out what's going to get disaggregated next. Which brings us to the point of this article.


Say hello to the metaplatform

Sun's rallying cry in the 1990s was, "the network is the computer" (link). It was an excellent insight that pointed to the emerging importance of the Internet, but most of the industry misread what it meant. We looked at the architecture of the thing we knew best, the PC, and tried to map it directly to the network. So servers would replace the PC hardware, and software on those servers would replace Windows. The PC itself would be reduced to light client, a screen connected to a wire.


What we expected

But instead of a new OS on the network replacing the OS on the PC, what we're seeing is the breakdown of the OS into component parts that live everywhere, on both the client and the server.

In other words, the OS is the next thing that gets disaggregated.


What's actually happening

People have been talking about elements of this change for years, but like the proverbial blind men feeling bits of the elephant, we've talked about individual pieces of it, with each of us assuming that the piece in front of us was the most important. So people producing software layers like Java and Flash say that they are separating the APIs on the device from the underlying OS. And the advocates of cloud computing say they're creating a software services architecture that runs on servers. But in reality we're doing both of those things, and a lot more. The OS is dissolving into a soup of resources distributed across both the network and the local device, with the application in the middle calling on both as appropriate. We need to get off the idea that the network or the client will be dominant; they're both supporting elements in something larger.

You can see this process operating in the evolution of web applications. The first web app companies tried to make applications that were entirely light client, but they didn't work particularly well -- they were slow, and their user interfaces were too limited. Web apps took off only when they adopted an approach in which the platform was split between the PC and the network -- the user interface ran locally through the browser, while back-end calculation and data storage was done on the network.

Mobile computing reinforces the need for this sort of hybrid architecture. Wireless broadband has important limitations that make pure light client computing extremely problematic. Wireless networks are relatively slow compared to wired networks, there's high latency on them, coverage is inconsistent, heavy communication drains device batteries rapidly, bandwidth is expensive, and most importantly, total wireless bandwidth is limited. The most effective mobile application are and will continue to be hybrids of local and network resources, like RIM's e-mail solution.

Companies entering the mobile market often ask me which mobile operating systems are going to win long term. I think that's the wrong question. What we're seeing is the gradual evolution of a super-OS that includes both the network and the device.

Like software developers before the word "software" was invented, we don't have a name for this new thing, and so we have trouble talking about it. It's not just the Network or the Cloud, because those terms are usually understood not to include the software on the client computer. And it's certainly not just the local APIs on the client device.

I'm calling it the "metaplatform" because it subsumes all other platforms. No single company controls the metaplatform. Google obviously contributes a lot to it, as does Amazon Web Services, as does Microsoft. But they're only fragments of the picture. There are thousands of other contributors to the metaplatform, in areas ranging from mapping to graphics to identity.

There's still a lot of work that needs to be done on the metaplatform, especially in the mobile space. But already it's evolving faster than any single company could move it, because the work is divided across so many companies, and because there's competition driving innovation at almost every point in the architecture. Although the metaplatform isn't necessarily elegant (because it's poorly coordinated), what it lacks in beauty it more than makes up for in rate of change and versatility.


New opportunities

The metaplatform helps to solve some computing problems, but creates others. For example, a recurring problem for software in the OS era has been compatibility. Old data files, even when perfectly preserved, can become unreadable if the hardware and software that created them is no longer available. A lot of software is very dependent not just on the hardware, but on the particular version of the OS it's running on. (If you want to see that effect in action, try running a ten-year-old Windows game on a new PC. It may work, it may refuse to run at all -- or it may freeze right when you're about to defeat the boss bad guy.)

The metaplatform is helping to resolve some compatibility problems, through emulators available online. But more importantly, web apps on a PC are less vulnerable to PC-style compatibility breakdowns because PC browsers are relatively standardized, and much of the OS code the web app relies on lives on the same server as the app itself, so they are less likely to get out of sync.

But metaplatform-based software is uniquely vulnerable to a new set of problems. When a user's data is stored on a web app company's server 3,000 miles away, what happens if that company goes out of business or just decides to stop maintaining the product?

Another problem experienced by any website using plug-ins is component breakage. If you've incorporated external web services into your site, the site will break if any of those services stops working. This can happen without warning. On my own weblog, the load time for the site suddenly became ridiculously long. It took me weeks to realize that a user-tracking service I'd once signed up for had gone out of business without telling anyone. My site stopped loading while it tried helplessly to connect to a tracking site that no longer existed.

An old software application from the OS era has some hope of revival if you have a copy of the CD, because all the code that made up the app is together in one place. But an old, broken web app will be almost irretrievably dead, because huge chunks of its code will be missing.

Problems like these are just starting to emerge, but as the metaplatform grows and ages they'll become much more prominent. We don't have any systematic ways to deal with problems like these today -- which means they're a business opportunity for the next crop of software entrepreneurs.


What the metaplatform means to you

Much of the discussion in this post is pretty theoretical. But I think it has important practical implications. Here are a few specifics to think about:

If you're a computer user (and if you're reading this, you must be), keep in mind that the most interesting new software innovations are likely to come from companies that consciously work the metaplatform. If you want to be at the leading edge of software innovation, you should keep yourself open to experimenting with new web applications and plug-ins, and make sure your browser doesn't artificially cut you off from some technologies. This is especially true for mobile devices. The iPhone today gives (in my opinion) the best overall mobile browsing and app discovery experience, but you pay a price for it -- you're cut off from some web technologies (Flash, Java) and your choice of applications is limited by the Apple app police. You pay a serious price for the superior user experience of the iPhone. That price is worth paying today, but in the future I hope there will be mobile devices that are as satisfying as the iPhone but less controlled. Actually, I'm sure that will happen over time. But "over time" can sometimes mean a long time in the future. You can help the process along with what you buy and by the feedback you give to device manufacturers.

Are you working at an OS company? If so, you probably measure success by the number of devices your software controls. You need to rethink that viewpoint. The OS is going to be less and less of a technology control point in the future. It will become commodity plumbing underneath the metaplatform, limiting your ability to charge a lot of money for it. So at a minimum, you need to plan for cost control.

But you should also be asking if plumbing is the right place for your company's creativity in the long term. There will be much more profit opportunity in contributing to the metaplatform by creating APIs and developer functionality that can be used across different operating systems. OS companies have many of the assets needed to build those components of the metaplatform. A successful OS can be a great launching point for technologies that run across platforms, because you already have a big installed base that you can use to jump-start the technology's adoption.

Are you at an application company? Many successful app vendors are trying to create APIs that will enable other developers to extend their products. This is the right idea, but the implementation is often off-target. Many of the app companies I talk to are trying to make their APIs into the business equivalent of an operating system, with developers coming to them and living entirely within their private ecosystem. A warning sign is when a company uses a phrase like, "(insert company name) developer network" to describe its offering.

The wave of the future is not turning an application inward into its own little walled garden; it's opening the application outward so it can be mixed and matched with other functionality in the metaplatform. If you have the best drawing program in the industry, you should be asking how you can also become the best drawing module in the metaplatform. Get used to being a component in addition to a standalone product. You lose some identity in the process, but gain greater opportunities to grow.

And besides, if you don't do it, you'll be vulnerable to someone else doing it and taking your place.

If you're a computing student, or a computing veteran looking to create a new product, think about what role you can play in the metaplatform, and what customer problems you can solve with this new tool. There will be big market openings in both products for users and companies, and infrastructure for other developers in the ecosystem (billing, rights management, security, etc).

As in previous generations of software, the answers are not immediately obvious, and the people who figure them out first will have huge opportunities to do something impactful. Like Caminer, Goetz, Bauer, Bricklin, and Frankston, you're on an enormous beach with a trowel and bucket, and you have a chance to shape the next generation of computing.

Have fun.

====

I'd like to thank Eugene Miya of NASA Ames and Martin Goetz for helping with the research that contributed to this article. They're not responsible for any errors I made, but they definitely corrected some.

I'm sure there are folks out there who have additional information on the history I wrote about here. If you have anything to add (or correct) please post a comment.

Nokia: Running in molasses

Every time I think about Nokia and Symbian, I can't help picturing a man knee-deep in molasses, running as fast as he can. He's working up a sweat, thrashing and stumbling forward, and proudly points out that for someone knee-deep in molasses he's making really good time.

That thought came to me several times during a briefing day that Nokia and the new Symbian Foundation held recently in San Francisco. A recurring theme was a deeply earnest discussion of how big and complex their business is, and how proud they are that despite the complexity they can make forward progress. For example:

Charles Davies, CTO of the new foundation, pointed out to us that Symbian OS has about 450,000 source files. That's right, half a million files. They're organized into 85 "packages," all of which have been charted out in a diagram that will be posted soon on the foundation's website. Davies was proud that the diagram is in SVG format, so you can zoom in on it and see that "this is an architecture that's not just a plateful of spaghetti."

The diagram looks a bit like a plateful of very colorful spaghetti (although in fairness to Charles, that's true of every OS architecture diagram I've ever seen). Anyway, the big takeaway was how huge the OS is.

Davies talked about the substantial challenges involved in open sourcing a code base that large. He said it will take up to another two years before all of the code is released under the Eclipse license. In the meantime, a majority of the code on launch day of the foundation will be in a more restrictive license that requires registration and a payment of $1,500 for access. There's also a small amount of third party copyrighted code within Symbian, and the foundation is trying to either get the rights to that code, or figure a way to make it available in binary format.

Those are all typical problems when a project is moving to open source, and the upshot of them is that Symbian won't be able to get the full benefits of its move to open source until quite a while after the foundation is launched. What slows the process down is the amount of code that Symbian and Nokia have to move. I believe that Symbian OS is probably the largest software project ever taken from closed to open source. If you've ever dealt with moving code to open source, you'll know how staggeringly complex the legal reviews are. What Nokia and Symbian are doing is heroic, scary, and incredibly tedious. It's like, well, running in molasses.

Lee Williams, Nokia's software platform SVP who is moving over to become head of the Symbian foundation, picked up on the theme of massiveness. He said the OS is on 200 million devices, with 200 device types shipped and another 100 in development. With support for five different baseband modems, seven different processor architectures, symmetric multiprocessing, and a broad set of displays, "your options are dramatic and huge."

This sort of infrastructure is needed, he said, because IT, telecom, and the Internet "have merged almost completely.... It's the perfect storm of convergence. There's almost nothing it can't eat or it won't use." He compared its importance to the creation of movable type, color palettes, and the Renaissance.

He noted that some people think the Symbian Foundation is a response to Android and other competitive moves, but said the company can't move that fast, and actually the change was in the works long before Google announced its software.

At dinner, I had a chance to chat with one of the Nokia managers. He was kind enough to let me play around with a pre-release N97 (more on that below), and the discussion gravitated to the iPhone. He told me how excited he is by the many new products Nokia has in the labs but can't talk about yet, and expressed some frustration that people don't understand why it takes time for Nokia to respond to changes in the market. He described Nokia as a giant ship. "It takes a long time to turn it, but when we do..." he said ominously, and then reminded me that Netscape once had a lead over Microsoft before it was crushed.

The problem with talking to the folks from Nokia is that you're never sure what they believe vs. what's the official story they're trying to put out in the market. They're disciplined enough that they can stay on message quite well, and in most conversations they focus on talking about what they're doing rather than asking for feedback or getting into a two-way conversation.

So I'll assume that Nokia was being serious. In that case, let's look at some financials from 1997 (Netscape vs. Microsoft) and 2007 (Apple vs. Nokia):


All figures in millions of dollars.

Don't worry too much about revenue and net income; those are usually tied up by the ongoing operations of each company. The line I want you to focus on is cash. That is your ammunition -- the extra resource available to fund a big marketing campaign, or a new product development program, or an acquisition of an innovative new technology. Microsoft had 46 times more cash than Netscape in 1997, and it wasn't seriously threatened in any of its other core businesses. It could, and did, spend Netscape into the ground.

Apple has about the same cash hoard as Nokia. Much more importantly, Apple can focus that cash on a narrower battlefront. Its situation relative to Windows is relatively safe. Although Microsoft can never be ignored, it is innovating so slowly that Apple can take some profit from its PC business to fund other things. The music player business is also stable; although it's not growing like it used to, no one has come close to matching the integration of the iPod and iTunes. So Apple is free to spend huge wads of cash to establish its new iPhone business. It can pick the countries and vertical usages it wants to dominate, and as long as it doesn't do too many things at once, it can outspend almost any competitor.

Nokia, on the other hand, has battlefields everywhere:
--In mobile phones it's fighting Samsung, LG, and SonyEricsson, and a badly wounded (therefore desperate) Motorola.
--In entertainment smartphones it's fighting Apple.
--In communicators it's fighting RIM.
--In OS it's fighting Google, Microsoft, etc.
--In online services it's fighting Google, Yahoo, Microsoft, etc.

As Nokia EVP Anssi Vanjoki put it recently (link):

There’s a company that says they can index the world; we are going to go deeper - we are going to coordinate the world.

Sweet! He calls out Google and says he'll beat them in their core business. It's a noble effort. I love the company's ambition. But does Nokia have the resources to fight all those battles at once?

If the folks at Nokia really think they are well positioned to crush Apple, they need to go re-read The Innovator's Dilemma. Being big is not a benefit in a rapidly-changing market with emerging segments. A big company can't respond nimbly to that sort of change, and the segments attacked by new entrants are usually too small to justify huge investment by an incumbent. So new challengers like Apple and RIM pop up all around you, you gradually shed little chunks of market share, and you complain that people don't understand how powerful your core business is.

I am not at all saying that Nokia is doomed. They are an outstanding company, with smart people, a great brand, and enormous strengths. But they need to understand that turning the battleship a little faster won't win the war. Nokia's smartphone competitors are not standing in molasses; they won't stay still long enough for the 16-inch guns to be pointed at them. More importantly, the competitors on the services side breed like vampire rabbits. By the time you blow away a clutch of them, three dozen more have hatched and are sucking blood from the other side of the ship.

To succeed in smartphones, I think Nokia needs to start creating the sort of integrated software + hardware solutions that the smartphone winners excel at. And on the services side, it needs to start breeding its own killer rabbits (small entrepreneurial experiments that move fast and die quickly if they fail). So far what I think I see looks like a more design-savvy version of the smartphone business of Samsung (throw hardware at the wall and see what sticks) coupled with an effort to create a 16-inch cannon of services.

That's probably not enough to win in the long run. Nokia still has a lot of time to get it right. But do they really understand what needs to change? I can't tell, because all I usually get from them is monologues on how big their business is and how much cool stuff they have in the lab.

=====

A few other tidbits from the day...

N97: Second cousin twice removed of the Revo. I got a chance to play with a pre-release N97, Nokia's upcoming qwerty phone. The screen slides sideways to reveal a little keyboard underneath.

The look and size of the device reminded me a little bit of the old Psion Revo, although it's a pretty distant echo. The sliding process of the screen has a very nice feel to it; it's the sort of physical detail that Nokia excels at. Even in a pre-release state, the phone felt nice and solid in my hand.

The software needs a lot more work, but they admitted that. It's a pre-release device. No worries at this point.

As for the keyboard, I thought it was mediocre. The keys, and especially the microscopic letters on them, are a little too small for my taste (I have big thumbs). Typing was slower than I expect on a thumb keyboard. I'd put it about on a par with the Blackberry Storm (that's the Blackberry with the on-screen keyboard). The Storm has bigger letters than the N97, and unlike David Pogue I like the tactile feedback when you tap on its screen, although it is not as good as a real keyboard.

So the N97 has real keys but they're too tiny, and the Storm has bigger keys but they're not real. The tiebreaker is the software -- the Storm is notoriously unstable (it took me about 40 seconds to crash it). I think neither product is ready for the market yet. Unfortunately for RIM, the Storm is already shipping.

The destiny of Trolltech. About a year ago, when Nokia purchased Trolltech, I wondered what they were going to do with it (link). Now we know -- Trolltech's Qt software layer is going to become a graphics layer for Symbian. No word on what happens to Trolltech's other products.

That's nice, but what's it good for? Symbian is adding symmetric multiprocessing to the OS. In a session discussing the change, a member of the audience asked what you'd use symmetric multiprocessing for on a mobile device.

Long pause. "Well, some games use it..." Another long pause.

This is the difficulty of taking a technology-only approach when talking to developers. Although software developers are technophiles, what they really care about is what sort of cool products you can enable them to build. If your feature doesn't let them do something cool, they won't care about it.

(By the way, according to an article here, the benefit will be in performance tuning and battery life -- critical to handset vendors, but sanitation issues to application developers.)

Some alternate opinions. Some other people briefed by Nokia are not as worried as me about the molasses thing. In the interest of balance, here are a few examples:

Commentary from SymbianOne (link).

Fabrizio over at Funambol (link).

SonyEricsson on the event (link). (Never mind, that was a report from 2003. I am so embarrassed.)

Symbian changes everything, and nothing

[With a correction made on June 26.]

The Symbian Foundation announcement today is a fascinating change in business strategy, but I'm not sure if it will help or hurt Nokia in the long run. I think something like this was probably necessary just to clean up the mess in Symbian's ownership structure. If Nokia can make the new structure work, it'll be a milestone in the use of open source by large tech companies, but I'm not sure it helps Nokia win the smartphone war.


What happened

--Nokia is buying Symbian. Everyone currently working at Symbian becomes a Nokia employee after the deal closes. Nokia said it will spend the next six months deciding "how we will use the unique talent we are gaining."

[By the way, the buyout by Nokia is a change I said was possible two and a half years ago when it first became clear that some of Symbian's owners wanted out (link). I am astounded that the change took so long. I looked back at my old post a few months ago and thought, "wow, I really got that one wrong." Now I am relieved to say that I was not wrong, I was merely prematurely correct ;-) ]

--Symbian OS will become free. Nokia's Symbian-related assets, including both Symbian OS and the S60 interface, will be contributed to the new Symbian Foundation, a nonprofit that will control the Symbian platform. So Nokia writes the code and then gives it to the foundation for free.

Founding members of the foundation include: AT&T, LG, Motorola, Nokia, DoCoMo, Samsung, SonyEricsson, ST Micro, TI, and Vodafone. It's very interesting to see some operators in the mix, especially AT&T.

The foundation will open source the new Symbian platform over a two year period. So eventually Symbian will be available for free.

The new Symbian Platform will have a broader scope than the current Symbian OS. It will include:

-An application suite (previously controlled by licensees)
-Runtimes (including Webkit, Flash, Silverlight, and Java; previously licensee-controlled)
-UI framework (formerly controlled by licensees)
-Middleware
-OS
-Tools, SDK, and application signing (previously shared between Symbian and licensees)

--UIQ is dead. SonyEricsson's UIQ technology, and NTT DoCoMo's MOAP, both of which are user interface layers written on top of Symbian, will also be contributed to the foundation, which will incorporate pieces of them into S60. The new Symbian foundation partners said at the press conference, "We will reposition UIQ in the new ecosystem." That's seems to be a face-saving way of saying, "UIQ is dead." Confirming that, UIQ announced immediate plans to lay off more than half its employees (link).

These are huge changes, even though they'll take a couple of years to implement. We won't get the first release of the new merged platform until 2010, although the partners say S60 and native Symbian apps will continue to run in the future, so they hope many more developers will create Symbian apps today in anticipation of future growth.

--Nokia will continue to control Symbian development. This is my interpretation, not something they announced. Technically, control over Symbian and S60 passes to the new Symbian Foundation, with product plans controlled by a managing board and councils made up of foundation members. This makes Symbian sound independent. But Nokia will employ most of the people maintaining and extending Symbian and S60, and could divert them to other Nokia projects if it ever dislikes the direction of the foundation. More to the point, the whitepaper explaining the new foundation says, "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" (link). So Nokia as the dominant shipper of Symbian devices gets the most seats, and can then control the election of additional board members. Symbian contacted me on June 26 with a correction: "Five Foundation board seats will be allocated to handset vendors on the basis of volumes shipped using the Symbian Foundation platform. There will be a maximum of one (1) board seat per company." So Nokia gets one board seat, and does not control the foundation.

The right phrase for this, I think, is puppet strings. But I don't mean that in a bad way; it would have been insane for Nokia to actually give up control over its smartphone OS. Just don't have any illusion that the strings have been cut. They've merely been relocated, and in fact I think Nokia now controls things more directly since it owns the Symbian development team. Added June 26: Nokia has given other companies a formal say in the feature set, with less official control by Nokia than it had when it held about 50% of Symbian, but perhaps more practical influence because it now directly employs most of the people doing the engineering. So I think Nokia gave up the official veto it had over Symbian's actions, and replaced it with a practical one.


What does it all mean?

I don't know.

The announcement is so complex, and so many things are changing in the mobile market, that it's very difficult to predict how everything will turn out. Also, the whole thing depends on crisp implementation. Even the most brilliant strategy fails if you can't execute on it.

You can't say that Nokia lacks guts. The foundation members said at the announcement that it is one of the largest open source announcements ever, and I think that's true. It's a very interesting, aggressive move for Nokia, and I respect that. There are precedents for a big company acting as a sugar daddy for an open source software project, but I don't think it's ever been done with a project that is as central to the parent company's operations as Symbian is to Nokia. It will be fascinating to see if Nokia can really work effectively through the foundation model. I presume they have thought about this a lot and feel the risks are well controlled.

I'm having trouble seeing the big picture of how this changes the world, though. I suspect the announcement is actually half cleanup and half power move. The power move is that it challenges Android, and could help harness the energy of the open source community to support Symbian. The cleanup is that the ownership situation of Symbian was unstable and had to be changed eventually, and SonyEricsson clearly wanted to get out of the UIQ business. The creation of the foundation solves all of those problems at once. My guess is that since Nokia is paying most of the bills, the other foundation partners were willing to go along with it. The Symbian investors get some money from Nokia, and can sit back and wait to see what the foundation delivers.

Here are some other issues and questions that stand out to me:

Symbian gets its UI back. Years ago, Symbian took itself out of the user interface business, allowing Nokia and NTT DoCOMo to develop their own UIs, and spinning out the UIQ interface team. The company declared that it had been a mistake to ever go into the UI business. So it was amusing to hear Symbian at today's press conference saying how disruptive it was to have multiple user interfaces, and how great it is to have them unified.

The reality is that OS companies have traditionally created the UI along with the rest of the OS because they need to be coordinated closely, and because developers want to work with one consistent interface. So the real mistake was getting out of the UI business, and Symbian has now corrected that.

What will happen within Nokia? At the press conference, Nokia was asked what happens to its internal S60 development team (which is rumored to be larger than Symbian itself) once the merger is complete. Nokia said vaguely that it's going to spend six months working out all those integration issues, and what it will do with the multiple geographic locations. It's hard for me to believe that working out process won't result in some layoffs. I hope I'm wrong; I have friends at both Nokia and Symbian, and layoffs would be incredibly painful for the Symbian folks, many of whom have spent most of their careers there.

The fate of the people is just one of the open questions about what the merger means to Nokia. Another is the fate of Trolltech, the development tool that Nokia purchased recently and said would unify app development across Series 40 and S60. Will it be contributed to Symbian? And what does the open sourcing of Symbian mean for Nokia's use of Linux?

How does Nokia differentiate its software? The theory behind S60 was that Nokia would have its own user interface, helping to differentiate its phones from other Symbian vendors. Now that S60 will be given away, how will Nokia differentiate? The Symbian Foundation says licensees will be able to create a "differentiated experience" on its unified UI framework. Lord only knows what that means. Maybe Nokia has decided the UI is not a point of differentiation at all, and plans to focus on something else (web services, perhaps?)

Will the change in Symbian really drive more developers? As the Symbian partners pointed out repeatedly in the press conference, they have already sold 200 million phones. If that's not enough to excite developers, how will adding another 200 million -- or even 500 million -- do it? Although Symbian now has a nicer long term story, I don't think most developers were paying attention to that. They respond to user excitement and the chance to make lots of money. The new Symbian strategy doesn't directly drive either one.

What does it mean to Apple? I think it's probably good news. Although the Symbian partners could theoretically bleed Apple by sharing investments that Apple has to fund for itself, Apple competes on speed and elegance, not cost control. Nokia and Symbian will now spend the next six months sorting out how they'll integrate and rationalize their organizations. No matter how much they try to avoid it, this will slip schedules and force people to revisit plans. And the other Symbian licensees have to wait two years for the new OS. That gives Apple a long, long time to build up its iPhone business. The Register put it very bluntly in its commentary on the Symbian announcement (link):

"Apple must now see a clear road ahead for world dominance...it's now Apple's business to lose."

Wow, from new entrant to industry leader in just a year. That sort of stuff must drive Nokia nuts.

Is Google happy or upset tonight? My first reaction is to say that Google should be worried because there's now another very credible operating system being given away for free in competition with Android (or there will be in two years). What's more, the leading mobile handset companies all participated in the Symbian Foundation announcement. That makes it harder for Android to get licensees. But the new open Symbian OS is two years away from shipment, giving Google lots of runway to get established (that's what I meant about execution determining the real impact of the announcement). Also, the governance system for Android is a lot simpler than Symbian's. While the Symbian committees must debate and agree on product plans, Google can just decide whatever features it wants to add, and toss them out there. In theory, Google should be able to move much faster.

Besides, there is the question of why Google really created Android. One school of thought says that Android was just a tool to bleed Microsoft and force openness in the mobile ecosystem. If that's the goal, then the opening up of Symbian is a kind of a triumph for Google. Nokia is, in many ways, doing Google's work for it. Which brings us to...

What happens to Microsoft? Here's the weird thought for the day: Microsoft is the last major company charging money for a mobile operating system. The throwback. The dinosaur. How many companies are going to want to pay for Windows Mobile when they can get Linux, Android, or Symbian for free? This is Microsoft's ultimate open source nightmare, becoming real.

Mobile applications, RIP

Summary: The business of making native apps for mobile devices is dying, crushed by a fragmented market and restrictive business practices. The problems are so bad that the mobile web, despite its many technical drawbacks, is now a better way to deliver new functionality to mobiles. I think this will drive a rapid rise in mobile web development, largely replacing the mobile app business. This has huge implications for mobile operators, handset companies, developers, and users.


The decline of the mobile software industry

Mobile computing is different from PC computing.

For the last decade, that has been the fundamental rule of the mobile data industry. It was the central insight of Palm Computing's "Zen of Palm" philosophy. Psion came up with similar ideas, and you can hear echoes of them from every other successful mobile computing firm: Mobile computers are used differently from PCs, and therefore must be designed differently.

We all assumed this also meant mobile devices needed a whole mobile-specific software stack, including an operating system and APIs designed specifically for mobility, and native third-party applications created from the ground up for mobile usage.

That's what we all believe, but I'm starting to think we got it wrong.

Back in 1999 when I joined Palm, it seemed we had the whole mobile ecosystem nailed. The market was literally exploding, with the installed base of devices doubling every year, and an incredible range of creative and useful software popping up all over. In a 22-month period, the number of registered Palm developers increased from 3,000 to over 130,000. The PalmSource conference was swamped, with people spilling out into the halls, and David Pogue took center stage at the close of the conference to tell us how brilliant we all were.

It felt like we were at the leading edge of a revolution, but in hindsight it was more like the high water mark of a flash flood. In the years that followed, the energy and momentum gradually drained out of the mobile applications market.

The problem wasn't just limited to Palm; the level of developer activity and creativity that we saw in the glory days of Palm OS hasn't reappeared on any mobile platform since. In fact, as the market shifted from handhelds to smartphones, the situation for mobile app developers has become substantially worse.

That came home to me very forcefully a few days ago, when I got a call from Elia Freedman. Elia is CEO of Infinity Softworks, which makes vertical market software for mobile devices (tasks like real estate valuation and financial services). He was one of the leaders of the Palm software market, with a ten year history in mobile applications.

I eventually moved on from Palm, and Elia branched out into other platforms such as Blackberry. But we've kept in touch, and so he called recently to tell me that he had given up on his mobile applications business.

Elia gave me a long explanation of why. I can't reproduce it word for word (I couldn't write that fast), but I've summarized it with his permission here:

Two problems have caused a decline the mobile apps business over the last few years. First, the business has become tougher technologically. Second, marketing and sales have also become harder.

From the technical perspective, there are a couple of big issues. One is the proliferation of operating systems. Back in the late 1990s there were two platforms we had to worry about, Pocket PC and Palm OS. Symbian was there too, but it was in Europe and few people here were paying attention. Now there are at least ten platforms. Microsoft alone has several -- two versions of Windows Mobile, Tablet PC, and so on. [Elia didn't mention it, but the fragmentation of Java makes this situation even worse.]

I call it three million platforms with a hundred users each (link).

The second technical issue is certification. The walls are being formed around devices in ways they never were before. Now I have to certify with both the OS and with each carrier, and it costs me thousands of dollars. So my costs are through the roof. On top of that, the adoption rate of mobile applications has gone down. So I have to pay more to sell less.

Then there's marketing. Here too there are two issues. The first is vertical marketing. Few mobile devices align with verticals, which makes it hard for a vertical application developer like us to partner with any particular device. For example, Palm even at its height had no more than 20% of real estate agents. To cover our development costs on 20% of target customer base, I had to charge more than the customers could pay. So I was forced to make my application work on more platforms, which pushed me back into the million platforms problem.

The other marketing problem is the disappearance of horizontal distribution. You used to have some resellers and free software sites on the web that promoted mobile shareware and commercial products at low or no charge. You could also work through the hardware vendors to get to customers. We were masters of this; at one point we were bundled on 85% of mobile computing devices. We had retail distribution too.

None of those avenues are available any more. Retail has gone away. The online resellers have gone from taking 20% of our revenue to taking 50-70%. The other day I went looking for the freeware sites where we used to promote, and they have disappeared. Hardware bundling has ended because carriers took that over and made it impossible for us to get on the device. Palm used to have a bonus CD and a flyer that they put in the box, where we could get promoted. The carriers shut down both of those. They do not care about vertical apps. It feels like they don't want any apps at all.

You can read more of Elia's commentary on his weblog (link).

Add it all up, and Elia can't make money in mobile applications any more. As he told me, "Mike, it's time for you to write the obituary for mobile apps." More on that later.

Although it's a very sad situation, if Elia's experience were an isolated story I'd probably just chalk it up to bad luck on the part of a single developer. But it mirrors what I've been hearing from a lot of mobile app developers on a lot of different operating systems for some time now. The combination of splintering platforms, shrinking distribution channels, and rising costs is making it harder and harder for a mobile application developer to succeed. Rather than getting better, the situation is getting worse.

I've always had faith that eventually we would solve these problems. We'd get the right OS vendor paired with a handset maker who understood the situation and an operator who was willing to give up some control, and a mobile platform would take off again. Maybe not Palm OS, but on somebody's platform we'd get it all right.

I don't believe that any more. I think it's too late.


The mistake we made

We told ourselves that the fundamental rule of our business was: Mobile is different. But we lost sight of an even more fundamental law that applies to any computing platform:

A platform that is technically flawed but has a good business model will always beat a platform that is elegant but has a poor business model.

Windows is the best example of inelegant tech paired with the right business model, but it has happened over and over again in the history of the tech world.

In the mobile world, what have we done? We created a series of elegant technology platforms optimized just for mobile computing. We figured out how to extend battery life, start up the system instantly, conserve precious wireless bandwidth, synchronize to computers all over the planet, and optimize the display of data on a tiny screen.

But we never figured out how to help developers make money. In fact, we paired our elegant platforms with a developer business model so deeply broken that it would take many years, and enormous political battles throughout the industry, to fix it -- if it can ever be fixed at all.

Meanwhile, there is now an alternative platform for mobile developers. It's horribly flawed technically, not at all optimized for mobile usage, and in fact was designed for a completely different form of computing. It would be hard to create a computing architecture more inappropriate for use over a cellular data network. But it has a business model that sweeps away all of the barriers in the mobile market. Mobile developers are starting to switch to it, a trickle that is soon going to grow. And this time I think the flash flood will last.

If you haven't figured it out yet, I'm talking about the Web. I think Web applications are going to destroy most native app development for mobiles. Not because the Web is a better technology for mobile, but because it has a better business model.

Think about it: If you're creating a website, you don't have to get permission from a carrier. You don't have to get anything certified by anyone. You don't have to beg for placement on the deck, and you don't have to pay half your revenue to a reseller. In fact, the operator, handset vendor, and OS vendor probably won't even be aware that you exist. It'll just be you and the user, communicating directly.

Until recently, a couple of barriers prevented this from working. The first was the absence of flat-rate data plans. They have been around for a while in the US, but in Europe they are only now appearing. Before flat-rate, users were very fearful of exploring the mobile web because they risked ending up with a thousand-Euro mobile bill. That fear is now receding. The second barrier was the extremely bad quality of mobile browsers. Many of them still stink, but the high quality of Apple's iPhone browser, coupled with Nokia's licensing of WebKit, points to a future in which most mobile browsers will be reasonably feature-complete. The market will force this -- mobile companies how have to ship a full browser in order to keep up with Apple, and operators have to give full access to it.

There are still huge problems with web apps on mobile, of course. Mobile web apps don't work when you're out of coverage, they're slow due to network latency, and they do not make efficient use of the wireless network. But I believe it will be easier to resolve or live with these technical drawbacks in the next few years than it will be to fix the fundamental structural and business problems in the native mobile app market.

In other words, app development on the mobile web sucks less than the alternative.

Here's a chart to help explain the situation. Imagine that we're giving a numerical score to a platform, rating its attractiveness to developers. Attractiveness is defined as the technical elegance of the platform multiplied by how easy it is for developers to make money from it. The attractiveness score for native mobile app development looks like this over time:



This is why mobile app developers are in trouble. Even though the base of smartphones has been growing, and the platforms themselves have become more powerful, the market barriers have been growing even faster. So attractiveness has been dropping.

Now add in mobile web development:



Based on what I'm hearing from mobile developers, the lines just crossed. The business advantages of mobile web development outweigh its technical limitations. More importantly, if you look at where the lines are going, the advantage of mobile web is going to grow rapidly in the future.

I'm not saying all native mobile development is dead. In fact, we're about to see the release of Apple's native development tools for the iPhone, and as Chris Dunphy just pointed out to me, they are sure to result in a surge of native development for that platform. But I think even a rapidly-growing base of iPhones can't compare to the weight of the whole mobile phone market getting onto a consistent base of browsers.


What it all means

If you're a mobile developer, you should consider stopping native app development and shifting to a mobile-optimized website. That's what Elia did, and he said it's amazing how much easier it is to get things done. Even mobile game developers, who you'd think would be the last to abandon native development, are looking at web distribution (link; thanks to Mike Rowehl for pointing it out).

See if you can create a dumbed-down version of your application that will run over the mobile web. If the answer is yes, do it. If the answer is no, try to figure out what technology changes would let you move to the web, and watch for those changes to happen.

There are exceptions to any rule, and I think it makes sense to keep doing native development if your app can't work effectively over the web, and it's a vertical application so popular that you can get about $50 or more in revenue per copy. In that situation, you probably have enough resources to stay native for the time being. But even you should be monitoring the situation to see when you can switch to the web, because it will cut your expenses.

If you're a mobile customer, make sure your next smartphone has a fully functional browser that can display standard web pages. And get the best deal you can on a flat-rate data plan; you'll need it.

If you're an operator or a handset vendor, get used to life as a dumb pipe. By trying to control your customers and make sure you extract most of the revenue from mobile data, all you've done is drive developers to the Web, which is even harder to control. You could have had a middle ground in which you and mobile developers worked together to share the profits, but instead you've handed the game to the Google crowd.

Congratulations.


Oh, about that obituary...

In loving memory of the mobile applications business. Adoring child of Java, Psion, Palm OS and Windows Mobile; doting parent of Symbian, Access Linux Platform, and S60; constant companion of Handango and Motricity. Scared the crap out of Microsoft in 2000. Passed away from strangulation at the hands of the mobile industry in 2008. Awaiting resurrection as a web service in 2009. In lieu of flowers, the family asks that you make a donation to the Yahoo takeover defense fund.