Open-Core Licensing (OCL): Is this Version of the Dual License Open Source Business Model the New Standard?

On the topic of commercial open source business models, I think MySQL chief Marten Mickos gives a great overview.

Having worked for the company with the most widely deployed (open source and otherwise) business intelligence solution the past two years, I have come to appreciate what appears to be the standardization of a certain open source business model, a specific kind of 'dual license' (#6, "Commercial Extensions" in Marten's list). I believe some dual license strategies have gotten a bad rap, perhaps because of the confusion they cause or the approaches vendors take. I propose to rename this #6 dual license strategy as "open-core licensing", to remove confusion and promote a great business model for open source communities, paying customers, and vendors alike. (and this does not prevent using other means of revenue generation including #3 and #4 on Marten's list: if you embed it in closed source, you pay a fee; services are for a fee).

Dual license means that a vendor owns the intellectual property of a product, and they therefore have the rights to license it in two ways: an open source license (nearly always GPL), and also a commercial license. The vendor may choose to have the commercial license's bits be precisely the same as the GPL product's bits, or not. The really interesting version is, as in #6, when 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. (and the commercial license extra features might even have 'viewable code' albeit not fully GPL). This is highly interesting for customers and the vendor for a variety of reasons. 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 (ie, GPL core, with commercial extensions.)

Typically, a religious open source war breaks out on this point. Some say that this dual license strategy is OK, but as long as you follow the spirit of segmenting by user base, not features. (Fabrizio Capobianco notes that it also becomes difficult for a product manager to determine which features should be commercial and open source. A struggle happens within the vendor between the community leader and the sales manager. Perhaps a timebomb on all commercial features after a certain period of time from the commercial GA date makes those commercial features become GPL, but that may not be workable as it would make a long-term business model a lot trickier.) It seems that this model did not work for some vendors in the past due to 'angering the community.' I suspect the tension arises from how commercial open source companies are sometimes perceived as hi-jacking the term "open source" for marketing commercial gain. In my view, the business model could probably be better received by the community if it were named more specifically, such as "open core" that has a specific definiton attached to it.

For the customers this dual license is great; they get to kick the tires, or even use permanently, a GPL a "core" product license, free of charge. In addition, the customers enjoy, in a way, guarantee of liberty from the vendor; if things go sideways for the vendor, there is a sort of a "guaranteed escrow" of the source code thanks to the GPL license. The other, and arguably bigger benefit, is that which comes along with the code being open source. I am not saying that most customers will want to dive into the code themselves -- far from it. Rather, the open source nature of a product promotes a lively ecosystem that pops up around it. That ecosystem might be driven by a handful of hardcore developers and/or partners, as well as the occasional "long tail" specialist contributors. None-the-less, the benefit is there. You no longer have, as in Microsoft's case, an omnipotent power holding your future ransom over its API's and source code. I think this is one of the core values and dreams of the open source movement, and I think it is safe to say that it is playing out beautifully when you look at the leading open source ecosystems out there: Linux, Apache, MySQL, Eclipse, OpenProject, Talend, Mulesource, Alfresco, Drupal, Sugar, Jaspersoft, etc. They all have absolutely thriving communities thanks at least in large part to the open source model. And everyone benefits. Of course proprietary vendors can have large and vibrant communities also; I am just saying open source is one useful vehicle to make it happen, and typically more quickly.

Customers also benefit from the vibrancy of an open source industry, backed by profitable and thriving companies. The commercial open source companies act as strategic and full-time champions to the open source movement.

Now how do the vendors benefit? Well, that's easy. They have a way to more effectively monetize the large, open source communities by charging for significant extra value that they are delivering to the customers. Of course, the community still gets the core, commodity features as GPL, so they are losing nothing while gaining a prominent, full-time champion in the vendor. If the extra features are useful additions at a reasonable price, customers will be happy to pay for the value-add. I have observed with interest how some commercial open source vendors swear that they are earning significant revenue solely from training, professional services, and technical support - and of course indemnification. And then industry pundits responds, "oh, services -- does that really scale?" And then the stammering begins. No, a services model does not scale well for a software vendor.

This all leads to confusion by customers and backpedaling by some commercial open source vendors. For customers, they are confused by "what is really open source?" Some vendors use GPL; some swear by only MPL, LGPL, Apache, etc.; and still others issue their own flavor of open source license with some "small" strings attached. And those "purist" open source vendors stoke the FUD by pointing fingers at what is and is not "true open source." It seems there is still a lot of confusion on what business model makes sense for opens source. And at the same time, some leading open source vendors who do not openly evangelize the dual license model feel stuck between their open source religion and a mission to earn a profit. They are apologizing to their communities and to the market as they nudge themselves towards the inevitable dual license model. They indeed are beginning to offer commercial add-ons while nearly apologizing and trying to defend themselves that they "really are pure open source." Don't worry, guys, there is no evil behind dual license. Quit apologizing and go for it. Everyone wins.

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. (Except those poor vendors who do not own their intellectual property; I am sure they will be happy to tow the traditional line.)  And perhaps we could clarify the point if we were to use a new term, for example, "Open-Core Licensing." (not to be confused with the very interesting Open Core project.) 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. So who is using "open-core licensing" successfully? Well, Sugar, Jaspersoft, Zimbra, and Talend to name a few of the rapidly growing list. Even MySQL may already be in that category, up for interpretation perhaps; it may depend upon whether the definition requires commercial extensions to have viewable code or not. This "OCL", I suspect, is probably to become the standard business model of commercial open source. Do you agree? If so, shouldn't we give this specific dual license model a more clear and descriptive name? If not "Open-Core Licensing," ideas welcome...

So I propose the following for the OCL business model:

- core is GPL: if you embed the GPL in closed source, you pay a fee

- technical support of GPL product may be offered for a fee (up for debate as to whether it must be offered)

- annual commercial subscription includes: indemnity, technical support, and additional features and/or platform support. (Additional commercial features having viewable or closed source, becoming GPL after timebomb period are both up for debate).

- professional services and training are for a fee

Don't worry, not all is solved in this blog post. Still plenty of room for debate. If this dual license receives wide recognition from commercial open source vendors and communities, next, we can debate as to whether the commercial license in OCL has viewable or closed code for the extra features, as well as if commercial extensions should automatically timebomb to GPL 18-24 months or so after the GA date of the commercial features. I look forward to alternative ideas and debate too.

================

note on Aug 31: I learned today that Barry Klawans and Paul Doscher deserve credit for being the ones that devised the OCL business model that I am describing (including viewable source for commercial extensions) when they were at Jaspersoft. They took inspiration from MySQL and Sugar, but Barry also added the "viewable code" clause for the commercial license due to feedback from the community. Some community folks noted that if the commercial extensions are closed source, it takes away some of the great benefit from going with an open source product in the first place. So Barry came up with 'viewable code' as a happy medium.

==========

****Special thanks to Matt Dahlman and Sherman Wood for their edits and input to this post.

==========

Check out my other blogs on Open-Core Licensing:

• New and Improved Open Core, with AGPL (FEB08)
• Open Core: the New Standard in Commercial Models (MAR08)
• Variants on Open Core: (APR09)

Comments

[Matt Aslett]

Welcome to the blogosphere. Nice first post. The model you refer to has also been referred to (not widely, although I use it in a forthcoming report) as Split Licensing (to differentiate from Dual Licensing). I'll follow up with more discussion later.

[Barry Klawans]

Andrew, thanks for the acknowledgment - I'm rather proud of what was created when I was with JasperSoft. I feel forced to be humble though - the concept of "visible source" for commercial extensions came from a panel I attended at OSBC one year, and then a couple of panels I was on at various events. At the original panel a buyer of open source (unfortunately I can't recall who) pointed out that the option of closed-source extensions was a non-started, since it eliminated most of the benefits of going with open source in the first place.

