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:
- Vendor Open Source
- Community Open Source
- Mixed Open Source
- Hybrid Vendor
- Hybrid Community
- Hybrid Mixed
- Dual Licensing
- Open-Core License
- Single Open Source
- Assembled Open Source
- Commercial License
- Embedded Hardware
- Embedded Software
- Software as a Service (SaaS)
- Custom Development
- Other Products and Services
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.
The software is distributed using an open source license and is developed in public by a community of individuals and/or vendors.
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.
Development is dominated by the employees of a single vendor, and some functionality is developed behind closed doors.
The underlying software is developed in public by a community of individuals and/or vendors, and some functionality is developed behind closed doors.
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
A single code base is licensed to different users using either an open source or a commercial 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 source products are complemented by separate closed source products that are developed and sold separately under a commercial license.
There is a single code base with a single, open source license.
The product or service includes code from multiple open source projects that utilize multiple open source licenses.
The product is based on open source code but is not available under an open source license.
(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.)
A traditional commercial license not approved by the OSI or the FSF.
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.
Ad hoc support calls, service, training and consulting contracts.
The open source software is distributed as part of a hardware appliance, or with a commercially licensed hardware product.
The open source software is embedded within a larger commercial software package.
Users pay to access and use the software via the Internet.
The software is free to use and is funded by associated advertising.
Customers pay for the software to be customized to meet their specific requirements.
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.