Of Open Source and Open Innovation

Last week I wrote about a talk I gave with the title “Innovation inducement prizes as a possible mechanism to unlock the benefits of open innovation models”. I explored the idea of inducement prizes then, and now I'd like to look at...


Last week I wrote about a talk I gave with the title "Innovation inducement prizes as a possible mechanism to unlock the benefits of open innovation models". I explored the idea of inducement prizes then, and now I'd like to look at open innovation.

That concept rose to prominence with Henry Chesbrough's book, "Open Innovation – The New Imperative for Creating and Profiting from Technology", published in 2003. It's a decent enough exploration of the idea from a business viewpoint, but what shocked me when I read it was that Linux is mentioned just once, on page 106, in the context of IBM, which was "able to create value for its customers through its embrace of open standards in a variety of areas, including the Linux operating system, the Java programming language, and the aforementioned HTML and http protocols."

That's all true, but it misses the key point: that open innovation, as described throughout Chesbrough's book, was essentially invented by Linus when he started the Linux project in 1991. To see why, we need to look at the larger history of free software.

That began, obviously, with Richard Stallman's announcement of the GNU project in September 1983:

Starting this Thanksgiving I am going to write a complete Unix-compatible software system called GNU (for Gnu's Not Unix), and give it away free to everyone who can use it. Contributions of time, money, programs and equipment are greatly needed.


Individual programmers can contribute by writing a compatible duplicate of some Unix utility and giving it to me. For most projects, such part-time distributed work would be very hard to coordinate; the independently-written parts would not work together. But for the particular task of replacing Unix, this problem is absent. Most interface specifications are fixed by Unix compatibility. If each contribution works with the rest of Unix, it will probably work with the rest of GNU.

This emphasises two things. First, that GNU began as a project that Stallman was undertaking personally, although he was hoping that other programmers might contribute. And secondly, that "such part-time distributed work would be very hard to coordinate" - an indication of the rather limited connectivity that was available at this time.

In fact initially the approach taken was for the newly-formed Free Software Foundation (FSF) to hire someone to help Stallman write other parts of the code. As Stallman told me a decade ago:

"When I started it out, it didn't have have the money to hire anyone. Then it had money to hire one person, and it hired one person. The point is just that that enabled us to do more work at the same time because there were lots and lots of programs that were missing. In the earliest years [there were just] two or three people and volunteers [helping]; by the later 80s, I'd expect there were somewhere between thirty and fifty people."

The fact that the FSF was hiring people to write code underlines that this was a fairly top-down structure. That's understandable, since Stallman was the one with the vision, and therefore the one that was giving overall direction to the work.

Now move forward a couple of years to 1991. By then, most of the key pieces for the GNU system had been written – with one, major exception: the kernel. In another top-down decision, Stallman had opted for a microkernel design, and this proved much trickier to write than he thought.

Fortunately, someone else was knocking together a kernel, although of a rather different kind. In fact, it wasn't even originally conceived of as a kernel initially, but a simple task switching program to test out the capabilities of the 386 chip in his new PC. And far from planning to provide the keystone for the great GNU project, Linus' code was written "just for fun."

Perhaps it was that lack of pretension that made it natural for him to make his famous posting on comp.os.minix newsgroup, on 25 August 1991:

I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things).

I've currently ported bash(1.08) and gcc(1.40), and things seem to work. This implies that I'll get something practical within a few months, and I'd like to know what features most people would want. Any suggestions are welcome, but I won't promise I'll implement them :-)

What's interesting here is that Linus is actively soliciting suggestions for his fledgling Linux – there's no sense of him simply seeking other coders to implement his ideas, as was the case with Stallman.

Over the next few months people from around the world started to offer more and more suggestions, and also to become actively involved. That was possible because Linus had posted the code online (although not initially under the GNU GPL – that came later) and because the Internet by then had become cheap enough and sufficiently widely available that geography became less of an obstacle to taking part (Linus' location in Finland probably played a big part here: since local hacking communities were tiny, he was forced to reach out globally.)

As more coders joined in, the open development process evolved. But the key elements remained the same: participation completely open to all (coders and users); bottom-up rather than top-down (although Linus always has the final decision about which of those bottom-up suggestions should be adopted); and based on online rather than personal collaboration. Putting those together created not just what came to be called "open innovation", but a process that could scale.

Indeed, one of the other signal achievements of the open source development methodology is that it manages to avoid the problem enunciated by Fred Brooks in his book "The Mythical Man-Month", that "adding manpower to a late software project makes it later." The key new ingredient to add is openness: this allows potential members of a team to train themselves before joining without imposing additional overheads on the existing members. It's why open innovation only really works when there is a real willingness to open up.

I don't think Linus gets enough credit for helping to define (albeit unintentionally) the ideas behind open innovation a decade before books started appearing about it. In terms of achievement, it's arguably up there with the Linux kernel and Git.

For those who might be interested, I've embedded below the slides from my Brussels talk, which explore some of these ideas in the context of innovation prizes (freely downloadable, of course).

Follow me @glynmoody on Twitter or identi.ca.

"Recommended For You"

open source dividend Alan Cox, key Linux contributor, steps down