Capabilities for Open Source Innovation: Background

Organizational Capabilities

One of the lines of research that’s relevant to this topic explores organizational capabilities. These capabilities are the knowledge that individuals have at a company, but they’re also the abilities the company as a whole has built into their processes, into their business, and into their employees. Capabilities can be learned over time, so a company isn’t frozen to a fixed point of capabilities that can never change, but it does take time to build up new capabilities or strengthen existing capabilities. If a company doesn’t have the capabilities to tackle a totally new strategic area or a totally new project, then deciding to enter that new area is only the first step of a learning process. Organizational capabilities also affect strategic outcomes, so if two companies make the same strategic business decision—no matter how good that decision is in the context of their target market—one company may succeed because it has the organizational capabilities required to achieve that strategic goal, while the other company fails because it is lacking necessary capabilities.

Open Innovation

Another relevant line of research explores open innovation, which was first proposed by Henry Chesbrough in the 2000s, but has been through a number of different iterations over the decade plus since then. In some ways, open innovation is similar to open source, but it’s not quite open source and people get confused about that. The fundamental concept of open innovation is that innovation in general—and this can be technology innovation or business innovation—can be accelerated if companies are willing to go outside their boundaries and either share innovative ideas externally or assimilate external innovative ideas internally. An idea that a company shares outward may be one that they can’t profit from directly, but the other company can help them profit from it, so together they can both make more profit than if the idea just died internally. Being open to assimilate ideas that other companies created means having capabilities (processes and knowledge) around taking that innovation from outside and building it into your own innovation internally.

Open innovation is related to open source in the sense that open source does include both concepts of sharing your internal innovation externally and bringing external innovation internally. But it goes beyond just sharing ideas and knowledge, to actually sharing source code externally and bringing external source code inside the company. If your company is successful at open innovation, you have a set of capabilities towards being successful at open source. You’re not all the way there, but it’s a good boost to getting there.

Much of the change a company makes to become capable in open source has to do with thinking slightly differently about how you create and capture value for customers. It’s no longer a matter of creating all value yourself and capturing all value yourself. Perhaps you created some code, someone else created some more code, and yet another someone created even more code, and you’re getting much more value out of the code that you all develop together than you’re putting into it. Which means you can actually be more effective at driving innovation by not doing all the work yourself. A big part of the change is a matter of getting comfortable doing development in a way that is not purely under your direction. Work isn’t driven under one company from someone up on high, down through a hierarchy, to a set of individual developers. Instead, the work involves relationships across company boundaries.

Levels of Engagement

There are different kinds of relationships across company boundaries. Some relevant research into these relationships is around companies’ levels of engagement in open source and how that impacts their success, their failure, the capabilities they need to succeed, and ultimately their effectiveness in open source and in delivering value to their customers from open source.

Level 1: The lowest degree of engagement is often called Inner Source. A company at this level has taken some ideas from open source, but isn’t consuming external code or sharing code externally, they are just collaborating internally a little more like an open source project.

Level 2: The next step up is to use open source, but purely as a consumer, bringing in external code.

Level 3: Companies at this level deliver open source to customers, either straight up, combined with other open source software, or combined with proprietary software.

Level 4: Companies at this level lead an open source project that they created. They release their code as open source, but they don’t really have an active external community.

Level 5: Companies at this level participate in external projects by contributing code, sponsoring, or supporting the project in other ways, but the relationship is somewhat one-directional or distant. Their participation isn’t highly active, but they still benefit from contributing patches and other support, and getting back the source code.

Level 6: The highest degree of effective open source participation is companies who participate as co-leaders. These companies don’t just throw patches over the wall at the open source project, but take the time to actively share their needs with the open source project, to actively advocate for the directions that they think the project needs to go, and contribute developer time to the project. That doesn’t mean they control the project, in fact, there’s a great deal of value in having many perspectives contributing ideas and together negotiating the direction of the project, for the benefit of everyone involved. At this level, you find companies participating as equals with individual open source developers and respecting them for their technical expertise and role in the project. There’s some nuance here, in terms of how to be effective as a co-leader in an open source project, but the biggest thing to understand is that companies who take that step forward are more effective and get more value out of open source projects.

Other Relationships Across Company Boundaries

Some other relevant research is around more traditional collaborative innovation approaches like strategic alliances, where companies get together under a strong NDA and binding contracts to do some development. These kinds of alliances generally produce proprietary software rather than open source, but some of the research around how strategic alliances work and how companies participate in them is similar to the way companies participate in open source, so the research is relevant.

