Making commercial open source software

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:

• A company can contribute to an open source project that already exists.
• A company can create a new open source project (either by publishing existing software or creating new).

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 Enterprise Linux. 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:

• What legal risks are possible that need to be managed against a company’s risk profile. This should not be taken lightly. Companies are more interesting legal targets than individuals. Even if a company is using the software internally rather than in a product or service, there is still a risk profile to consider. It’s not that the risk is greater than purchasing a proprietary software solution from a vendor but one needs to feel comfortable that the externally run open source licensed project has appropriate IP management safeguards in place.
• What intellectual property is being contributed to whom. Again, companies are often uncomfortable contributing their own hard won R&D investment to others (even partners) without crisply understanding the return.

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:

• Useful software as a base around which to build a community.
• Motivation to share, credible expertise in the problem to be solved, and an understanding of the software structure to anchor the open source community.
• The project needs to have the structural issues of license, forge, and governance decided, even if governance becomes an evolving discussion in a growing community.
• The community needs to build a solid onramp to encourage use, and a second onramp for users to become contributors. The sooner this happens in a project’s life, the faster it can build a community.

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:

• Sell support, upgrades, customization, training and "stability" to a product that is otherwise provided as an open source project. The best example is probably Red Hat "selling Linux" when it doesn’t own the core IP. The "product" isn’t the software. JBoss tried several of these approaches before their Red Hat acquisition.
• Sell a core product (licensed as proprietary or open source) while encouraging an ecosystem of complements from partners around open source licensed projects.
• Allow customers to try the "product" in its simplest form as a set of unsupported unwarranted binaries for "free", i.e. downloading the community/developer editions, to self-qualify themselves in the sales pipeline. (This was very much how MySQL built both its businesses.)

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):

• Anchor customers both in an engaged relationship as well as from a technology perspective.
• Create knowledge, expertise and experience necessary to provide a complete solution for the technology pitch to the customer. These proof points are invaluable when potential customers are self-qualifying themselves and testing the strength of a solution’s community.
• Create advocates and evangelists to spread awareness about a solution.
• Create enormous inertia in the status quo around a technology. 
• Harden the solution by testing it in new scenarios and reporting issues.

These variations all rely on remembering a couple of related "rules":

• An open source licensed project is not a complete product solution for most people.
• Project community users and developers are not solution customers. Community members tend to have time to spend on a solution but no money while customers have money and are looking for time-to-solution and certain guarantees.

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.

Originally posted on the Outercurve Foundation Blog. Re-posted with permission.