Best Books On Open [Innovation/Source]

Many folks talk about Open Source today. When I think of Open Source, there are many non-intuitive aspects that need to be understood to be truly successful. In that context, there are four books that are important to read and understand as it relates to innovation and Open Source. One of my favorite books (below is my copy and a must read IMHO) is Dr. Henry Chesbrough's book “Open Innovation”.

This much acclaimed book lays out, in very clear language, the important differences between “Closed Innovation” versus “Open Innovation”. There are many interesting points that are brought out in his book, two points that he makes in his book that I think are extremely relevant in today's open source world:

"We don't have to originate the research to profit from it."

"Building a better business model is better than getting to market first."

This book is a must read for anyone who is trying to understand Open Source. This book takes a higher level view that is important to understand prior to digging into specifics of software open source and is rich with real life examples.

Dr. Chesbrough has a new book that I am going to buy and look forward to reading called, Open Business Models".

The second must read book is Eric S. Raymond's landmark book, "The Cathederal and The Bazaar".

This book is often quoted in the world of Open Source. It is a great historical book. The two points from this book that stand out in my mind are:

"Often, the most striking and innovative solutions

come from realizing your concept of the problem was wrong".

Raymond quotes Antoine de Saint-Exupery:

"Perfection (in design) is acheived not when there is nothing more to add,

but when there is nothing more to take away."

The third book certainly worth reading is Clayton M. Christensen's "The Innovators Solution", which is, of course, the follow-on to "The Innovators Dilemma".

The most interesting chapter, IMHO, is Chapter 6, "How To Avoid Commidization". The main point that Christensen makes is that "The companies that are positioned at a spot in the value chain where performance is not yet good enough, will find profit."

Obviously, Mr Christensen's point can be easier said than done, but the examples in the book help the reader to find the framework to think about in the context of their own industry.

The fourth book that I find a must read as well is Chris Anderson's "The Long Tail".

The subtitle of the book, "Why the Fture of Business Is Selling Less of More" is the central theme of the book that is brought out in his Chapter 4, "The Three Forces of the Long Tail".

"Democratize the tools of production.

The results of this are more stuff, which lengthens the tail.

Democratize the tools of distribution.

The result is more access to niches, which fattens the Tail.

Connect Supply and Demand."

The result is it drives busines from hits to niches.

It is the examples in this book that I find are very compelling.

I know there are many other books, that I plan on purchasing and reading. Which books have I left out?

Curt Harpold and How To Program ,1000s of Processors

I had the good fortune of traveling with Curt Harpold down to Virginia Tech on January 28th, 2009 to listen to Curt present, "How To Program 1,000s of Processors". Curt wowed the ACM members on the challenges of programming lots of processors as well a the many tremendous features of Sun Grid Engine 6.2.

For complete details of this along with a video as well as Curt's complete presentation, please go to John Edstrom's blog entry here.

Balancing Act: Community Version versus Enterprise Edition

Thanks to Mabimal for the great questions and comments on open source monetization. Recently, on April 29, 2009 at 11:02 PM EDT, Mabimal asked the following:

Hello Dave,

Thank you so much for putting efforts on creating this article.

What i understood from this article is that, open source project cannot be a standalone project as it must be backed up by enterprise versions which generates revenue for open source projects as well, and when the feature of open source project gets stable it will be transformed to enterprise version.The developers and employees developing open source project gets their income from the revenue generated from enterprise versions.

I hope i understood exactly as u r trying to make me understand.
If not please clarify me.

Thank you so much.

Yes, you are absolutely right. That is the general framework. Where things can get a little more complicated are the corner cases. What becomes extremely important is the latency or delay between the Community Version and the Enterprise Edition.

Let me give you a specific example. Let's say we have a Community Version that has nightly builds. Let's also say that we have an Enterprise Edition that was being released semi-annually. If the Community Version introduces a specific feature that the market place is clamoring for. Let's use as an example a Enterprise Service Bus (ESB ) with a new healthcare protocol adapter. If the customer base is clamoring for this particular adapter, the obvious question jumps to the forefront:

Does the new healthcare protocol adapter have to "wait" until it is rolled into the Enterprise Edition from the Community Version?

There are different ways that some companies address this situation. Some companies believe that you never, ever support the Community Version and you simply tell the customer to wait until the healthcare adapter gets rolled into the Enterprise Edition. Other companies believe that you do support the Community Version, but do it from your PS services group at a premium cost with the idea that you move your customer to the Enterprise Edition as soon as the healthcare adapter is officially supported.

My personal view is that when you are designing your Community Version and Enterprise Edition monetization framework, that you carefully review what makes sense to have as plugins that can be rapidly supported in the Enterprise Edition. Keeping with the example above, it would certainly be logical to separate out the protocol adapters to allow for flexibility in official product support in an Enterprise Edition. I also believe that it is perfectly reasonable to have certain plugins as non-open source in the outer ring of the Community Version/Enterprise Edition monetization framework.

There is a hard core group of open source enthusiasts who firmly believe that EVERY line of code must be open source and the only two driving factors are indemnification and support. These hard core enthusiasts call anything that is not totally open source as being crippleware. I believe crippleware is software that has had a critical piece of code purposely removed from it. An example of this is not allowing saves to a file or limiting the size of a particular structure or file. I do not subscribe to this view that EVERY piece of code must be open source. I believe that it is a balancing act between the Community Version and the Enterprise Edition.