Nokia and the valley iPhone super-fans

"Nokia's Software Problem", proclaimed an article in Forbes yesterday, that gave voice to excited Silicon Valley adulation over the can't-do-anything-wrong iPhone.

The article contained a report on a recent roundtable organised by Michael Arrington. Arrington himself is quoted in the article as pronouncing,

"I believe that Nokia and Symbian are irrelevant companies at this point."

Part of the problem, apparently, is that:

"Nokia sells hundreds of phone models and supports three different operating systems. No two phones work exactly the same way. Simple models like Nokia's 2610 aren't compatible with the Symbian software used on Nokia's best handsets, such as the N95. Applications written for the iPhone, by contrast, will run on every iPhone."

Now there's such a thing as being a fan of the iPhone. That's understandable. Indeed, there are many great features to the iPhone. It's proved to be an impressive device. What's much less understandable is when this fanship extends into super-fanship of the type reported in this article, which makes people blind to:

• the genuine merits of devices from other manufacturers (such as Nokia);
• the likelihood that these manufacturers will come out with impressive new devices.

(I almost used a less polite word than "super-fanship" here, but hey, let's try to be objective.)

Let's get real. Of course there are big differences between different Nokia phones. Nokia supplies phones catering to very wide varieties of taste, usage model, and pocket. It's no surprise that different software is used to power these different devices. In contrast, up till now, there's really only one kind of iPhone. That makes it relatively easy for developers to write apps that work on (err) every kind of iPhone. However, the current iPhone isn't to everyone's taste. Some people love the big screen form factor, and are happy that there's no keyboard. Others would definitely prefer different form factors and UI mechanisms. Others again would prefer a far less expensive phone. If/when Apple produce a variety of phones comparable to that produced by Nokia, it will be interesting to see exactly how portable the different applications remain.

I have another reservation about the arguments in the Forbes article. The email capabilities of the N95 are criticised as being less immediately usable than those of the iPhone. However, a fairer comparison in this case would be with those Nokia phones that specialise in email connectivity. (Remember, there is more than one kind of Nokia phone...). The recently released E66 and E71 would be better comparators. (See eg here for one review of the E71.)

It's true that we can anticipate very interesting times, as forthcoming new Nokia phones reach the market in the months ahead. Naturally there will be impressive new smartphones from several other suppliers too (running both Symbian and non-Symbian operating systems). We can expect new kinds of user interface models, as different manufacturers build and riff on the innovations produced by their competitors - and bring out some totally new ideas of their own. In achieving these new effects, Symbian-powered phones can take advantage of the following features that are missing (so far) from the iPhone stable: Flash, Java, and the new ScreenPlay graphics architecture.

Looking slightly further afield, the new levels of openness enabled by the Symbian Foundation should have the additional benefits of providing new routes to market for Symbian technology, as well as more rapid collaborative development. If that's a "software problem", it's a problem of the most attractive sort!

Who says that "design by committee" must always be bad?

Writing in EE Times yesterday, comparing the prospects of different mobile operating systems, Rick Merritt has a bit of illicit fun complaining about what he sees as inevitable slowness in the operation of the forthcoming Symbian Foundation:

Trailing behind

...it will take developers as long as two years to meld all the pieces of the unified open-source platform Nokia plans.

The environment will combine the best elements of the UIQ and MOAP(S) environments created by Sony Ericsson and Docomo, respectively. But it will not run existing apps written for those environments.

Worse, the unified Symbian will be defined by a complex set of interworking groups at the Symbian Foundation—including separate councils on feature road mapping, user interface and architecture—drawn from the dozen companies that make up the new foundation. What's the Finnish term for "design by committee"?

This description of the intended collaborative design and review mechanism of the Symbian Foundation implies that such a process is bound to be ineffective. The underlying idea is that committees (or "councils", to use the word from the Symbian Foundation whitepaper) are for losers, and never produce anything good.

It's true that many committees struggle. They can degenerate into talking shops. But not all committees have such a fate.

Indeed, what's proposed for the Symbian Foundation isn't something brand new. It's an evolution of a collaborative design and review mechanism that is already in place, and which has been working well for many years, guiding the evolution of Symbian OS up till now.

For example, Symbian TechCom ("Technology Committee") has met three or four times each year since 1998, and successfully performs many of the tasks slated for the new councils. Symbian TechCom membership includes leading technical specialists and senior product managers from phone manufacturers around the world. What makes TechCom work so well is:

• A series of processes that have evolved over the ten years of TechCom's existence
• Continuity of high-calibre personnel attending the meetings, who have learned how to work together effectively
• Skilled management by the Symbian personnel responsible for the operation of this body
• Excellent preparation before each meeting - and good follow up afterwards.

The skills of running an effective committee may sound boring, but believe me, if done right, they enable better decisions and a new level of combined buy-in to the conclusions eventually reached.

As another example, from further back in my professional career, I remember countless long discussions over aspects of the Psion EPOC suite of software. How should the Agenda app operate in such-and-such a circumstance, exactly what APIs should the OPL scripting language provide, which software features should be centralised to libraries and which left in individual apps...? These questions (and many many others) were decided by a process of debate and eventual consensus. It can be truly said that this software system was "designed by committee". Some people might think that's a criticism. On the contrary, it's a great strength.

In short, collaboration is hard, but when you've got the means to make it work, the outcome will be better (for complex problems) than if strong individuals work independently.

Let me briefly comment on the other two paragraphs from the above extract:

The [Symbian Foundation] environment will combine the best elements of the UIQ and MOAP(S) environments created by Sony Ericsson and Docomo, respectively. But it will not run existing apps written for those environments.

However, it will run existing apps written for the S60 environment - which is the majority implementation of Symbian OS.

it will take developers as long as two years to meld all the pieces of the unified open-source platform Nokia plans.

But there's no need to wait for two years before working with this software. That software will represent a smooth evolution of existing Symbian OS. Symbian OS will continue to be updated regularly, with new releases continuing to appear roughly two or three times each year. Any effort applied by developers to create solutions for these existing and forthcoming releases will be well worth it:

• These solutions will run on the smartphone platform that has by far the largest marketshare
• These solutions will also run on devices running the version of Symbian OS released in due course by the Symbian Foundation.

In conclusion, I don't agree with any implication that the Symbian Foundation is going to result in slower software development. On the contrary, the outcome will be deeper collaboration and swifter innovation.

There’s more to Open Innovation than Open Source

Here’s the challenge: How best to capitalise on the potential innovation that could in theory be created by users and developers who are based outside of the companies that are centrally responsible for a product platform?

This is the question of how best to make Open Innovation work. Recall the following contrasts between Open Innovation and so-called Closed Innovation - taken from the pioneering book by Henry Chesbrough, “Open innovation: the new imperative for creating and profiting from technology”:

The “closed innovation” mindset:

1. The smart people in our field work for us
2. To profit from R&D we must discover it, develop it, and ship it ourselves
3. If we discover it ourselves, we will get to the market first
4. The company that gets an innovation to market first will win
5. If we create the most and the best ideas in the industry, we will win
6. We should control our IP, so that our competitors don't profit from our ideas.

The “open innovation” mindset:

1. Not all the smart people work for us. We need to work with smart people inside and outside our company
2. External R&D can create significant value; internal R&D is needed to claim some portion of that value
3. We don't have to originate the research to profit from it
4. Building a better business model is better than getting to market first
5. If we make the best use of internal and external ideas, we will win
6. We should profit from others' use of our IP, and we should buy others' IP whenever it advances our own business model.

In the modern world of hyper-complex products, easy communication via the Internet and other network systems, and the “Web 2.0” pro-collaboration zeitgeist, it is easy to understand why the idea of Open Innovation receives a lot of support. The challenge, as I said, is how to put these ideas into practice.

It’s tempting to answer that the principal key to successful Open Innovation is Open Source. After all, Open Source removes both financial and contractual barriers that would otherwise prevent many users and external developers from experimenting with the system. (What’s more, “Open Innovation” and “Open Source” share the prefix “Open”!)

However, in my view, there’s a lot more to successful Open Innovation than putting the underlying software platform into Open Source.

To see this, it’s useful to review some ideas from the handy summary presentation by leading Open Innovation researcher Joel West, “Managing Open Innovation through online communities”. Joel makes it clear that there are three keys to making Open Innovation work best for a firm (or platform):

1. Maximising returns to internal innovation
2. Incorporating external innovation in the [platform]
3. Motivating a supply of external innovations.

Let's dig more deeply into the second and third of these keys.

Incorporating external innovation in the platform

The challenge here isn’t just to stimulate external innovation. It is to be able to incorporate this innovation into the platform. That requires the platform itself to be both sufficiently flexible and sufficiently stable. Otherwise the innovation will fragment the platform, or degrade its ongoing evolution.

It also requires the existence of significant skills in platform integration. Innovations offered by users or external developers may well need to be re-engineered if they are to be incorporated in the platform in ways that meet the needs of the user community as a whole, rather than just the needs of the particular users who came up with the innovation in question.

• This can be summarised by saying that a platform needs skills and readiness for software management, if it is to be able to productively incorporate external innovation.

Motivating a supply of external innovations

The challenge here isn’t just to respond to external innovations when they arise. It is to give users and external developers sufficient motivation to work on their ideas for product improvement. These parties need to be encouraged to apply both inspiration and perspiration.

• Just as the answer to the previous issue is software management, the answer to this issue is ecosystem management.

But neither software management nor ecosystem management comes easy. Neither fall out of the sky, ready for action, just by virtue of a platform being Open Source. Nor can these skills be acquired overnight, by spending lots of money, or hiring lots of intrinsically smart people.

Ecosystem management involves a mix of education and evangelism. It also requires active listening, and a willingness by the platform providers to occasionally tweak the underlying platform, in order to facilitate important innovations under consideration by external parties. Finally it requires ensuring that third parties can receive suitable rewards for their breakthroughs – whether moral, social, or financial.

Conclusion: On account of a legacy of more than ten years of trial and error in building and enhancing both a mobile platform and an associated dynamic ecosystem, the Symbian Foundation will come into existence with huge amounts of battle-hardened expertise in both software management and ecosystem management. On that basis, I expect the additional benefits of Open Source will catalyse a dramatic surge of additional Open Innovation around the Symbian Platform. In contrast, other mobile platforms that lack this depth of experience are likely to find that Open Source brings them grief as much as it brings them potential new innovations.

Audacious goals

Martin Sauter asks: Which BHAGs are held by companies in the wireless space?

BHAG (Big Hairy Audacious Goal) is a memorable term introduced by Jim Collins and Jerry Poras in their watershed book, “Built to last: successful habits of visionary companies”. This book was widely read (and debated) within Psion in the mid 1990s. I vividly remember Psion CEO David Potter giving an internal talk on themes from that book relevant to Psion. That talk had a lasting effect.

As Martin mentions, Symbian has been driven for many years by the audacious idea that, one day, Symbian OS will be the most widely used software platform on the planet. But that’s only one of several BHAGs in my mind.

Personally I prefer to say that Symbian’s goal is to be the most widely used and most widely liked software platform on the planet. That’s because I see the latter element as being a key contributor towards the former element. My vision is that people of all dispositions and from all social groups the world over will have good reason to want to use devices running this software – and will be able to afford them.

Here’s another BHAG. Looking towards the activities of the Symbian Foundation (assuming that the regulatory authorities approve the deal that creates this foundation), I envision a time when the ten or so principal package owners for the Symbian Platform will be among the most widely admired and respected software engineers on the planet. Books and articles will frequently write about each of these principal package owners and their finely honed skills in software architecture, software quality, software usability, and large-scale software integration. These articles will celebrate the different backgrounds and different sponsor-companies of these principal package owners (and will no doubt also delve into the multi-faceted inter-personal relationships among this group of world-striding individuals). These individuals will be the pin-up superstars who inspire new generations of emerging world-class software engineers.

I have other large-scale aspirations concerning the future of the Symbian Foundation, but it’s not appropriate to talk about these for the moment. However, what I am happy to share is some audacious ideas for the evolution of the products that I expect to be created, based on Symbian OS, in the 15-25 years ahead:

• The human-computer interaction will sooner or later evolve to become a far more efficient brain-computer interaction. Instead of device owners needing to type in requests and then view the results on a physical screen, it will be possible for them to think requests and then (in effect) intuit the results via inner mental vision. (Just as we all had to learn to type, we’ll have to learn to think anew, to use these improved interfaces, if you see what I mean.) So the rich information world of the internet and beyond will become available for direct mental introspection;
• The smartphone devices of the future will be more than information stores and communications pathways; they will have powerful intelligence of their own. Take the ideas of a spell-checker and grammar-checker and magnify them to consider an idea-checker and an internal coach. So the smartphone will become, for those who wish it, like a trusted best friend;
• Adding these two ideas together, I foresee a time when human IQ and EQ are both radically boosted by the support of powerful mobile always-connected electronic brains and their nano-connections into our biological brains. To be clear, such devices ought to make us wiser as well as smarter, and kinder as well as stronger. For a glimpse of what this might mean, I suggest you take the time to find out what happens to one of the key characters in Kevin Bohacz’s awkwardly titled but engrossing and audacious (I think that’s the right word in this context) novel “Immortality”.

There’s more. In addition to far-reaching ideas about the products that the operation of the Symbian Foundation will eventually enable, it’s also worth considering some far-reaching ideas about the problem-solving capabilities of the robust yet transparent open collaborative methods expected to be deployed by the Symbian Foundation (methods that build on best practice established in the first ten years of Symbian’s history). In other words, the potential benefits of richly skilled open collaboration go far beyond the question of how to create world-beating smartphones. As highlighted in the tour-de-force “The upside of down” by the deeply thoughtful Canadian researcher Thomas Homer Dixon, the profound structural issues facing the future of our society (including climate change, energy shortage, weapons proliferation, market instability, fundamentalist abdication of rationality, and changing population demographics) are so inter-twined and so pervasive that they will require a new level of worldwide collaboration to solve them. Towards the end of his book, Homer-Dixon points to the transformative potential of open-source software mechanisms for inspiration for how this new level of collaboration can be achieved. It’s an intriguing analysis. Can open source save the world? Watch this space.

Footnote: Having the right BHAG is an important first step towards a company making a dent in the universe. But it’s only one of many steps. Although “Built to last” is a fine book, I actually prefer Jim Collin’s later work, “From good to great: why some companies make the leap ... and others don't”. In effect, “From good to great” is full of acutely insightful ideas on how companies can make progress towards their BHAGs.

Connectivity failure

Sometimes you only really appreciate the value of a service when you can no longer access it.

For around the last four years, I've enjoyed having my corporate email pushed onto my smartphone. That means, wherever I've been, I've had a good idea of the items waiting for me when I open my email application on my PC - and I've very often been able to answer emails from my phone (and/or write new emails), without needing to trouble my PC. It's been a great productivity boost.

However, yesterday I crossed over the border from Peru to Bolivia, as part of a long anticipated two-week long family holiday in South America, and all the GPRS connectivity to my phone ceased. I've been in a state of mild shock ever since. I've not been able to access the services that I've come to take for granted in previous holidays and business travel around the world. That includes BlackBerry push email connectivity, frequent mobile access to information sites such as the BBC, Wikipedia, Google, and Facebook, as well as interaction with various mobile forums or discussion groups.

I'm sure I'll enjoy the sights in and around La Paz over the next 48 hours. For example, there's the ruins of Tiwanaku, a pre-Inca city which is said to have been, around 700AD, the largest city anywhere in the world. But I'm also sure there will be many moments during these 48 hours when I'll be instinctively reaching for my smartphone, ready to look up some information snippet that will provide more context to what I'm seeing with my own eyes or hearing from the tourguide, and then I'll realise that, for the time being, I'm cut off from that richer information world.

Footnote: My internet connectivity is provided by Vodafone UK. None of the network operators that I can see from my phone, here in Bolivia, seem to have working GPRS roaming back to Vodafone. If anyone knows differently, I'll be delighted to hear from you!

Two fallacies on the value of software

Software is everywhere. Unfortunately, buggy software is everywhere too.

I'm writing this en route to a family holiday in South America - four countries in 15 days. The holiday starts with a BA flight across the Atlantic. At first sight, the onboard "highlife" entertainment system is impressive. My son asks: do they really have all these music CDs and movies available? "Moore's Law in action" was my complacent reply.

The first sign of trouble was when the flight attendant welcome announcement, along with the usual stuff about "if you sleep, please ensure your fastened seat belt is visible on top of your blanket", contained a lengthy dire warning that no one should try to interact with the video screens in any way, while the system was going through its lengthy startup activity. Otherwise the system would be prone to freeze or some other malfunction.

It seems the warning was in vain. From my vantage point in the very back row of seats on the plane, as the flight progressed I could see lots of passengers calling over the flight attendants to point out problems with their individual systems. Films weren't available, touchscreen interactions were random, etc. The attendants tried resetting individual screens, but then announced that, because so many screens were experiencing problems, the whole system would be restarted. And, by the way, it would take 30 minutes to reboot. All passengers would need to keep their hands off the screen throughout that period of time, even through many tempting buttons advertising features of the entertainment system would be displayed on the screen during that time.

One flight attendant forlornly tried to explain the situation to me: "it's like when you're starting up a computer, you have to wait until it's completely ready before you can start using it".Well, no. If software draws a button on the screen, it ought to cope with a user doing what comes naturally and pressing that button. That's one of the very first rules of GUI architecture. In any case, what on earth is the entire system doing, taking 30 minutes to reboot?

To be fair, BA's inflight entertainment system is hardly alone in having this kind of defect. I've often seen various bizarre technobollocks messages scrolling on screens on the back of aeroplane seats. I also remember a Lufthansa flight in which the software controlling the reclining chairs (I was flying business class on that occasion) was clearly faulty - it would freeze, and all subsequent attempts to adjust the chair position would be ignored. The flight attendants that day let me into the secret that holding down three of the buttons simultaneously for a couple of seconds would forcibly reboot the system. It was a useful piece of knowledge!

And to be fair, when the system does work, it's great to have in-flight access to so much entertainment and information.

But I draw the following conclusion: Moore's Law is not enough. Moore's Law enables enormous amounts of data - and enormous amounts of software - to be stored on increasingly inexpensive storage mediums. But you need deep and wide-ranging skills in software creation if the resulting compex systems will actually meet the expectations of reasonable end users. Software development, when done right, is going to remain as high value add for the foreseeable future.

"Moore's Law" is enough is the first fallacy on the value of software. Hot on its heels comes a second idea, equally fallacious:

The value of software is declining towards zero.

This second fallacy is wrapped up with a couple of ideas:

1. The apparent belief of some people that all software ought to be sold free-of-charge
2. The observation that the price of a fixed piece of software does tend to decline over time.

However, the second observation misses the important fact that the total amount of software is itself rapidly increasing - both in terms of bulk, and in terms of functionality and performance. Multiply one function which is slowly declining (the average price of a fixed piece of software) with another one that is booming (the total amount of all software) and you get an answer that refutes the claim that the value of software itself is declining towards zero.

Yes, it's reasonable to expect that individual pieces of software (especially those that have stopped evolving, or which are evolving slowly) will tend to become sold for free. But as new software is made available, and as software keeps on being improved, there's huge scope for value to be made, and for a portion of that value to be retained by first-rate developers.

Footnote: Even after the BA entertainment system restarted, there were still plenty of problems. Fast-forwarding through a film to try to get to the previous location was a very hit-and-miss affair: there was far too much latency in the system. The team responsible for this system should be hanging their heads in shame. But, alas, they're in plenty of company.

Human obstacles to audacious technical advances

[A] French noblewoman, a duchess in her eighties, ..., on seeing the first ascent of Montgolfier's balloon from the palace of the Tuilleries in 1783, fell back upon the cushions of her carriage and wept. "Oh yes," she said, "Now it's certain. One day they'll learn how to keep people alive forever, but I shall already be dead."

Throughout history, individual humans have from time to time dared to dream that technological advances could free us from some of the limitations of our current existence. Fantastic tales of people soaring into the air, like birds, go back at least as far as Icarus. Fantastic tales of people with lifespans exceeding the biblical "three score years and ten" go back at least as far as, well, the Bible. The French noblewoman mentioned above, in a quote taken from Lewis Lapham's 2003 Commencement speech at St. John's College Annapolis, made the not implausible connection that technology's progress in solving the first challenge was a sign that, in time, technology might solve the second challenge too.

Mike Darwin made the same connection at an utterly engrossing UKTA meeting this weekend. Since the age of 16 (he's now 53), Mike has been trying to develop technological techniques to significantly lower the temperature of animal tissue, and then to warm up the tissue again so that it can resume its previous function. The idea, of course, is to enable the cryo-preservation of people who have terminal diseases (and who have nominally died of these diseases) until reviving them at such time in the future when science now has a cure for that disease.

Mike compared progress with the technology of cryonics to progress with the technology of powered manned flight. Renowned physicist Lord Kelvin had said as late as 1896 that "I do not have the smallest molecule of faith in aerial navigation other than ballooning". Kelvin was not the only person with such a viewpoint. Even the Wright brothers themselves, after some disappointing setbacks in their experiments in 1901, "predicted that man will probably not fly in their lifetime". There were a host of detailed, difficult engineering problems that needed to be solved, by painstakingly analysis. These included three kinds of balance and stability (roll, pitch, and yaw) as well as lift, power, and thrust. Perhaps it is no surprise that it was the Wright brothers, as accomplished bicycle engineers, that first sufficiently understood and solved this nexus of problems. Eventually, in 1903, they did manage one small powered flight, lasting just 12 seconds. Later that day, a flight lasted 59 seconds. That was enough to stimulate much more progress. Only 16 years later, John Alcock and Arthur Brown flew an airplane non-stop across the Atlantic. And the rest is history.

For this reason, Mike is particularly keen to demonstrate incremental progress with suspension and revival techniques. For example, there is the work done by Brian Wowk and Gregory Fahy and others on the vitrification and then reanimation of rabbit kidneys.

However, the majority of Mike's remarks were on topics different from the technical feasibility of cryonics. He spoke for over two hours, and continued in a formal Q&A session for another 30 minutes. After that, informal discussion continued for at least another 45 minutes, at which time I had to make my excuses and leave (in order to keep my date to watch Dark Knight that evening). It was a tour-de-force. It's hard to summarise such a lengthy passionate yet articulate presentation, but let me try:

1. Cryonics is morally good
2. Cryonics is technically feasible
3. By 1968, Cryonics was a booming enterprise, with many conferences, journals, and TV appearances
4. However, Cryonics has significantly failed in its ambitions
5. Unless we understand the real reasons for these failures, we can't realise the potential benefits of this program
6. The failures primarily involve people issues rather than technical issues
7. In any case, we should anticipate fierce opposition to cryonics, since it significantly disrupts many core elements of the way society currently operates.

The most poignant part was the description of the people issues during the history of cryonics:

• People who had (shall we say) unclear ethical propriety ("con-men, frauds, and incompetents")
• People who failed to carry out the procedures they had designed - yet still told the world that they had followed the book (with the result that patients' bodies suffered grievous damage during the cryopreservation process, or during subsequent storage)
• People who were technically savvy and emotionally very committed yet who lacked sufficient professional and managerial acumen to run a larger organisation
• People who lacked skills in raising and handling funding
• People who lacked sufficient skills in market communications - they appeared as cranks rather than credible advocates.

This rang a lot of bells for me. The technology industry as a whole (including the smartphone industry) often struggles with similar issues. The individuals who initially come up with a great technical idea, and who are its first champions, are often not the people best placed to manage the later stages of development and implementation of that idea. The transition between early stage management and any subsequent phase is tough. But it is frequently essential. (And it may need to happen more than once!) You sometimes have to gently ease aside people (ideally at the same time finding a great new role for them) who are your personal friends, and who are deeply talented, but who are no longer the right people to lead a program through its next stage. Programs often grow faster than people do.

I don't see any easy answers in general. I do agree with Mike on the following points:

• A step-by-step process, with measurable feedback, is much preferable to reliance on (in essence) a future miracle that can undo big mistakes made by imprecise processes today(this is what Mike called "the fallacy of our friends in the future");
• Feedback on experiments is particularly important. If you monitor more data on what happens during the cryopreservation process, you'll discover more quickly whether your assumptions are correct. Think again about the comparable experiences of the Wright brothers. Think also of the importance of carrying out retrospectives at regular intervals during a project;
• Practice is essential. Otherwise it's like learning to drive by just studying a book for six months, and then trying to drive all the way across the country the first time you sit in the drivers seat;
• The quality of the key individuals in the organisations is of paramount importance, so that sufficient energies can be unleashed from the latent support both in the organisation and in wider society. Leadership matters greatly.

Footnote: I first came across the reference to the tale of the venerable French duchess in the commentary to Eliezer Yudkowsky's evocative online reminiscences regarding the death of his 19-year old brother Yehuda Nattan Yudkowsky.