Open Source Innovation - Fact or Fiction

Is Open Source Innovation an oxymoron? Is Open-source fostering innovation or killing it?

There are two school of thoughts out there: First, there are lots of people, who say that open-source is not fostering innovation or even killing it, because it is just about the reimplementation of already solved problems and that it actually kills innovation, because it keeps people from implementing solutions that can not be protected from being reimplemented as an open-source solution. Second there are at least as many people, who say that open-source is actually creating/fostering innovation, because a company can not hide behind a bad implementation and will always be forced to look for ways to make its solution better, faster and more affordable.

Let's first contemplate on the nature of innovation. As previously discussed there is a difference between innovation and creativity: You can ask people to be creative, but you can't really ask them to be innovative, because innovation is something that get's established after the fact, means it get's established by the traction you get with your ideas in a give business context and the impact they have on the business and the market.

I personally believe that you cannot orchestrate or manage or create innovation. It just happens. It happens in a more darwinistic way: Through diversity/competition/mutation and selection. What you can do is to create an environment, which cherishes diversity/creativity and competition. This will increase the likelyhood that some of your ideas turn into real innovation. In that context you probably want to set up a number of small units to shoot at the same target and want to make them compete for the best implementation. This is why open-source is innovative and/or creates innovation. It is not the a/the project that is innovative. It is the competition between the projects that creates the innovation. One good discussion on this can be found in "Innovation Happens Elsewhere, by Ron Goldman and Richard P. Gabriel".

One other way to put more structure into the discussion is to segment innovation into ...

• Business Model Innovation - a new creative way to make money with something (might be closed-source or open-source)
• Solution Innovation - a new creative way to solve a given (old or new) problem
• Implementation Innovation - a new creative way to implement a given solution

Open-source is clearly a good fit to drive implementation innovation. If you do not like a given implementation, you can always take the source code and make it better or even reimplement a given solution (e.g. a customer relationship management solution) or a given standard (e.g. JBI) with a new implementation.

Question is, if open-source and/or open-source concepts are also suitable to drive solution- and/or business-model-innovation? This leads to the next bigger question: In the past the value of a company was determined by the solutions they own. This is why pharmaceutical companies try to protect their products with patents and other means. I am not sure that will stay this way going forward. Instead we might see a world in which your solutions matter less, but your ability to detect problems and develop solutions will determine the value of your company to a much larger extend.

In such a world, open-source concepts might actually be very suitable to foster innovation on the solution level.

Solid State Disks - Level 5 cache

Last month I had the pleasure to spend 2 hours in the car with Klaus Grieger. Klaus and myself know each other from ObjectDesign and Versant. Right now he is a partner with CIMT AG in Germany. As always talking to him was invigorating. He is one of the most innovative people I know.

The topic of the drive was the future of Solid State Disks (SSDs). His thought was/is that with the arrival of in-expensive, fast SSDs we can potentially rethink the way we structure memory and storage in general. Right now, we "load" executables from a "disk" into "main memory". What if, we turn the disk into a level 5 CPU cache, means programs never get loaded and/or started. They get installed into "memory" and will stay there all the time. Instructions get fetched into lower-level CPU caches on as needed basis. This would/could probably work for instructions, but not for data. Means for data you would still needs a disk with a file-system.

Hhhhmmmmmm, ... can somebody help me to think this through?

Embedded Software Engineering - Can we avoid another software crisis

The term "software crisis" was coined 1968 by F.L. Bauer during the first NATO Software Engineering Conference in Garmisch, Germany and was used by Dijkstra in his very famous lecture on "The humble programmer":

[The major cause of the software crisis is] that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.

– Edsger Dijkstra, The Humble Programmer

Right now there are lots of people who are saying two things: First, embedded devices and embedded software will change and transform our way of life in a similar or even stronger way than the arrival of the internet and second, the resulting software engineering challenges are huge.

There are a lot of drivers/trends behind this, but two of the more critical ones are the arrival of multi-core processor architectures for embedded devices and the resulting increase in processing power that comes with it (see quote above :)). And secondly the increasing demand to make embedded devices talk to each other (e.g. make Electronic Control Units (ECUs) on the car talk to each other and then make cars talk to each other).

The lack of abstraction that we have in embedded software engineering makes more than 50% of all embedded software projects being later, over budget or not deliver on expectations.

This sounds and looks like a first class software (engineering) crisis. What do we do?

Killing the problem with people (e.g. throw more people at the problem) is a very popular approach, especially with the emergence of cheap off-shore development centers in India and other places, but creates a huge liability, because over time it does not scale very well and the management and maintenance burden has the potential to become an even bigger problem.

More thoughtful approaches first segment the embedded market from a requirements point of view and then look for much more systematic approaches to address the requirements in the given segment. One way to segment the market would be along the lines of the real-time requirements. Working assumption would be that there is a hard real-time market, a soft real-time market and an embedded market (no real-time requirements, but the software must run on devices with limited CPU and memory capabilities).

The segment with the strongest growth is the last one. Addressing the software engineering issues in this segment will give us the biggest bang for the buck.

One way to go about it is to use existing approaches that have (kind of) worked for the first two (real-time) segments and also use them in the embedded space, e.g. using integrated tool-chains to generate a lot of the source code (also known as Model-Driven Software-Development (MDSD)). This gives you good initial results in terms of productivity, but has the potential to create hard to maintain, monolithic, tightly-coupled monster systems.

The most promising approach right now is to introduce the idea of Software Product Lines (SPLs) to the domain of embedded software engineering and combine it with MDSD. This will give you the productivity gains you are looking for, but will also allow you to enforce a/the necessary level of reuse to ensure the long-term maintainability of the system.

In that context abstractions become pivotal. Without abstractions there is no way to create good boundaries for reuse. The first level of abstraction is the operating system and here is good news, because more and more embedded systems are based on standard operating systems (e.g. embedded Linux). But the layer above that is still under construction. What is needed is a platform that will allow you to build business-level software components and integrate them on the device and/or even reuse them over device boundaries.

Interesting efforts in this context are ...

• OSGi - a component deployment platform for embedded devices for components and services implemented in JAVA
• The Virtual Function Bus (VFB) in AUTOSAR - a common software infrastructure for automotive systems of all vehicle domains based on standardized interfaces
• Various embedded software engineering platforms for mobile devices like LiMo, Moblin and Android
  

Complementary to these efforts you need a way to distribute/access these components over process or even hardware boundaries. The IONA Professional Services Organization has implemented a solution called Artix/E, that provides a transport-independent, high-performance, component platform for the embedded market.

Can we avoid the embedded software crisis? Yes, we can! Check it out.

Randy Pausch - about elephants, walls, rooms and TVs

Last week Randy Pausch died. With all the hype around his cancer and "the last lecture", it was/is kind of hard to see who he was or what he was. Yesterday I tried to find out a little bit more and watched his presentation on time management. Good presentation, but not something that we haven't heard before. In the end I have to agree with him: He is a smart professor, but there are lots of smart professors out there. What made him unique was not what he did, but why he did it and how he did it. From what I saw of him, he had a passionate ambition to make learning fun. His students were his customers and he felt an obligation to deliver value to them. He found his purpose and lived it. And this makes him a role model.

Here are my personal take-aways ...

• if there is an elephant in the room ... then talk about it!
• "experience is what you get, when you don't get what you want"
• walls are there to show you how much you really want something
• if your children want to paint their room ... let them do it!
  
• switch off the godd.... television

In this blog I am not talking about how he dealt with his cancer, because I believe that this is not something he wants to be remembered for.