dw2

8 September 2008

Mobile web browsing wide open

Filed under: browsers, Opera, Webkit — David Wood @ 8:59 pm

While the blogosphere has, understandably, been paying a lot of interest to one new web browser – Chrome, from Google – I’ve unexpectedly found myself paying a lot of attention to a different web browser: Opera Mini.

Opera Mobile was, for several years, my mobile web browser of choice. Whichever smartphone was in my pocket – eg Sony Ericsson, Samsung, Nokia… – I would download the latest Opera Mobile, and make heavy use of it.

This changed when Nokia started shipping the Webkit browser on their S60 3rd edition phones. Although I kept, for a while, both Opera Mobile and Webkit installed, I found myself using the Webkit browser more and more. The attraction was that, with its intelligent scrolling and “complete page” view, it served up web pages in very similar fashion to how they appeared on desktop browsers. It has been described as “bringing real PC web-browsing to the smartphone”.

However, I confess that I’ve been having occasional problems with the Webkit browser on my Nokia E61i. Pages often take quite a long time to load – and then re-load, with more text, once the stylesheet has been downloaded – but with an awkward gap in between, when the screen is blank. Worse, the S60 Webkit browser crashes rather too often for my liking – sometimes (causing real frustration) at the end of a lengthy process while I’ve been navigating to a page I particularly want to view. Whilst it’s a great piece of software, it’s not perfect.

Last week, I decided it was time to update the device software on my E61i. Using the Nokia Software Updater (as prompted by the Nokia PC Suite), I moved up from ROM version 1.0633 to 2.0633. The process went smoothly. At the same time, I cleaned out lots of add-on software that I no longer used. So my E61i was looking fresh and new. Alas, after the upgrade, the Webkit browser software let me down again – with an Odeon cinema webpage disappearing just as I was about to check possible film times for later that week.

My son – who at the age of 17 going on 27 is already a smartphone veteran – took the opportunity to offer me some of his well-honed teenage wisdom: he told me I should switch to Opera Mini. That’s Opera Mini, not Opera Mobile – it’s a free app that is funded (like Firefox) from a share of advertising revenues via links with Google.

It wasn’t the first time my son had given me that advice. I’d been resisting it, because:

  • The “Mini” in the name made it sound to me like the application was underpowered
  • I knew it was written in Java, and I thought its performance would, therefore, be less than that of an app written in C++.

However, I noticed a lot of praise in internal Symbian discussion databases for Opera Mini, so I decided to take the plunge. Downloading and installing the app was simplicity itself: I googled “Opera mini”, and the very first site offered a download link. The download was surprisingly quick – reflecting the fact that the app itself is quite small. Although there was a slight delay when the app started running, the subsequently performance was pleasantly fast. I can well believe the claim in Wikipedia that, with Opera Mini, data transfer is “about two to three times faster“.

The next surprise was how well the browser coped with sites that, previously, required me to wait until “the re-load after the initial load”, before displaying text in (for example) right-hand columns on the screen. For example,

  • Recently the BBC news page changed over to this kind of layout scheme
  • Similarly an upgrade to the Atlassian Confluence engine used for various wikis at Symbian also changed over to this kind of layout scheme.

With a fast connection and a strong CPU on a desktop, web pages like those above load quickly enough. But on my E61i, I had been used to having to wait quite a while, before text in right hand columns on the screen finally became visible. However, because Opera Mini uses a very different mechanism (assembling the page server-side, before compressing it and sending it down to the client), this text is now available to me much more quickly. That’s an unexpected bonus.

And I keep finding other UI features and application functionality in Opera Mini that, likewise, pleasantly surprise me – such as an optimised interface to search on Wikipedia or on Amazon.

After a couple of days, I did the previously unthinkable, and re-assigned one of the E61i application hot keys, away from Webkit, to Opera Mini. And I still haven’t looked back.

The morale of this story, for me, is that the mobile web browsing competition is still wide open. It’s another reminder of one of the central characteristics of an open platform: an application which looks like being the #1 in its field at any given time, might be overtaken in the future – provided the underlying platform serves up a level playing field. And the real winner of this kind of open competition is the end user. In order to remain #1, an application has to keep on providing quality innovations – quickly!

Of course, there’s not just Opera and Webkit in the mobile web-browser space. There’s also Netfront and Skyfire, among many others, and we can expect mobile versions of Chrome and Mozilla to make entrances too at some stage.

4 September 2008

More TechCrunch reality-distortion on iPhone vs Symbian OS

Filed under: iPhone, results — David Wood @ 8:04 am

Following fast on the heels of the recent attention-grabbing declaration by TechCrunch’s Michael Arrington that “Nokia and Symbian are irrelevant companies at this point“, TechCrunch has published another piece of contentious analysis on iPhone vs. Symbian OS market share. On this occasion, the author is Don Reisinger.

The piece starts with the graph which I’ve reproduced above. The red line at the top shows six figures for Symbian OS quarterly sales – five of which are as already published by Symbian, and the sixth, for July through September this year, is speculation from TechCrunch. The blue-line projections of sales for iPhone in that period are similarly speculative. (Interestingly, the filename for this graph on the TechCrunch site is “iphone-v-symbian-real“. Real, that is, apart from the future projection.)