Research into standards bodies with patent pools is also relevant. The patent pools give the participating companies some degree of protection from each other, which makes them more comfortable all sharing together in terms of the strategic direction and the advancement of the technology. Open source foundations often play a similar role when they include some aspects of patent calming within their contribution and licensing terms, so the participating companies don’t have to be afraid of each other. They can set aside defensive tactics and focus on what’s best for the technology, what’s best for innovation, and what’s going to give all the companies the best value together.

Internal and outsourced R&D also have many similarities to open source. The way an internal R&D department works, or the way a company relates to an outsourcing partner, are in fact very similar to the way that a company relates to an open source project, or the way that companies relate to each other within an open source project. Both open source and more traditional R&D approaches are examples of development happening in a different group, and they require building the same kinds of relationships across the different groups.

Another relevant piece of research is licensing as acquisition. Licensing technology or components as part of a larger effort in innovation is an incredibly common pattern. When one company needs an innovative technology that another company has already developed, they negotiate a license with the other company to use that technology rather than spending the time and money to develop it in-house. The difference between this form of proprietary licensing and open source licensing, is that open source makes the whole process of licensing external innovative technology much easier, because you don’t have a long negotiation before you get to the point that you can license that technology. Open source technology is just freely available under the open source license, you can pick it up, try it, and choose whether you want to integrate it or not. This is one of the concrete ways that open source accelerates innovation, because it makes it faster and easier for companies to acquire innovative technologies and components through licensing.

Technology Innovation and Open Source

The overall focus of this background study was looking at existing research into technology innovation and existing research into open source, and exploring the similarities between the two sets of research. I didn’t start off with specific assumptions on what I might find, just an idea of cross-referencing between the two, since the people who research the two topics don’t seem to talk to each other, read each other’s research, or attend the same conferences. What I found is that the organizational capabilities required to succeed at technology innovation are a very near match to the organizational capabilities required to succeed at open source. I mapped out more than 100 shared characteristics, but I’ll summarize the top few.

Collaborate with external communities: You will innovate faster by taking advantage of available knowledge and resources out in the open, than by trying to do it all yourself internally. Source code is one form of external knowledge and resources that you can use to help your company innovate faster.

Share ideas outward: Tightly grasping every idea you have internally is generally not the path of greatest advantage. You can help accelerate the entire pool of innovation if you’re willing to share ideas outward, and see if other people are willing to contribute to successfully implementing those ideas.

Organizational learning, assimilate ideas inward: Observing external technology innovation or open source isn’t enough, you have to have capabilities in place to assimilate external knowledge and external code.

Efficiency of reuse/modification: In both open source and more general technology innovation, you get an acceleration of innovation from the reuse or modification of existing innovation. There are slightly different mechanics around that in proprietary technology innovation and open source, but the organizational capabilities are basically the same.

Strategic approach to customer value: One set of authors (Morgan & Finnegan) called this “strategic open source”. It’s about taking an approach to customer value where you’re not just blindly assuming that the only way to produce customer value is to do everything yourself in-house, but instead consciously examining your customers’ needs, the capabilities you have, the technology you have, and strategically planning out which pieces you should outsource, which pieces you should build in-house, and which pieces would benefit from inviting customers to participate in creating that value, because it will serve their needs better if they’re involved.

Low barrier to entry: In open source this is partly related to the licensing, which makes it easy to pick up the source code and use it. More generally, it has to do with the fact that innovation moves faster as a whole, across an industry, when we aren’t working in tightly constrained silos. If every company across the cloud industry was working in a silo, we would pretty much have Amazon leading the pack, a couple of other companies struggling to try to do something similar, and that’s it. The barrier to entry for any one company entering the industry would be far too high. When a number of companies are willing to share their ideas and work together, the combined brain power of all of those companies together is orders of magnitude larger than any one company on its own.

Conclusion

If you only take away one thing from this post, make it this: open source is mostly just technology innovation. If your company has already developed the capabilities for technology innovation, then open source won’t be a big hurdle. There are a few new things to learn, but it’s not as radically different as you might think. If your company hasn’t really embraced technology innovation yet, you’ll find open source and any other approach to technology innovation challenging. The good news is, the capabilities that you need to learn to effectively engage with open source, are actually pretty much the same capabilities you need to learn to effectively innovate at technology anyway. And, open source is a particularly easy way to learn those capabilities, because open source communities are generally eager to teach people how to participate and how to succeed with their project. Your competitors in proprietary technology innovation, on the other hand, probably consider every aspect of their technology a closely guarded secret, and are unlikely to have any interest in sharing or helping you learn from their successes and mistakes.