Making Commercial Open Source Software
Delight customers and profit
By: Stephen Walli
Dec. 28, 2012 01:30 PM
I recently blogged about making open source software, and the high level steps for how to think about the process. We started with the need for software to seed the discussion, the need for clear motivation as to why to publish as open source software, and then the structural requirements to build a community (license choice, collaboration platform or forge, and governance considerations). Contributions are the life blood of any community, so lastly we talked about the need to build an onramp to encourage users that will hopefully become contributors, and the additional onramp needed to make it easy to contribute.
Rory MacDonald (@technocreative) challenged in the comments that there are substantial commercial motivations for a company to develop open source projects that go beyond a desire for collaboration, and provided a number of examples. I completely agree, and I'd like to build on these ideas.
Why as a company (rather than as an individual) would you want to "make" open source?
Again we have two types of making to consider:
If we consider a company making contributions to an "outside" project then we should do so from the perspective that this is an advanced case of collaboration where the open source project is being used in a product or service the company offers to customers for sale. Think Red Hat and using Linux to deliver Red Hat Advanced Server. Otherwise, contributing to a project that is used strictly in-house pretty much looks like the discussion in the previous post -- it's about engineering economics and shared innovation and living on a fork gets expensive over time unless it can be balanced against the costs of maintaining a business advantage through secrecy (e.g. the way Google used Linux in the early days).
Participating in an external open source licensed project is a case of expanding traditional corporate thinking of "build" versus "buy" to include "borrow" and "share". It's about time-to-solution if a company uses the project in-house and about time-to-market if the project is used to develop a product or provide a service to customers for sale. One needs to remember as a company using open source licensed software in a product or service that the company exists to solve a problem and create a marketplace around the solution. This is all about Levitt's observations about solving customer problems ("needing a 1/4 inch hole") over selling products ("the drill"). Red Hat wasn't "selling a Linux distro" but rather providing a professionally maintained and supported low cost PC-based server replacement for expensive proprietary UNIX systems on expensive proprietary hardware.
The interesting problems when using an externally developed open source project as a company are in understanding the flow of ownership of the intellectual property with respect to the software. There are a couple of predominant concerns:
As a company each of these legal concerns comes with additional legal responsibilities. Open source software foundations provide solutions to these problems by providing neutral non-profit space in which companies can collaborate together, and backing the space with proper IP management practices. The Apache Software Foundation, the Eclipse Foundation, the Linux Foundation (né OSDL) and the Outercurve Foundation were all created to manage the risk around these software IP problems.
The discussion becomes interesting when a company considers creating its own open source licensed projects. Rory's examples speak to benefits. Let's start with the motivation again. People are often very good at understanding their "gut" motivation for doing something. The larger a company becomes the more thought and documentation needs to go into such decisions, especially once a company goes public.
If the project to be published under an open source license is "infrastructure" for the company, then the motivations are all based on shared innovation and distributed engineering economics. This is what we see with data centre-centric projects created by the likes of Amazon, Yahoo, Google, Twitter, Netflix, or the Facebook Open Hardware Initiative. The company starting the project is sharing work in which they have invested time and energy in the hopes that others will join the project, use it in new ways thereby hardening the software and contributing at the very least bug reports, but also hopefully extending and evolving it.
When this is the motivation, all the discussion in the previous article comes into play around making open source. Essentially, one needs:
The additional consideration to encourage corporate participation and contribution needs to be software ownership, legal risk, and IP management around the contributions. This is where considering using existing open source software foundations comes into play. Corporations are far more likely to contribute their software to a neutral non-profit for mutual benefit.
But as Rory points out, there are business motivations for creating open source projects as well. A company's executives want to "increase business" but does that mean increase leads in the sales pipeline? Or build a community of evangelists that firmly anchor the company's products and services while providing proof points and expertise to potential new leads.
Using free and open source software in a commercial setting doesn't change the nature of running a business. One needs to clearly understand that customers buy solutions to problems and what problem the company is solving. Geoffrey Moore demonstrated some time ago that companies offering the best "whole" solution win, i.e. a core product or service and all its complementing products and services around a more complete ecosystem. This has a lot to do with shaping a "complete" solution to account for the subtle differences that customers perceive they have around the problem space. Successful companies essentially offer a portfolio of products and services and as long as the sum of the costs of delivering the portfolio is less than the sum of the revenues (spend less than you earn), the company is profitable. Taking a portfolio approach allows a company to play with their pricing models and differentiate themselves for customers against similar competitors.
Open source software can play a number of roles in such a portfolio approach. A company can:
These items all speak to the delivery of the product and the pipeline. A company can also develop a community of users of the open source project that act as a source of expertise and experience for potential customers.
A community of developers and users is an essential piece of the whole solution. Some companies develop large successful communities without ever publishing their product software. IBM, Microsoft, Oracle, and SAP have all done this to great success. This is why community building is so important for your company and why community development is an essential ingredient in your solution pitch to customers. User and developer communities (regardless of open source):
These variations all rely on remembering a couple of related "rules":
Creating an open source project can be as simple as publishing software using an open source license, and this gives customers insight into the workings of a solution. But if you ignore community building activities, you're losing all the benefits that come from an engaged base of customers and users of your technology.
Clearly understanding the benefits of using open source licensed software for delivering time-to-market, providing a rich complement ecosystem, and enabling communities to anchor the ecosystem in place allows a company to set its motivations correctly. One can discuss the investment in effort as a way to understand the motivation. We can contrast the publication of the software as open source and the effort required to develop the community against the evolution of the commercial product in terms of investment and value returned.
This also allows a company to understand the problems with half measures. Companies sometimes treat "open source" licensing as marketing pixie dust, instead of rightly understanding its place in the solution portfolio or the need to build genuine community that will lead to solving customer problems, and ultimately delighting said customers which can be measured in profitability. They try to limit access and only approach community half-heartedly because ultimately they're unsure of the benefits. Fully appreciating the benefits allows a company to fully engage with both community and customers to solve problems.
Rory also mentioned the use of open source projects to undermine a competitor's margins. This is a level of competitive play by large complex companies in well-established markets that warrants its own blog post. We save it for another day, and instead stay focused on the commercial positives of making open source software.
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week