Don reassuringly writes, “I assume Symbian OS will only grow at 5 percent each quarter, since it is a mature technology”. Then he goes on to have some fun and games by considering what will happen if iPhone sales grow steadily, for the next few years (in some cases looking all the way out to 2012), at either 300% per annum, 100% per annum, or 50% per annum.

The article ends on a decidedly duff note:

But one thing is certain: the Symbian OS is simply not selling nearly as well as the rest of the industry and the iPhone 3G is outpacing every other smartphone on the market.

No. Symbian OS is currently outselling all other smartphone operating systems added together. This piece of the article makes explicit a confusion that lies under the surface of much of the rest of the article – a confusion between growth and actual value. (Mathematically, the difference between dy/dt and y itself.) It’s true that the recent growth in Symbian OS sales has slowed down, and that the iPhone, starting from a much lower base, has achieved higher growth percentages. But that’s a very different thing.

In the past, I’ve done a bit of sales growth projection myself. In November 2004, I wrote the following words as part of Chapter 1 “At the heart of the smartphone revolution” in my book, “Symbian for software leaders: principles of successful smartphone development projects” that went on sale the following year:

It’s no surprise that the commercial market for smartphones has grown by at least 100% in each of the last three years. There are good reasons why this growth should continue throughout at least the next three years – reasons grounded in technological progress, networking dynamics, and market evolution:

  • Moore’s Law means that, for the same cost, more and more powerful hardware can be supplied; tomorrow’s smartphones will have as much computing power as yesterday’s PCs
  • New generations of phone networks (3G, 3.5G, 4G, and so on) will allow the speedy transmission of ever larger amounts of data, both satisfying and whetting still more user demand
  • More powerful devices and more powerful networks jointly enable the provision of attractive add-on services, created by third parties, which in turn increase the market pull for devices capable of supporting such services
  • The cumulative operation of software means that new services and applications can piggy-back on the functionality and power of previous services and applications, with striking, innovative results
  • Many of these services are community-oriented: the more people who take part in these services, the more valuable these services become (this is sometimes called Metcalfe’s Law)
  • As people discover the benefits of mobile online gaming, mobile commerce, and so on, they will spread this message by word-of-mouth, so that the communities of smartphone users swell in size
  • Phone network operators have a strong interest in ensuring that phone users
    are attracted to make regular use of services that involve greater amount of
    data transfer (and which therefore attract higher fees).

Sales of Symbian OS phones up to the time I wrote these words had in fact been increasing, annually, at greater than 100%. Sales of 2.0 million units in 2002 had soared to 6.7 million in 2003 and again to 14.4 million in 2004. Similar percentage growth rates continued after that – for a time. Sales were 34 million in 2005, 52 million in 2006, and 77 million in 2007. Past performance (ie growth over 100% per annum) is no sure guide to future results! On the other hand – just to reiterate the point – declining sales growth is not the same thing as declining sales!

A better guide to future sales prospects is probably the number of active phone projects under development. Symbian reports these figures quarterly too. As stated in our press release, there were 92 Symbian phone models (to our knowledge) in development at the end of June. That’s a 48% increase from the same figure last year – 62 models. It’s also by some way the largest value this figure has been.

Another sign (admittedly, again imperfect) of potential increased volume sales is in the increased revenues earned by Symbian’s professional services department. To quote from the press release,

76% growth in consulting services from £5.1 million in H1 2007 to £9.0 million in H1 2008 driven by a demand for Symbian services resulting from a broader and deeper range of customer mobile phone products in the pipeline.

What factors will, instead, govern future sales of iPhones? I’ve previously discussed some of the potential breakthrough features in this device. But what prevents these features being emulated by products from competitors – including some of the 92+ new products under development using Symbian OS?

Steve Litchfield of AllAboutSymbian has just published a thought-provoking article that touches on this topic, “Joined-up applications and The Way Ahead“. Steve is a high-integrity, thoughtful, and immensely knowledgeable writer, with deep all-round hands-on knowledge of numerous smartphones, so I have a lot of respect for his opinions. Steve writes:

Now there are four good reasons why [the iPhone] platform is relatively novel:

  1. – the iPhone has a large (320 by 480, 4″), patented capacitive display that’s touch-sensitive and yet has super visibility in all light conditions, something that was previously impossible.
  2. – the iPhone is almost always on a flat rate, all you can eat data tariff, which means applications can assume full Internet connectivity, bandwidth no object.
  3. – the iPhone has a built-in, callable version of Google Maps and a good YouTube client.
  4. – the iPhone is fully location aware, using cell towers, Skyhook Wi-Fi location (this works exceptionally well in towns) and (in the 3G model) full GPS.

(I’m tempted to add a fifth reason – that the Mac-loving, iPhone-loving crowd have more imagination and creativity than their equivalents in the Windows and Symbian worlds).

Then Steve reviews some of the particularly attractive (“jaw-droppingly well conceived”) downloadable applications which have become available for the iPhone. Finally, Steve comes back to the four points he made earlier:

…here’s the kicker – there’s no reason why similar levels of imagination and integration shouldn’t happen on S60 and Symbian – with Maps/Chat/Ovi, progress is being made. But if I’m honest, Apple’s iPhone platform has already seized the technological high ground – in this area, at least.

