Visualizing Open Source Business Models

Matt Aslett gave a great talk about the evolution of open source business strategies last week at the Open Source Business Conference in San Francisco. In it, he presented a model to allow one to visualize businesses that use open source in their solutions, and what it means in terms of relationships with customers and the community.

The community relationships are driven by the lower triangle:

The customer relationships are driven by the upper triangle:

Matt goes on to apply the model across a collection of companies and business models, visually demonstrating how different companies have made different choices and evolved those choices, as well as playing out a number of scenarios. It's an excellent model.

Matt and I have debated in the past as to whether or not there is such a thing as an open source business model. I've argued there's no such business model, but discuss it as a set of tools that are applied to the business. Regardless of one's opinions however, Matt has provided an excellent visual model for the discussion and presentation of the ideas. It works in much the same way as the Business Model Design template in visually capturing the information to ensure a completeness of discussion and an understanding of how the parts relate. I'm looking forward to the continuing evolution of the model over the coming year as he prepares the next major open source business report from the 451 Group, and would encourage you to give the entire presentation a read.

Comments

[Jack Repenning]

Any idea why Matt continues to ignore the most successful and profitable business-to-OSS relationship, "Open Infrastructure"? That is, fostering and contributing to a community OSS project that produces something you need, so you can get on with whatever you want to do? This is how most participants relate to Linux, for example; not to mention how *all* participants relate to Apache projects.

[Matt]

Jack,

As I answered when you asked a similar question before http://blogs.the451group.com/opensource/2009/11/11/copyrightleft-at-the-centre-of-open-source-business-strategies/comment-page-1/#comment-491774 this is actually covered in the explanation of this slide, but it not explicit within it. The strategy you describe would be covered by the "open complement" licensing strategy, in our model.

[Matt]

P.S. Thanks for blogging this Stephen

[Jack Repenning]

Sorry I missed your earlier response, Matt. But I don't think Open Infrastructure should be lumped as a subset of Open Complement. There are many big differences between

- creating a (possibly proprietary) core platform where others contribute open-source value (one part of your open-complement space).

- supporting an open community that openly creates something you need, in order to provide your own (possibly proprietary) product on top of it.

Consider, for example, the companies whose employees contribute to Apache projects, like httpd or Subversion. None of them is selling the project output, yet all the web depends on infrastructure components like these. Companies contribute to these projects because they believe they can make more money in a world that has these resources.

This is very different, in many ways, from creating a community that can openly expand and extend on your base product.

Because these terms describe the relationship between a company and a project, and large projects involve many companies, some companies will have one relationship while others have another. When Red Hat, for example, contributes to RHEL, there's an "open complement" aspect to the strategy: Linux is a platform for doing other things, and most people who use Linux use it to do other things: to complement the core.

But when another company contributes to Linux, they may be doing it to create infrastructure on which they depend. They may fix a kernel crash, for example, because they've found it keeps crashing while running their product, and people don't like to pay for products that make the kernel crash.

Another distinction is almost too obvious to mention: if your "openness" is "openness to others creating stuff that can only run on my platform," your contributions are still pretty enclosed. But if your "openness" is "contributing to open projects that help everyone," then you're open in many dimensions.

[Matt]

Jack,

I would agree the approach you describe is not covered in our model. Part of my reason for presenting this was to engage in conversation and highlight flaws in the model that can be fixed ahead of our report being published later this year. In my presentation I talked a little about different strategies that are subsets of Open complement - providing a proprietary product on top and using open source to drive innovation around a proprietary product, for example. Those are also not explicitly represented in our model. I think at a practical level they may be a level of detail beyond the scope of the model, but I will investigate how they could be added. If you have any suggestions, I'd be happy to hear them.

Thanks
Matt