It was one of those "why didn't I think of that?" moments where once said, something seems obvious, but in fact wasn't. After that I had a series of discussion with folks at various events which resulted in the "visible source" (or in JasperSoft's case, "modifiable source") for commercial extensions.

-Barry

[Curt]

Andrew,

I wonder if it's important to draw a distinction between 'extensions' and 'applications'? Extensions imply a superset of the core technology (as you point out); whereas I think of an application as a different program running on or with the open source software. What I'm getting at is, is there a category for this - namely, 1) a GPL code base; 2) a commercial version with identical bits, and 3) closed source applications that can be run with either license?

[Andrew Lampitt]

I am not sure I follow you, Curt, but some comments:
1) distinction between 'extensions' and 'applications.' Well I think the distinction concept is dependent upon the context of the type of software we are talking about and the context in which it is used. Let's take a BI tool for example. BI can be a component inside another application, but it can also be a standalone BI application itself.

2) yes, agreed that it makes sense to have commercial versions that are without (ie, same as GPL bits) and with premium extensions. Typically any company that does OCL will let you license the GPL bits with a commercial license.

[Tristan Rhodes]

Andrew,

Excellent post, I find myself agreeing with your points. Defining this business model and giving it the name "Open-Core Licensing" can help present a positive image when talking to open source communities. The relationship between vendor and community CAN be a mutually beneficial one.

Keep up the great posts,

Tristan

wow.. great info at this post thanks!!

nice reading ;)

[Arabic Translator]

There still a number of effective business models for opensource. I believe the basis for the Opensource phenomenon is that services can actually drive more revenue than code. If you are the defacto source for the code then you can control the knowledge associate with the most profitable services. This is a smart strategy.

[Andrew Lampitt]

In response to Arabic Translator, I will summarize all of my open core blogs in a few lines:

The whole point around open core is to articulate the most scalable business model for commercial open source.

Offering services is not more scaleable than offering a product. That's because with professional services, you have to maintain qualified headcount and keep them billable. For a product, you simply charge additional customers for the same bits you already created for customer #1.