What about my four reasons (above) why the iPhone has engendered this sort of enthusiastic solution? How can they apply in the Symbian world?

  1. – the unusual E90 aside, the largest screen sizes in common use in the S60 world are 2.8″, half the size of the iPhone’s display (in terms of area) and many phone displays are 2.4″ or even 2.2″ (which works out as just over a quarter the area of the iPhone’s). Bigger displays are needed and of higher resolution. No doubt these will come, and at least outdoor contrast is very good on most S60 devices, but in the meantime it’s again advantage iPhone.
  2. – flat rate data tariffs are the exception rather than the rule for most S60 phone owners. I’d like to see every contract come with unlimited data and
    every pay-as-you-go SIM allowed unlimited data for a day for a nominal fee (e.g. £1). Until people reach the point where they don’t worry about how much Internet is costing them on their mobiles, they’ll be suspicious and, again, at a disadvantage to the more expensive, but worry-free, iPhone.
  3. – Google Maps is already native S60, which is good, although it’s not as slick as the iPhone implementation. But YouTube playback is a toss-up between the low resolution official Java client or the third party and slicker (but often unreliable) S60 app Mobitubia. Yet again, advantage iPhone.
  4. – with almost every S60 device now coming with built-in GPS and an OS that allows positioning to be accessed from any application, location useage is simply down to the skill and imagination of developers. We’re starting to see S60 apps that use GPS, but it’s still early days, it seems.

I don’t want to sound too negative – I love my S60 phones and I love the high performance, high speed nature of Symbian OS. But credit where credit’s due – hopefully you’ll agree that the above two iPhone application examples are nothing short of inspiring – whichever platform you use or develop for.

The killer question is: can the successes of the iPhone indeed inspire similar applications, services, and devices from competing platforms? Can other platforms support devices that have a similary gorgeous screen, a first rate web browser, flat rate data tariffs, and rich callable middleware? If this is possible, the TechCrunch sales projections are dubious.

Personally, I don’t think these successes can be fully emulated by in-house proprietary operating systems – but the answer changes when the underlying software system becomes sufficiently sophisticated, flexible, and robust. That is, feature phones cannot compete with these devices – but smartphones can. With these complex products, innovation requires underlying strength. Maturity, as Don Reisinger calls it, doesn’t need to mean sales stasis: it can mean the basis for very significant new innovation and new sales spurts – especially when coupled with the kind of restructuring that will follow from Nokia’s planned acquisition of Symbian and the formation of the open source Symbian Foundation.

3 September 2008

Restrictions on the suitability of open source?

Filed under: Open Source, security, usability — David Wood @ 8:56 am

Are there restrictions on the suitability of open source methods? Are there kinds of software for which closed source development methods are inherently preferable and inherently more likely to succeed?

These questions are part of a recent discussion triggered by Nokia’s Ari Jaaksi’s posting “Different ways and paradigms” that looked for reasons why various open source software development methods might be applicable to some kinds of project, but not to others. As Ari asks,

“Why would somebody choose a specific box [set of methods] for their products?”

One respondent suggested that software with high security and high quality criteria should be developed using closed source methods rather than using open source.

Another stated that,

I firmly believe ‘closed’ source is best route for targeting consumers and gaining mass appeal/ acceptance.

That brings me back to the question I started with. Are there features of product development – perhaps involving security and robustness, or perhaps involving the kinds of usability that are important to mainstream consumers – to which open source methods aren’t suited?

Before answering that, I have a quick aside. I don’t believe that open source is ever a kind of magic dust that can transform a failing project into a successful project. Adopting open source, by itself, is never a guarantee of success. As Karl Fogel says in the very first sentence of Chapter 1 in his very fine book “Producing open source software: how to run a successful free software project“,

“Most free projects fail.”

Instead, you need to have other project fundamentals right, before open source is likely to work for you. (And as an aside to an aside, I believe that several of the current attempts to create mobile phone software systems using open source methods will fail.)

But the situation I’m talking about is when other project fundamentals are right. In that case, my question becomes:

Are there types of software for which an open source approach will be at odds with the other software disciplines and skills (eg security, robustness, usability…) that are required for success in that arena.

In one way, the answer is trivial. The example of Firefox resolves the debate (at least for some parameters). Firefox shows that open source methods can produce software that scores well on security, robustness, and usability.

But might Firefox be a kind of unusual exception – or (as one of the anonymous respondents to Ari Jaaksi’s blog put it) “an outlier?” Alternatively – as I myself believe – is Firefox an example of a new trend, rather than an irrelevant outlier to a more persistent trend?

Regarding usability, it’s undeniable that open source software methods grew up in environments in which developers didn’t put a high priority on ease-of-use by consumers. These developers were generally writing software for techies and other developers. So lots of open source software has indeed scored relatively poorly, historically, on usability.

But history needn’t determine the future. I’m impressed by the analysis in the fine paper “Usability and Open Source Software” by David M. Nichols and Michael B. Twidale. Here’s the abstract:

Open source communities have successfully developed many pieces of software although most computer users only use proprietary applications. The usability of open source software is often regarded as one reason for this limited distribution. In this paper we review the existing evidence of the usability of open source software and discuss how the characteristics of open-source development influence usability. We describe how existing human-computer interaction techniques can be used to leverage distributed networked communities, of developers and users, to address issues of usability.

