I've been working over the past month with Paula Hunter and the Outercurve Foundation on a short book to introduce executives to the fundamentals of free and open source software. It's based on writing she and I have done in the past with a few new essays. One of the last topics I wanted to tackle is the question of when not to publish software under FOSS licensing terms from the perspective of companies in a position to "make" FOSS software.
Many managers are concerned with creating and contributing to the open source ecosystem for two primary reasons:
- Losing control of the “value” inherent in the IP creation, and
- the liability risks of contributing to or publishing the software.
If liability risk is the real problem, then one needs to be sure that one is comfortable with the FOSS license terms, any terms of service that may be involved in the project’s web presence, and the IP management process in place to vet contributions, regardless of whether one is accepting inbound contributions to one's own FOSS-licensed project or outwardly contributing to another project. There’s not much more that can be done about such perceived risk. A company will either be comfortable with the benefits against the risk analysis or not.
A good measure of the risk however is the number of lawsuits that have happened in the open source space relating to copyright. The few that exist tend to be focused on a company using open source software in their products and services while blatantly ignoring the FOSS licensing terms. Openly and honestly participating in an open source community doesn’t appear to lead to lawsuits. Liability risk is probably not a good reason NOT to make FOSS software unless you have a particular risk profile.
The value of the software published is a very different discussion. People need to be very crisp when discussing value. One should never publish one’s core value proposition to its customers. Geoffrey Moore published “Crossing the Chasm” in 1991, and helped business managers understand the concept of their core value proposition. This was a very customer-focused “core” value. Everything else was a complement around the core. It related to the problem one solved for the customer. In later writings (“Dealing with Darwin”) Moore once again discussed core value, but here he was discussing core competency. It was an inward focused core value, and everything else a company did was context. It wasn’t what the customer bought, but rather how one solved the customer's problem.
Core competencies and core value propositions shouldn’t be published for all to use. If the software you have represents the core competency of the company, or generates a substantial competitive edge, it shouldn’t be shared under liberal licenses. The trick, however, is in understanding the truth about the core competency.
Google is an excellent example of this idea. Google consumes a lot of open source, and contributes back in a myriad of ways. But it hasn’t historically shared certain changes it has made to the Linux kernel, nor does it publish all the tools it uses to rapidly deliver software to customers.
Red Hat is another more interesting example. One could argue they simply publish a Linux distribution. The reality is that they dominate the space because they understand it isn’t the software asset that the customer is buying (and over which Red Hat has no particular ownership or control) but all the value around the software in services and risk mitigation and quality and ease-of-deployment that made Red Hat Enterprise Linux such a great replacement for expensive proprietary UNIX systems, and now an excellent server platform going forward.
There is a lot of software in an organization that isn’t in and of itself mission critical to the value they deliver to their customers. Modern Internet properties like Facebook, Netflix, Twitter, and LinkedIn all collaborate on software infrastructure and publish tools they use because it improves the infrastructure for all. Their value to their customers and their competitive business lock is the data, and in some cases the data in aggregate. Or it will be otherwise unrelated to the software platform, e.g. their ability to deliver customer value through a particular channel at a particular price point. These companies deliver a high-quality robust software-based experience to their customers that would make the average enterprise IT shop envious — and they do it on a software platform on which they’re happy to collaborate.
Software is valuable. It represents an investment in its creation, and delivering good software isn’t easy. But in relation to a business endeavour, the cost of creating it may best be shared through collaborative development because it doesn’t represent the core value of a corporation. It’s context in the business.
An interesting further observation from Moore was that a company’s core competency changes over time. They leave a growing pile of context behind them. Google also provides an interesting example of how a company’s edge changes over time. When they were a young company, the company’s ranking algorithms were critical and it would have been idiocy to publish them. At this point in time, with the value that may have been built up in their indexes, they might well be able to share the algorithm because it only works properly in conjunction with the rest of the structured data they have amassed.
Likewise, Microsoft originally needed to protect the Windows NT core competency at the software level. Now, their competencies may be more around the release processes and delivery channels. While there is a lot of third party software in the Windows product of today that cannot trivially be shared, the company’s value is likely no longer tied up in the kernel software anymore than Red Hat’s value is tied up in the Linux kernel that they don’t own and only influence.
Reliably developing robust useful software is hard work. Liberally sharing software and collaborating in open communities is an excellent way to distribute the costs and gain domain insight and knowledge, regardless of whether one is an individual or a corporation. For companies, the challenge is to understand their real and evolving value proposition to customers and the core competencies that enable them to best deliver to those customers. Everything else can be shared.
Comments