dw2

Building the software system for complex smartphone products is one of the toughest engineering challenges on the planet. The amount of software in a high-end phone has been roughly doubling, each year, for the last ten years. In order to reap market success, smartphone software has to meet demanding requirements for performance, reliability, and usability. What’s more, to avoid missing a fast-moving market window, the software needs to pass through its integration process and reach maturity in a matter of months (not years). As I said, it’s a truly tough problem.

[Author’s note: a version of this article is appearing in print today, to mark the first day of the Symbian Smartphone Show. I thought that people might like to read it online too.]

In broad terms, there are two ways in which a company can seek to solve this kind of tough problem:

1. Seek to keep careful control of the problem, and rely primarily on resources that are under the tight direction and supervision of the company;
2. Seek to take advantage of resources that are outside the control of the company.

The attraction of the first approach is that it’s easier to manage. The attraction of the second approach is that, in principle, the company can take better advantage of the potential innovation created by users and developers that are outside the company.

Writers and academics who study how innovation works in industry sometimes use the terms “closed innovation” and “open innovation” to describe these two approaches. In his pioneering book “Open innovation, the new imperative for creating and profiting from technology”, Henry Chesbrough lists the following contrasts between open innovation and closed innovation:

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. It sounds extremely attractive. However, the challenge is how to put these ideas into practice.

That’s where open source enters the picture. Open source removes both financial and contractual barriers that would otherwise prevent many users and external developers from experimenting with the system. For this reason, open source can boost open innovation.

However, in my view, there’s a lot more to successful open innovation than putting the underlying software platform into open source. We mustn’t fall into the trap of thinking that, because both these expressions start with the same adjective (“open”), the two expressions are essentially equivalent. They’re not.

Indeed, people who have studied open innovation have reached the conclusion that there are three keys to making open innovation work well for a firm (or platform):

• Maximising returns to internal innovation
• Incorporating external innovation in the platform
• 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 codelines forming 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 codeline management, if it is to be able to productively incorporate external innovation.

Codeline management in turn depends on skills in:

• Codeline gate-keeping: not accepting code that fails agreed quality criteria – no matter how much political weight is carried by the people trying to submit that code
• Reliable and prompt code amalgamation: being quick to incorporate code that does meet the agreed criteria – rather than leaving these code submissions languishing too long in an in-queue
• API management, system architecture, and modular design – to avoid any spaghetti-like dependencies between different parts of the software
• Software refactoring – to be able to modify the internal design of a complex system, in the light of emerging new requirements, in order to preserve its modularity and flexibility – but without breaking external compatibility or losing roadmap momentum.

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 skilled software codeline management, the answer to this issue is skilled ecosystem management.

Ecosystem management involves a mix of education and evangelism. It also requires active listening (also known as “being open-minded”), 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. This involves the mindset of “growing the pie for mutual benefit” rather than the platform owner seeking to dominate the value for its own sake.

But neither software codeline 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.

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 should come into existence with huge amounts of battle-hardened expertise in both software codeline management and ecosystem management. On that basis, I expect the additional benefits of open source will catalyse a significant 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. For these platforms, open source may result in divisive fragmentation and a dilution of ecosystem effort.

Footnote: For more insight about open innovation, I recommend the writings of Henry Chesbrough (mentioned above), Wim Vanhaverbeke, and Joel West.