Another very interesting paper, in similar vein, is “Why Free Software has poor usability, and how to improve it” by Matthew Paul Thomas. This paper lists no less than 15 features of open source culture which tend to adversely impact the usability of software created by that culture:

  1. Weak incentives for usability
  2. Few good designers
  3. Design suggestions often aren’t invited or welcomed
  4. Usability is hard to measure
  5. Coding before design
  6. Too many cooks
  7. Chasing tail-lights
  8. Scratching their own itch
  9. Leaving little things broken
  10. Placating people with options
  11. Fifteen pixels of fame
  12. Design is high-bandwidth, the Net is low-bandwidth
  13. Release early, release often, get stuck
  14. Mediocrity through modularity
  15. Gated development communities.

As Paul says, “That’s a long list of problems, but I think they’re all solvable”. I agree. The solutions Paul gives in his article are good starting points (and are already being adopted in some projects). In any case, many of the same problems impact closed-source development too.

In short, once usability issues are sufficiently understood by a group of developers (whether they are adopting open source or closed source methods), there’s no inherent reason why the software they create has to embody poor usability.

So much for usability. How about security? Here the situation may be a little more complex. The online book chapter “Is Open Source Good for Security?” by David Wheeler is one good starting point. Here’s the final sentence in that chapter:

…the effect on security of open source software is still a major debate in the security community, though a large number of prominent experts believe that it has great potential to be more secure

The complication is that, if you start out with software that is closed source, and then make it open source, you might get the worst of both worlds. Incidentally, that’s one reason why the source code in the Symbian Platform isn’t being open-sourced in its entirety, overnight, on the formation (subject to regulatory approval) of the Symbian Foundation. It will take some time (and the exercise of a lot of deep skill), before we can be sure we’re going to get the best of both worlds, rather than the worst of both worlds.

31 August 2008

Intellectual property and open source

Filed under: books, GPL, Intellectual property, Open Source — David Wood @ 7:17 pm

I’ve just finished reading a third book, within two months, on the topic of open source licensing. The three books are:

  1. Heather Meeker’s “The Open Source Alternative: Understanding Risks and Leveraging Opportunities” – which I reviewed here;
  2. Lawrence Rosen’s “Open Source Licensing: software freedom and intellectual property law” – which I reviewed here;
  3. Van Lindberg’s “Intellectual property and open source: a practical guide to protecting code“.

My headline summary is that all three books are well worth reading. They overlap to an extent, but they come at their shared subject from very different viewpoints, so each book has lots of good material that you won’t find in the others.

Van Lindberg targets his book at software engineers. He uses many analogies between legal concepts and deeply technical software engineering concepts. For example (to give a flavour of many of the clever pieces of writing in the book):

“One way to think about private goods is to analogize them to locks or mutexes in a multithreaded program. A number of different threads may want to use a protected resource, but control of the lock around the resource is rivalrous…”

Somewhat unexpectedly, the first half of the book hardly mentions open source. There’s good reason for this. The first seven chapters of the book cover the basic principles of intellectual property (IP), including patents, copyrights, trademarks, trade secrets, licences, and contracts. I found the very first chapter to be particularly engrossing, as it set out the philosophical foundations for IP. Van Lindberg highlighted the utilitarian justification for IP, in terms of legal measures to counter what would otherwise be two sorts of market failures:

  • “The cost of creating knowledge is high, but the cost of consuming it is low…. Therefore there is a societal incentive to not create as much knowledge as we would ideally like to have” (hence the utilitarian rationale for copyright)
  • “Secrets are more valuable to you personally, but shared knowledge is more valuable to society…. The resource is valuable to you because you have a key, but it is worthless to everyone else” (hence the utilitarian rationale for patents).

As I said, the very first chapter was particularly engrossing, but I thought the other early chapters dragged a bit. Although all the material was interesting, there were rather too many details for my liking.

Chapter eight (“The economic and legal foundations of open source software”) went back to philosophical principles, in an attempt to pinpoint what makes open source different from proprietary software. The difference, according to Van Lindberg, is that:

  • Proprietary software is driven by corporate business goals (which inevitably involve profit-maximisation, and therefore – he claimed – a tension between what’s best for the customers and what’s best for the shareholders)
  • Open source software is driven by cooperative goals, in which the goals of the customers have primacy. (Note the difference between the similar-looking words corporate and cooperative.)

This chapter also runs a pretty compelling extended comparison between proprietary software and open source software, on the one hand, and banks and credit unions, on the other hand. Again, the first member of each pair is driven by shareholder goals, whereas the second member of each pair is driven by customer goals (the legal owners are the same people as the customers).

The primary task of open source licences, according to this analysis, is to support cooperation. In more detail, Van Lindberg says that open source licences are intended to solve the “Programmer’s Dilemma” version of the famous and well-known “Prisoner’s Dilemma” problem from game theory:

“Open source licences serve two functions in a game-theoretic context. First, they allow programmers to signal their cooperative intentions to each other. By placing their code under a licence that allows cooperation, programmers indicate to their peers that they are willing to participate in a cooperative solution. Second… licences are based in copyright law, which allows the original developer to dictate (to some extent) the users and uses of his code. The legal penalties associated with copyright violations change the decision matrix for other programmers, leading to a stable cooperative (and optimal) solution.”

