Open Source Business Models Redux

I debated again yesterday with a colleague on open source business models. I don't believe there is such a thing. Several well documented models have been articulated and debated (see Matt Aslett, Roberto Galoppini, Carlo Dafarra for excellent cogent examples) but when you get into the discussion it immediately degenerates when you try to assign certain companies to certain models. It degenerates further when you try to invert the discussion to argue that these stylized business models share attributes or can be applied together when discussing example companies. To me it's a useless rat-hole of a discussion.

It confuses audiences into thinking "open source" (or "free software") is different in a business context. Such confusion:

• Slows adoption by customers.
• Causes investors to hesitate.
• Can lead inexperienced start-up executive teams to chase ghosts instead of focusing on the business at hand.

Here's how I tried to articulate the counter-debate yesterday:

1. Customers buy solutions. In the immortal words of Theodore Levitt (Harvard Business School), “People don't want to buy a quarter-inch drill. They want a quarter-inch hole!”
2. Geoffrey Moore wrote "Crossing the Chasm" in 1991. As well as clearly articulating the Technology Adoption Life-Cycle (that he has evolved over the ensuing ~20 years), it helps people understand that developing a "whole product" offering (the core product and its complements) provides a better solution to customer needs and companies in a market that provide the best whole solution succeed better than their competitors and peers.
3. For technology solutions companies, there are a well understood collection of tools that product development management uses to deliver solutions.
• Buy or build complements and include them in the base product.
• Publish interfaces to encourage complement value add in an ecosystem of partners.
• Provide tools and frameworks to ensure partners can easily build complementary products in the ecosystem, providing an even bigger "whole solution" or enabling it to be re-positioned into new markets (i.e. onto new problems).
• Publish tutorials, how-tos, books, etc. to ensure people understand the product solution and can provide complement value add in the ecosystem. And publish here is a very loose word. Consider magazines and conferences and user groups here as well, and how the web helps or supplants each. The web removed enormous friction from this collection of related tools.
• Develop training programs to ensure people understand the product solution.
• Develop certification programs to ensure a good supply of knowledgeable people on the solution.
• Provide consulting services to ensure an immediate supply of knowledgeable people on the solution. Really though it could be other services as well (maintenance, repair, operational, etc.)
4. Companies can choose to sell (or license) the complement or give it away. In each case there's an opportunity for direct or indirect revenue. As long as the sum of the revenues is greater than the sum of costs of providing the whole solution (and operational margins are within tolerances specific to the "tool" or tactic or mix in the portfolio) the company is profitable and thrives. [Indeed, over time as value moves around the solution network — and it's a network not a stack — companies have a better chance of survival if they control more of the higher margin pieces of the network that is their whole solution or ecosystem. Think IBM with the breadth of whole solution they can deliver posting better than expected results September 2008 as the rest of the economy tanked.]
5. The larger the company, the more tools it likely uses in providing a whole solution. Maybe this is the corollary to the above statement. It certainly explains why we all rat-hole when trying to fit large complex companies into the stylized business models.
6. Adding open source licensed software repositories on the web and collaborative community development into the mix adds new tools, and evolves old tools:
• To "buy" vs "build" for complement value add, you can add "borrow" (IBM Websphere and Apache, and Red Hat and RHAS) and "share" (IBM and the original Eclipse project, and Intel and moblin).
• New companies (Red Hat) with lower margin business models (compared to the incumbent) can use F/OSS components to rapidly develop products that either serve new markets or serve the bottom end of an over-served market and then evolve over to or up into an incumbent’s market space. [Classic Christensen economics here.]
• It broadens the base of "users" which opens future customer opportunities and locks out competitors. (JBoss and MySQL used this tool.)
• Companies that participate in communities:
• Can rapidly develop complements to core offerings in their solution network (without necessarily building complete products), e.g. SAP and MaxDB and MySQL
• Can amortize dev/support/maint costs of software components across customers/partners/competitors (e.g. the vendors in the Linux Foundation today are no different than the vendors in the OSF 20 years ago sharing the development costs of OSF/Motif and OSF/1 as royalty free base technology).
• Get to interact directly with like-minded customer prospects in community, influencing customer/partner developers.
• Build brand awareness and trust through transparency of actions.
• Companies that participate deeply in communities better influence those communities (e.g. participate, hire, or acquire).
• Companies developing their own communities increase the opportunity for partners to provide complement value add as well as encourages engagement and commitment through participation and contribution.
• Companies can use F/OSS projects to reduce the cost of sales by allowing users to try and pre-qualify themselves as customers.
• F/OSS projects are an interesting publication strategy against competitors from an IP strategy perspective.

