A classification of open source business strategies

UPDATE An updated version of the business strategy classification can be found here. UPDATE

How does IBM’s open source strategy compare to Sun’s? Or Microsoft’s? What’s the difference between MySQL’s strategy and JasperSoft’s? Are some strategies better suited to engaging with organic open source communities, rather than inorganic? What on earth is the Open Core model?

These are some the questions we hoped to try and address with our Open Source is Not a Business Model report, published in October last year. As I mentioned yesterday, however, without an agreed set of definitions and a common vocabulary it is difficult for a broader understanding the implications of the various models to develop.

One of the ways we might be able to do that is to map the categories we used in our report to the taxonomy used in other reports, for example, the one published by Carlo Daffara that updates the original taxonomy used as part of the FLOSSMETRICS and OpenTTT efforts.

I believe it is possible to map the two together, and provided an example of how this could be done. But I am aware that it is impossible to align our taxonomy with others in the industry and encourage better understanding without publishing more details of the categories we used.

I have also noticed some confusion about various strategies (including Open Core) in recent days, so publishing our classification provides a single resource we can point towards.

Of course, there is more to Open Source is Not a Business Model than just the classification, and for some insight into how these strategies are being used, by which vendors, and to what end, I’d encourage you to take a look at the complete research report.

The report also includes details on how the various development, licensing and revenue strategies influence each other; the relative strengths and weaknesses of each strategy category; how third parties generate revenue from open source; the commercial implications of permissive and reciprocal licenses; future revenue generation strategy trends; sales strategy trends; and more besides.

I will also be speaking about the report and its results at various events on my forthcoming US trip.

With all that in mind, here’s the classifications we used:

    Development Model

  • Vendor Open Source
  • The software is distributed using an open source license, and all contributions are public, but development is dominated by the employees of a single vendor.

  • Community Open Source
  • The software is distributed using an open source license and is developed in public by a community of individuals and/or vendors.

  • Mixed Open Source
  • The product or service provided by the vendor is based on a combination of projects using open source software developed publicly by multiple vendors and/or communities.

  • Hybrid Vendor
  • Development is dominated by the employees of a single vendor, and some functionality is developed behind closed doors.

  • Hybrid Community
  • The underlying software is developed in public by a community of individuals and/or vendors, and some functionality is developed behind closed doors.

  • Hybrid Mixed
  • The product or service is based on a combination of projects using open source software developed publicly by multiple vendors and/or communities, and some functionality is developed behind closed doors.

    Vendor Licensing Strategy

  • Dual Licensing
  • A single code base is licensed to different users using either an open source or a commercial license.

  • Open-Core License
  • The core code is available using an open source license, but enterprise or professional versions include open source code and closed source extensions and are licensed commercially. (See also Andrew Lampitt’s definition).

  • Open-and-Closed
  • Open source products are complemented by separate closed source products that are developed and sold separately under a commercial license.

  • Single Open Source
  • There is a single code base with a single, open source license.

  • Assembled Open Source
  • The product or service includes code from multiple open source projects that utilize multiple open source licenses.

  • Closed
  • The product is based on open source code but is not available under an open source license.

    Revenue Triggers
    (It is of course possible for a vendor to have more than one revenue trigger. In fact, our analysis indicated that the majority of vendors were deploying more than one revenue generation strategy, with some utilizing four different triggers for a single product.)

  • Commercial License
  • A traditional commercial license not approved by the OSI or the FSF.

  • Subscriptions
  • Annual, repeatable support and service agreements — effectively an insurance policy against the need for ad hoc service and support, which may also provide updates and other services.

  • Service/Support
  • Ad hoc support calls, service, training and consulting contracts.

  • Embedded Hardware
  • The open source software is distributed as part of a hardware appliance, or with a commercially licensed hardware product.

  • Embedded Software
  • The open source software is embedded within a larger commercial software package.

  • Software as a Service (SaaS)
  • Users pay to access and use the software via the Internet.

  • Advertising
  • The software is free to use and is funded by associated advertising.

  • Custom Development
  • Customers pay for the software to be customized to meet their specific requirements.

  • Other Products and Services
  • The open source software is not used to directly generate revenue. Complementary products provide the revenue.

As I say, this list is being published in the hope that it encourages greater understanding and enables the emergence of an agreed taxonomy, and we would welcome any comments and suggestions as to how it could be improved and/or manipulated to complement existing taxonomies.

Tags: , , , , , , , , , , , , , , , , , , , , , ,


#1 Ian Skerrett on 03.12.09 at 7:42 am


I think it is great that you are leading these conversations. It would be nice to get to a common taxonomy. However, a taxonomy that includes 10 different models is just too complicated. It needs to be simplified.

For instance, I still do not see the difference between open-core and open-and-closed. It seems to me that in both models you are selling commercial software on top of a widely adopted oss core? The strategy is to create many potential customers by having low barriers to the core and then up sell them. How are the two different?

#2 Matthew Aslett on 03.12.09 at 8:08 am

Thanks Ian,

I agree it can be a fine line between Open-Core and Open-and-Closed. The way I would differentiate it is that with Open-Core the commercial software extends and is dependent on the core open source software, whereas with Open-and-Closed the commercial product complements the open source software.