This (like everything else in the book) is thought-provoking. But I’m not fully convinced. I think this puts too much importance onto the licence aspect of open source. Yes, picking a good licence is important – but it’s insufficient to guarantee the kind of cooperative behaviour that will make an open source project a real success. And as I’ve argued elsewhere, picking the right licence is no guarantee against the software fragmenting. But despite this quibble, I still think the ideas in this chapter deserve wide readership.

The second half of the book changes gear. With the first eight chapters having carefully outlined the underlying legal framework, the remaining six chapters walk through the kind of real-life IP concerns that will face someone (whether an individual developer, or a company) who wants to become involved in an open source project:

  • Issues with standard employment contracts that probably specify that everything you work on – even in your spare time – belongs to your company, and which you therefore are not free to assign to an open source project
  • General guidelines on choosing between some of the more popular open source licences
  • Legal complications over how to accept patches and other contributions, from outsiders, into your project
  • Particular issues with the GPL
  • Reverse engineering
  • Creating a non-profit organisation or foundation (recommended if your project becomes larger).

There’s lots of good advice here. Every chapter of this part of the book has important material – but I was slightly disappointed with some parts. For example, given the careful attention to patents in the first half of the book (where two chapters were devoted to this topic), I was expecting more analysis of how some of the major open source licences differ in their approach to patent licences and patent retaliation clauses. On reflection, that’s something that the other two books (ie by Meeker and Rosen) handle better.

The chapter on the issues with the GPL confirmed and extended the opinion about that licence which I’d picked up from my previous reading: the interpretation of the GPL is subject to great uncertainty over ambiguities. The chapter includes a lengthy “Questions and answers” section, to which the answer to nearly every question is “Maybe” or “It depends”. (Apart from the last question, which is “Can I depend on the answers in this Q&A to keep me out of trouble?”; the answer to this is “No, this is our best understanding of copyright law as it stands right now, but it could change tomorrow – and nobody really knows…”)

Giving more evidence for this view of the ambiguities surrounding the GPL, Van Lindberg mentions an essay by Matt Asay, “A Funny Thing Happened on the Way to the Market“. Here’s an extract from that essay:

“I asked two prominent representatives of the Free Software Foundation – Eben Moglen, general counsel, and Richard Stallman, founder – to clarify thorny issues of linkage to GPL code, and came up with two divergent opinions on derivative works in specific contexts…”

“…it is telling how widely their responses diverge – there appear to be no definitive answers to the question of what constitutes a derivative work under the GPL, not even from the holders of the licenses in question.”

This looks decisive, but it could be argued that this quote from Matt Asay is itself misleading, since Matt’s article goes on to state that:

“Fortunately, as I will detail below, this issue has largely gone away, as it has become accepted practice to dynamically link to GPL code [without that code becoming part of the GPL program]. Linus Torvalds helped to build momentum for such a reading of the GPL. While some argue that kernel modules, including device drivers, must be GPL, Torvalds has stated: This [GPL] copyright does *not* cover user programs that use kernel services by normal system calls – this is merely considered normal use of the kernel, and does *not* fall under the heading of ‘derived work.’“

However, Van Lindberg seems to be right that the official FAQ about the GPL, maintained by the Free Software Foundation, advocates a stricter interpretation:

“Q: Can I release a non-free program that’s designed to load a GPL-covered plug-in?

“A: It depends on how the program invokes its plug-ins. For instance, if the program uses only simple fork and exec to invoke and communicate with plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program.

“If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.

“If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

“Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking.”

Do these ambiguities over the GPL really matter? It’s hard to be sure, but I’m personally glad that the Symbian Foundation plans to adopt a licence – the EPL – which avoids these issues.

I’m also glad to have taken the time to read this book – it’s helped my understanding grow, in many ways.

Footnote: My thanks go to Moore Nebraska for drawing my attention to the Van Lindberg book.

30 August 2008

Anticipating the singularity

Filed under: Moore's Law, Singularity — David Wood @ 10:05 am

“Let an ultraintelligent machine be defined as a machine that can far surpass all the intellectual activities of any man however clever. Since the design of machines is one of these intellectual activities, an ultraintelligent machine could design even better machines; there would then unquestionably be an ‘intelligence explosion,’ and the intelligence of man would be left far behind. Thus the first ultraintelligent machine is the last invention that man need ever make.”

The first time I read these words, a chill went down my spine. They were written in 1965 by IJ Good, a British statistician who had studied mathematics at Cambridge University pre-war, worked with Alan Turing and others in the highly secret code-breaking labs at Bletchley Park, and was involved in the creation of the Colossus computer (“the world’s first programmable, digital, electronic, computing device“).

The point where computers become better than humans at generating new computers – or (not quite the same thing) the point where AI becomes better than humans at generating new AI – is nowadays often called the singularity (or, sometimes, “the Technological Singularity“). To my mind, it’s a hugely important topic.

The name “Singularity” was proposed by maths professor and science fiction author Vernor Vinge, writing in 1993:

“Within thirty years, we will have the technological means to create superhuman intelligence. Shortly after, the human era will be ended…

“When greater-than-human intelligence drives progress, that progress will be much more rapid. In fact, there seems no reason why progress itself would not involve the creation of still more intelligent entities — on a still-shorter time scale…

