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.