An example that makes use of the “Embedded Hardware” revenue category would be a strategy that creates a commercially-licensed hardware appliance that uses open source software project. There are many examples of this in the security sector.

Using an “Embedded Software” example I would suggest IBM’s use of Apache within WebSphere. The WebSphere code and the Apache code are complementary rather than interdependent and IBM’s strategy (in this example) is not necessarily a matter of creating potential customers but R&D cost sharing, building on a quality standard commodity building block.

#3 Ian Skerrett on 03.12.09 at 9:16 am

If there is a fine line then I would suggest combining them would be an improvement. The fact that it depends or complements seems to be a technical detail. The strategy though seems to be consistent in the fact you want a wide customer base to sell into.

My 2 cents…

#4 Matthew Aslett on 03.12.09 at 9:26 am

The fact that it depends or complements might be a technical detail but the strategic reasons for deciding to do one or the other is not, IMO. Additionally a complementary strategy is better suited for engaging with organic communities, interdependence for inorganic

#5 Brian Aker on 03.12.09 at 9:43 am


You have way to much taxonomy.

You could just make this simpler by saying we have open source, and we have attempts to put a bow around crippleware, and make it look like it is open source.


#6 Poker Blog » Blog Archive » For the Record: Open Publishin… | Open Publishing Group, Inc. on 03.12.09 at 10:30 am

[…] 451 CAOS Theory » A classification of open source business strategies […]

#7 451 CAOS Theory » A classification of open source business strategies | Justin.lt on 03.12.09 at 12:31 pm

[…] The rest is here: 451 CAOS Theory » A classification of open source business strategies […]

#8 Henrik Ingo on 03.12.09 at 2:59 pm

Hehe, uncompromising Brian at work.

I guess there is nothing wrong in trying to categorize things you observe actually happening. For instance Microsoft incorporates BSD code into Windows, we all know it, yet they vehemently deny it (“Well maybe there once was some tcp/ip stack but at least in current windoses it is all rewritten.” “Sure we only use an etc/hosts file for added fun?”)

So you could argue this is Microsofts “Open Source Business Model”, it is then a completely separate question which models actually qualify as meeting the Open Source values, and I agree with you there is no reason to pretend that something that isn’t Open Source would be.

I once categorized various business models along an “ethical-unethical” axis:
Business models of a hacker. Some of the modern ones didn’t exist at the time of writing. (And I also didn’t use these academic terms as Matthew does, doesn’t fit my style really.)

#9 Matthew Aslett on 03.13.09 at 5:19 am

Interesting. I’m sure someone could do the same with the categories in our study. I’ll leave that to someone else though – being the arbiter of ethics when it comes to open source business strategies isn’t my style 🙂 As you say, we categorize what we observe happening, and we make suggestions as to the strengths and weaknesses, but “ethics” are in the eye of the beholder

#10 Boycott Novell » IRC: #boycottnovell @ FreeNode: March 12th, 2009 - Part 3 on 03.13.09 at 6:24 am

[…] These guys really turns FOSS into something ‘unsexy’: http://blogs.the451group.com/opensource/200… […]

#11 451 CAOS Theory » 451 CAOS Links 2009.03.13 on 03.13.09 at 8:23 am

[…] various open source business strategies with the aim of finding a common ground. You can also read our categories, and an example of how Carlo’s taxonomy could be mapped to our […]

#12 451 CAOS Theory » Define “free software vendor” on 03.17.09 at 4:51 am

[…] Interestingly this is very similar to the approach we took when assessing vendor strategies as part of Open Source is Not a Business Model, where we examined the development, vendor licensing and revenue generation strategies. […]

#13 451 CAOS Theory » Towards an agreed taxonomy for open source business strategies on 03.24.09 at 11:16 am

[…] I will publish the descriptions of the various categorizations we used within OSINABM in a later post. Permalink | Technorati Links | Bookmark on del.icio.us | digg it Categories: Business models, […]

#14 vineet on 03.31.09 at 1:45 am

Hi Mathew….where do you place the IT System Integrators that and provide ‘solutions’ and ‘services’ to businesses using open source integration, development and support. Also these companies participate and contribute to open source communities while solving real business problems.

#15 Matthew Aslett on 03.31.09 at 3:53 am

Hi Vineet,

It would depend on the SI concerned and the project but typically we would see them using hybrid mixed development and assembled open source licensing (as they are involved with multiple open source projects but often do not contribute back) and support and customer development revenue models, as well as other products and services. The classification is better suited to product specialists than broad I must admit, and I think this is something we would address in any future version.


#16 451 CAOS Theory » Strategies for creating business opportunities based on open source software on 09.18.09 at 5:48 am

[…] An explanation of these and the classifications that we came up with can be found here. […]

#17 Once More unto the Breach on 09.22.09 at 4:19 pm

Making Money from Open Source and the Business Model Debate…

Matt Aslett makes great observations about open source business models in a recent blog follow-up discussion: I am very glad that they took that decision, because in hindsight the statement “there is no open source business model” would have been…..