“From the human point of view this change will be a throwing away of all the previous rules, perhaps in the blink of an eye, an exponential runaway beyond any hope of control…

“I think it’s fair to call this event a singularity (“the Singularity” for the purposes of this paper). It is a point where our old models must be discarded and a new reality rules. As we move closer to this point, it will loom vaster and vaster over human affairs till the notion becomes a commonplace. Yet when it finally happens it may still be a great surprise and a greater unknown…”

If Vinge’s prediction is confirmed, the Singularity will happen within 30 years of 1993, namely by 2023. (He actually says, in his paper, “I’ll be surprised if this event occurs before 2005 or after 2030”.)

Of course, it’s notoriously hard to predict timescales for future technology. Some things turn out to take a lot longer than expected. AI is a prime example. Progress with AI has frequently turned out to be disappointing.

But not all technology predictions turn out bad. The best technology prediction of all time is probably that by Intel co-founder Gordon Moore. Coincidentally writing in 1965 (like IJ Good mentioned above), Moore noted:

“The complexity for minimum component costs has increased at a rate of roughly a factor of two per year… Certainly over the short term this rate can be expected to continue, if not to increase. Over the longer term, the rate of increase is a bit more uncertain, although there is no reason to believe it will not remain nearly constant for at least 10 years. That means by 1975, the number of components per integrated circuit for minimum cost will be 65,000. I believe that such a large circuit can be built on a single wafer…”

For more than forty years, Moore’s Law has held roughly true – with (as revised by Moore himself) the doubling period taking around 24 months instead of 12 months. And it is this persistent growth in computing power that leads other writers – most famously, Ray Kurzweil – to continue to predict the reasonably imminent onset of the singularity. In his 2005 book “The Singularity Is Near: When Humans Transcend Biology“, Kurzweil picks the date 2045.

Intel’s present-day CTO, Justin Rattner, reviewed some of Kurzweil’s ideas in his keynote on the future of technology at the Intel Developer Forum in San Francisco on the 21st of August. The presentation was called “Crossing the chasm between humans and machines”.

To check what Justin said, you can view the official Intel video available here. There’s also a brief slide-by-slide commentary at the Singularity Hub site, as well as lots of other web coverage (eg here and here). Justin said that the singularity “might be only a few decades away”, and his talk includes examples of the technological breakthroughs that will plausibly be involved in this grander breakthrough.

Arguably the biggest unknown in the technology involved in superhuman intelligence is software. Merely improving the hardware doesn’t necessarily mean the the software performance increases to match. As has been remarked, “software gets slower, more rapidly than hardware gets faster”. (This is sometimes called “Wirth’s Law”.) If your algorithms scale badly, fixing the hardware will just delay the point where your algorithms fail.

So it’s not just the hardware that matters – it’s how that hardware is organised. After all, the brains of Neanderthals were larger than those of humans, but are thought to have been wired up differently to ours. Brain size itself doesn’t necessarily imply intelligence.

But just because software is an unknown, it doesn’t mean that hardware-driven predictions of the onset of the singularity are bound to be over-optimistic. It’s also possible they could be over-pessimistic. It’s even possible that, with the right breakthroughs in software, superhuman intelligence could be supported by present-day hardware. AI researcher Eliezer Yudkowsky of the Singularity Institute reports the result of an interesting calculation made by Geordie Rose, the CTO of D-Wave Systems, concerning software versus hardware progress:

“Suppose you want to factor a 75-digit number. Would you rather have a 2007 supercomputer, IBM’s Blue Gene/L, running an algorithm from 1977, or an 1977 computer, the Apple II, running a 2007 algorithm? Geordie Rose calculated that Blue Gene/L with 1977’s algorithm would take ten years, and an Apple II with 2007’s algorithm would take three years…

“[For exploring new AI breakthroughs] I will say that on anything except a very easy AI problem, I would much rather have modern theory and an Apple II than a 1970’s theory and a Blue Gene.”

Another researcher who puts more emphasis on the potential breakthrough capabilities of the right kind of software, rather than hardware, is Ben Goertzel. Two years ago, he gave a talk entitled “Ten years to the Singularity if we really try.” One year ago, he gave an updated version, “Nine years to the Singularity if we really really try“. Ben suggests that the best place for new AIs to be developed is inside virtual worlds (such as Second Life). He might be right. It wouldn’t be the first time that significant software breakthroughs happened in arenas that mainstream society regards as peripheral or even objectionable.

Even bigger than the question of the plausible timescale of a future technological singularity, is the question of whether we can influence the outcome, to be positive for humanity rather than a disaster. That will be a key topic of the Singularity Summit 2008, which will be held in San Jose on the last Saturday of October.

The speakers at the summit include five of the people I’ve mentioned above:

(And there are 16 other named speakers – including many that I view as truly fascinating thinkers.)

The publicity material for the Singularity Summit 2008 describes the event as follows:

“The Singularity Summit gathers the smartest people around to explore the biggest ideas of our time. Learn where humanity is headed, meet the people leading the way, and leave inspired to create a better world.”

That’s a big claim, but it might just be right.

27 August 2008

Sympathy for the operators

Filed under: openness, operators — David Wood @ 2:51 pm