What all of this means is that the ideas need to be turned around. Technology businesses and technology adoption is well understood. We know how to measure successful companies and compare them. We understand the tools those businesses use to engage customers and solve problems. Open source software is a key economic driver from an engineering efficiency and software reuse perspective, but it also opens new opportunities and additional tools for product management to engage better with customers and improve both the top line and the bottom line.

But there is no open source business model.

Comments

[Carlo Daffara]

Dear Stephen, many thanks for the interesting post. I would like to point out a thing about our research: while the classification of business models we developed was derived from real-world observation (on more than 200 companies) I am not claiming that there is a 1-1 matching between company and model- the reality is that companies are usually mixing more than one model, and changing that mix with time (as I wrote: "We found that the most probable future outcome will be a continuous shift across models").
The reason for study them is related to what differences may be introduced in a company by adopting one model versus the other; and this has an impact in helping businesses align their expectation and strategies.
I would not subscribe to your point that "OSS business models don't exist"- they clearly do, and in some cases are radically different from traditional ones (for example: dual licensing, that is possible only when one of the license is a strong copyleft license). It is true that OSS does not change the basic economic facts of a company- the fact that it must sell something.

[Swashbuckler]

“People don't want to buy a quarter-inch drill. They want a quarter-inch hole!”

Fun quote, but... not really accurate. How many people just want a quarter-inch hole? What they really want is:

- To make the room nicer by hanging a picture (which requires a hole)

or

- To have a TV in the kid's room (which requires stringing out cable, which requires a hole in a wall to be done safely)

[Stephen Walli]

@Carlo: Thanks for the commentary (and indeed for all your continued great observations). Your example of "Dual Licensing" is exactly the sort of example I object to when people discuss "open source business models". It's an artifact of copyright law. I can license my intellectual asset to as many people I want in as many ways as I choose.

The Microsoft EULA attached to software at the local office supply store is different to the Enterprise Agreement signed when a corporation purchases based on a bundle of units and services is different again from a volume license to a smaller organization. No one accuses Microsoft of "dual" or "multi-licensing" their software.

The fact that MySQL began selling closed licensing royalties as well as selling service agreements (i.e. product) of their GPL distributed software does not mean that they invented "dual licensing". It's just business.

[Stephen Walli]

@Swashbuckler: Thanks for the commentary. I do agree with you. I like the quote more for the shock value of reminding a company that what they're selling isn't name-of-their-own-god-like-technology but rather a solution to a customer's problem. It's the difference between core value proposition (outward customer focus) and the core competencies (inward focus) that enable the value proposition. Microsoft wasn't a software company to its customers, they were a business appliance company that enabled business people to break the chains and the wait with corporate IT departments. The core competency was software. Indeed today Microsoft really does the certified warranted binary (competency) better than anyone when you consider the size of the test matrix they need to exercise (OEMs, ISVs, devices). But people think Red Hat some how invented it as an "open source business model".

[Carolyn]

Good article. But can you please give a definition of an 'open source business model'? I can't tell who is right about its existence or non-existence without knowing what it is.

[Simon Phipps]

I'd go further, Stephen. To assert there is "an open source business model" is to lose sight of the nature of open source.

An open source project is a community of participants that gathers around a free software commons, with each participant aligning a fragment of their interests with the interests of all the others there in order to collaborate. Each participant comes to the community with their own individual interest, which in the case of a business will stem from their business model.

An open source community is thus a mix of many motivations. If there's only one motivation present - only one "business model" - it's unlikely there is any true community either.

[Carlo Daffara]

Dear Stephen, thank you very much - I also enjoy all your contributions.
I absolutely agree that most of the discussion on OSS business models is usually not very solidly grounded, but I am still unconvinced that the example of "dual license" is just an artifact (it would not be possible without the GPL...)
Anyway, the real problem is the fact that most discussion on OSS is based on very vague definitions and some myths that are not a good basis for real discussion- both for research and for structuring a business on.
Pragmatic discussion is a good way to clear away misconceptions :-)

[Simon Phipps]

Carlo: Dual licensing is an artefact of the aggregation of copyright, not of open source per se. when any single entity owns the full copyright to a work, they can license it as many ways as they want. Moreover, the license they use can contain whatever terms they want - including terms that reverse the freedoms in the license itself.