JasperSoft’s business development director Andrew Lampitt has kicked off his new blog with an interesting post related to business models used by open source-related vendors.

In it he attempts to define the approach utilized by the likes of JasperSoft and SugarCRM, which offer open source products with core functionality, as well as commercial extensions. The approach is a twist on the dual licensing approach made famous by MySQL* where the vendor, as copyright holder, makes the code available under both the GNU GPL and a commercial license for customers that would rather avoid the GPL.

The approach taken by JasperSoft et al is not to segment by user base but by features. As Andrew explains, “the commercial license is a super-set of the open source product, i.e., it offers premium product features that you will not see in the GPL license.”

The model is widely used (Hyperic, xTuple, Zenoss, Talend and GroundWork also use it) but has not been properly defined. Savio Rodrigues has referred to it as the “Product Driven OSS Business Model”, Carlo Daffara calls it Split OSS/Commercial, while I have used the term “Split Licensing”.

Andrew recommends referring to the model as Open-Core Licensing, arguing: “My feeling is that we would save a lot of confusion for communities, customers, and vendors if all recognize that a dual license ”open core” model is a sensible business model for all involved,” and that “In this way, it is clear to customers that there is a “core” open source product that is GPL, and there is also additional high-value available as add-on features for purchase.”

Defining the model is important because it should help customers understand the actions and strategies of their vendors and, as Andrew puts it: “If you rename what it is called, you help to remove the “bait and switch” controversy by openly recognizing it as an emerging standard business model with specific attributes associated to it.”

(It is also important to distinguish between Open-Core Licensing and what I would call Embedded Open Source, where the open source code is embedded with a larger commercial package - for example IBM has for many years embedded the Apache HTTP server within its WebSphere middleware, while the Apache Geronimo project forms the basis of its WebSphere Application Server CE product. There is sometimes a fine line between the two models.)

The term Open-Core Licensing (OCL) certainly makes sense to me and I have decided to adopt it for The 451’s forthcoming report on business models related to open source software. I had originally used the term “split licensing” but have decided to switch to OCL as some people use the term “split licensing” interchangeably with “dual licensing”, such as in this research report from the University of Southampton. (Just to confuse things further, Carlo uses “twin licensing” rather than “dual licensing”).

Another example of “split licensing” being used to describe what I would call “dual licensing” is this blog post by Kirk Wylie, a software engineer in the financial services sector, which also eloquently describes why the OCL model is of interest to customers as well as vendors.

“Let’s say you’re an open source company, and you’re trying to figure out how to sell yourself to me in the Money… “What you have to do is give me something tangible if I give you money. It’s just that simple,” he writes.

“Give me a cookie. Seriously. Give me something I only get if I pay you… It might be development tools… It might be support tools… It might be domain-specific functionality… Heck, figure out how to leverage GPGPUs or Infiniband or whatever. Just find something that I’m going to have to pay you for, and make sure it’s of merit to me. Then sell me that with my support contract.”

(Kirk also concisely describes why the subscription services model doesn’t cut it for the company he works for: “No matter how good your SLA is, getting someone to remote diagnose a problem over a telephone line during a production outage with traders yelling at you is impossible… This means that support is mostly useful pre-production, and post-outage post-mortem. In the middle of the crisis, it’s less than useless. If you can’t fix it, you shouldn’t be running it.”)

One of the issues that Open-Core Licensing raises for vendors is deciding what that cookie will be (it’s what Matt Asay has called “the nettlesome question”). It is up to the vendor to try and decide what features should be commercial and how the balance between the core and the extensions changes over time.

Savio has suggested drop-feeding features from the commercial to the open source product over time, with new features added to the commercial product to ensure customers continue to be willing to pay.

Andrew cites “a timebomb on all commercial features after a certain period of time,” that “makes those commercial features become GPL” but notes that it may not be workable “as it would make a long-term business model a lot trickier”.

As this suggests, there is more to discuss with OCL than its name. Some of the plusses and minuses of the model were discussed here. Andrew also makes the point that it is also debatable whether the code for the commercial extensions should be visible or completely closed.

Naming the model is an important first in setting the terms for the debate, however, and even though it means re-writing my ongoing research report, Open-Core Licensing gets my vote.

*Commercial licensing, via the dual license model, was originally responsible for driving MySQL’s revenue growth, although in recent years subscription services have been a more significant revenue generator.