Opening the Door to Innovation

The link between open innovation and open source has long been documented. That there is a significant correlation is obvious and not arguable, but to what extent is there causation? And in what direction?

Open innovation describes a process, whereas open source — as well as its predecessor, free software — has traditionally described a product or end result. The ultimate determination of whether a software project qualifies as open source is the license under which it is released.

I posit that the relationship between process and end result is one-way: Open innovation in software will necessarily lead to an open source result, but not the other way around. It is entirely possible to release open source software without open innovation. In fact, this happens all too often.

How Does One Innovate ‘in the Open’?

The debate over what qualifies as open has raged ever since marketing departments in technology companies realized that calling their products “open” yielded non-trivial results in the form of trustworthiness and market credibility.

Indeed, it is a nebulous term and entirely relative — there is no such thing, for example, as absolute openness. When someone declares their product to be “open,” one must ask, “compared to what?”

Even so, there are two telltale signs of open processes and innovation:

Maintains transparency — When drafting the rules governing a project, creating a road map, or discussing feature designs, innovating in the open means these important discussions are accessible to the public and not hidden from view.

Seeks external input — Open processes dictate not only that daily project functions be accessible, but also that they will actually solicit — and listen to, if not accept — outside input.

Neither of these mention open source, per se, so how do they necessarily lead to an open source result? In 2006, I argued that all other things being equal, a software project that publishes source code will have a competitive advantage over a project that does not — perhaps not directly or immediately, but over time. If you think about it, it’s not a stretch in logic to come to that conclusion.

A project that seeks and solicits input and is transparent in its operations would cripple itself by not releasing source code. Imagine outsiders following the development of a software project and wanting to participate. Without the source code, they may be able to download a usable tool or set of tools, and they may be able to send in bug reports or feature requests, but they would be constrained by how much they could participate.

Indeed, the only way to get full access to the project would be through some type of official induction ceremony, at which point they would have to quickly come up to speed on the code base when they could have already been doing that.

It’s not that there are no solid reasons for keeping a software project’s code secret, but if the developer goes to the trouble of establishing transparency and open processes, then keeping the code a secret becomes more trouble than simply releasing it.

Note that I’m not advocating that every software project must innovate in the open, although I am clearly biased towards that sort of thing. I am simply arguing that if you have decided that open innovation is the way to go, then you will eventually go down the path of open source.

When Is Open Source Not Open Innovation?

As I mentioned above, this causation is not bidirectional. Open source code does not necessarily lead to open innovation. There are numerous examples of code released under an open source license without any other transparency or external input.

These projects are typically easy to spot: They have no outside contributors; they are usually sponsored by a single commercial entity; and their community consists primarily of nontechnical end-users.

In the past, I’ve argued that these projects may as well be proprietary, because they are not enjoying many of the benefits associated with open source software. In fact, their primary benefit — increased adoption of their software product — could just as easily be reaped without releasing source code at all.

In these cases, there is usually a core group of engineers who are employed by a single company, have conversations in private, and keep information under wraps (and under their control). The instincts that drive this behavior are understandable, but that doesn’t make them any more sensible. Nor does it make the project’s goals any more attainable.

Do You Want or Need Open Innovation?

One can have innovative products without opening up processes to the world — it depends on the specific goals. However, chances are that whatever you’re working on, someone else has faced similar challenges and could help you reach your goals more quickly.

As much as we might like to believe that we’re working on something unique, the fact is that we’re usually not, and seeking outside help could greatly speed up a project’s progress. Again, you need not necessarily innovate in the open to be successful, but it would seem to work in your favor the vast majority of the time.

In today’s modern computing environment, there’s even more incentive to go the open innovation route: integration with and inclusion in other projects. Considering how many software components form the basis for data center automation, cloud computing and all virtualization, it’s rare that a new technology could infiltrate data center infrastructure without being open source.

Looking around your basic data center, there’s an awful lot of Linux, MySQL, Xen, KVM, Apache, Puppet, Chef, Hadoop and other core open source pieces. Granted, there are also proprietary pieces to round out the components, but name the last technology not named “VMware” to permeate the data center infrastructure stack. In fact, open innovation methodologies and open source software have made entire business models viable, when before they were not.

The core pieces that make things “go” are overwhelmingly open source. To even be part of the conversation, either you must have truly revolutionary technology, or you’re open source. How can you participate in the projects and communities driving the cloud computing revolution if you don’t follow the open innovation ethos?

While it’s certainly possible to participate, it’s much easier if you also implement open innovation processes and, thus, release open source code. If you have code that you’d like Puppet, KVM, Linux kernel and other developers to adopt, what do you think is the quickest way to do that? If you have software that you’d like to be adopted by the same people who stretch those same technologies to the max, what is the best way to accomplish that?

In modern marketing lingo, it’s often said that you need to be a part of the conversation, which is a nice way of suggesting that companies should be transparent and participate (honestly) in the various conversations that take place online. In modern development lingo, it’s important to be part of the process — and being part of the process means opening up.