It’s not just Apple and the iPhone that are the subject of some extreme views (particularly in North America). Network operators also provoke some red-hot far-out responses. But whereas the iPhone tends to provoke unduly strong admiration, the operators tend to provoke unduly strong opprobrium.

For example, here’s some verbatim comments that came up in a private piece of research conducted in and around Silicon Valley earlier this year:

“Everyone in tech has rope burns around their necks from doing business with the carriers. They hung themselves trying to do carrier deals.”

“The operator is an adversary, not a partner.”

“The basic problem with mobile is that the operators are in the way”.

In London, the sentiment is less blatant, but it’s still present. During almost every Mobile Monday London event that I’ve attended, sooner or later some question from the audience takes a semi-joking, semi-serious pot shot at network operators, blaming them for one or other aspect of lack of openness. I find these comments uncomfortable – first, because I count many friends among employees of network operators, and second, because it seems to me that the issue is considerably more nuanced than this kind of easy scape-goating suggests.

It was for this reason that I deeply enjoyed discovering and reading the recent article “Open=Beta?” by former Qualcomm SVP Jeffrey Belk. The article started by recounting some of the the usual criticisms:

“The application community, and the Venture Community that finances them, are rightly tired of what can be perceived as a small global cadre of folks in the carrier community, as well as egregious application qualification processes, putting a chokehold on the deployment of innovation in the applications space. And the chokehold is stifling innovation and growth of the wireless data applications business”.

However, as Jeffrey goes on to say,

“But as usual, the truth is not so simple…”

“One REALLY cool company got a trial with a few operators. A small problem: Their application bricked (i.e. killed dead, dead, dead) the phones of some of the trial users. Other applications, usually written by folks that are accustomed to the massive memory and hard drives of PCs or Mac, are WAAAY too resource intensive (memory, processing power) for anything but the top tier of smart phones, and even with that tiny market, performance of the apps is often suspect. Another application (fixed now), kept a persistent data connection up between the phone and carrier network. This is a huge issue, as a lot of users still don’t have unlimited data, and if an app is sucking data without them knowing it, it could be costing them a fortune, let along putting an anchor on the data performance of the operator’s network…”

“For the operators, the simplistic reality is that the bottom line is the bottom line, and they CANNOT allow applications to either 1) raise their costs structures or 2) damage their brand/customer base, because when things go wrong with an application or phone, people blame the operator. Every piece of research I have seen (or conducted) over the past decade makes that point clear. And just why do operators need to protect their network? A few months ago, I saw a CEO of a major operator speak. In the Q&A, he mentioned as an answer to a question that it costs him a minimum of $8 per phone call to answer a support call. That’s not counting the pissed off customer factor and dilution of the brand that he’s spent billions of dollars or euros building…”

“At a recent developers conference, an operator was telling a story of a section of a city where service parameters all went to hell, cells shrinking, customers losing service. They tracked it back to an enterprise customer that had gotten permission to test a new piece of hardware, and that hardware was causing nasty network effects. Bad. Another example, not as brutal, is when several applications that, when I asked about some trial metrics, with persistence (or even no persistence but frequent network access) were impeding customers’ ability to make or receive voice calls. Very bad, again — something operators just ain’t gonna allow because when these things start to happen, customers are going to look down at their phone, look at the logo on the phone, and get pissed at their operator. And pissed off customers churn. And churn makes operators’ metrics look bad. And bad metrics make financial markets unhappy. And unhappy financial markets make operator executives lose their jobs. So it just won’t happen.”

In between the paragraphs I’ve quoted, there’s lots more interesting analysis. There’s no easy answer, Jeffrey suggests, except for some first-class development work by applications providers, who need to take the time to understand the special complications of mobile. Applications won’t be tolerated on the network, even with the label “Open”, if they are in reality only beta quality (or “pre-beta”), and risk significant network and support costs.

Is that the end of the story? Unfortunately, there is one more twist. Application developers often perceive that network operators have an additional motivation, lying behind their defensible motivation to preserve the quality of the network. That additional motivation is less defensible: it’s to block the kind of innovative services that could divert some of the network operator’s highly valued revenues to alternative services. Presumably that’s part of the reason why network operators appear to dislike open phones that support wireless VoIP.

That looks like another issue for which there’s no easy answer. It’s an issue that transcends mobile operating systems.

24 August 2008

Market share is no comfort

Filed under: disruption, innovation, iPhone, Nokia — David Wood @ 9:55 am

In the discussion of whether Symbian and Nokia are fundamentally threatened (or even “irrelevant”) in the face of the huge market buzz around the Apple iPhone, I take no comfort in the fact that Symbian’s share of the global smartphone market is an order of magnitude larger than that of the iPhone. Therefore I disagree with those replies to my previous blog post that highlighted Symbian’s very considerable market share lead, worldwide (but admittedly not in the USA), over the iPhone.

At first sight, strong market leadership should count for a lot. It should trigger a virtuous cycle effect. More phones should attract more developers (who are interested in their apps running on large numbers of phones) which should result in more software tailored to that platform, which should in turn increase the attractiveness of these phones to end users. And that should result in even more phones being sold, and so on – virtuous cycle.

And in reality, a powerful virtuous cycle effect does exist. An experienced and sophisticated ecosystem (“ES”) has grown up around the Symbian operating system (“OS”) and is continuously adding more value to this platform. The OS-ES virtuous cycle does work. However, it’s not invulnerable.

The history of the technology industry is full of examples of companies who were in similar leadership positions to that currently held by Symbian, but whose markets were transformed by disruptive new entrants. Harvard Business School professor Clayton Christensen is deservedly applauded for his description and analysis of how market disruption takes place:

  • Celebrated examples include how the leading providers of mini-computers, such as DEC, Data General, Wang, Nixdorf, and Prime, failed to appreciate the significance of the initially small market that grew up around fledgling personal computers. These manufacturers saw little profit in that market. But when PC technology improved and the surrounding ecosystem matured, it was too late for these erstwhile computing giants to take leading roles in the new industry (despite lots of effort which they eventually but unsuccessfully expended on that new cause).
  • An earlier example, also told by Christensen (in “Seeing what’s next: using theories of innovation to predict industry change“), concerns the disruption caused by the invention of the telephone to the communications industry of that era (1870s): market leader Western Union evaluated the new technology created by Alexander Graham Bell, but concluded it lacked the power to handle the long-range business communications from which the company made most of its profits. Again, technology improved and new business relationships formed, faster than Western Union could respond – with Western Union being plunged into decline as a result.

And there’s more. MIT professor James Utterback elegantly recounts many intriguing and salutary examples in his book “Mastering the dynamics of innovation: How Companies Can Seize Opportunities in the Face of Technological Change”. The book shows how familiar technologies such as refrigeration, electrical lighting, and plate glass, were all clear underdogs at the time of their initial market introduction, and faced serious competition from entrenched industrial alliances whose technologies (such as large-scale ice transportation, or gas lighting) themselves appeared to be regularly improving.

Could the iPhone fit into a similar pattern? It might. There are possible futures in which, say, more than half of all phones sold in the world have iPhone technology inside them. I don’t see that as the most likely future – far from it! – but it does have a certain logic to it:

  1. The iPhone is in many ways a simpler product proposition than existing smartphones (just as PCs were simpler than mini-computers). There are considerably fewer applications built into the iPhone than you can find in a standard S60 phone. That relative simplicity means that some feature-focused users will decide not to use the device. But the device taps into a new market that is arguably underserved by previous offerings. This is the very considerable market of users who don’t need every bell and whistle in feature-packed smartphones, but who are ready for a better experience than can be had from ordinary phones.
  2. The iPhone uses physical components that “break the rules” regarding cost: they’re considerably more expensive to manufacture than most other smartphones, and this makes the device more expensive to purchase. However, again, it may be that now is the right time to break this rule: a greater number of users may be willing to bear this additional cost (in view of the additional benefits that buys them).
  3. The iPhone isn’t growing its ecosystem from scratch; it can benefit from a crossover effect from various components that were already in place in Apple’s pre-iPhone product offerings. Principally, the highly-evolved iTunes distribution mechanism plays a big part in ensuring a good end-user experience with the iPhone.
  4. The iPhone has put special emphasis upon a number of usability aspects, including the graphics “wow”, the UI itself, the mobile web browsing experience, and the discovery and installation of new applications. Users have been drawn to these aspects of the device, even though the device lacks other aspects that are present (and well-evolved) in other smartphones.
  5. Despite what some critics have said, these innovations aren’t (all) easy for other companies to copy. The “look” can be mimicked, but the “feel” is the result of countless small design and implementation details, that are anchored in a sophisticated underlying software system.

For another analogy, the iPhone is similar to the initial Palm Pilot devices, which fared much better in the market than earlier attempts at pen-input handheld devices. The Palm Pilot delivered less than these other devices (such as the Apple Newton, the Casio Zoomer, and the General Magic “Magic Cap”) but provided a much more usable experience.

So, let’s evaluate this scenario. Do disruptive new market entrants always succeed in reaching market leadership position? Of course not. Although it is difficult for market leaders to respond to this kind of change of rules in their industry, it’s not impossible.

Here’s one counter-example: Microsoft and the Internet. Initally, it did look as though Netscape was succeeding in building an impregnable position by bringing a compelling new product to market in an area that Microsoft had previously ignored – an Internet browser. But Microsoft managed to turn around the situation, by dint of two measures:

  1. Clear internal recognition, from the highest leadership, of the fundamentally changing market landscape
  2. Swift and effective execution, continued over many years.

I’m loathe to compare Nokia/Symbian to Microsoft, but in this case the comparison has merits.

What’s more, I expect that it will become clear, over the next year or so, just how much the Symbian Foundation is itself changing the rules of the mobile industry – and (crucially) enabling companies who use this software to change the rules even further. If you think the iPhone is innovative, you’re right, but you ain’t seen nothing yet.

19 August 2008

Nokia and the valley iPhone super-fans

Filed under: iPhone, Nokia — David Wood @ 9:47 pm

“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!

14 August 2008

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

Filed under: collaboration, Symbian Foundation — David Wood @ 3:47 am

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.

13 August 2008

There’s more to Open Innovation than Open Source

Filed under: ecosystem management, Open Innovation, Open Source, software management, Symbian Foundation — David Wood @ 3:04 am

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.

« Newer Posts — Older Posts »

Blog at WordPress.com.