Lampitt or Leave It

Open-Core Licensing: Variants Include VC and CC

My four posts on Open-Core Licensing:

• Open Core Licensing defined (AUGUST 29, 2008)
• New and Improved Open Core, with AGPL (FEBRUARY 2, 2009)
• Open Core: the New Standard in Commercial Models (MARCH 2, 2009)
• Variants on Open Core (March 25, 2009)

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

I was a panelist on the open core business model panel today at OSBC. Open core seems to be a hotly debated topic in the blogosphere today, mostly I think because some folks fear being "left out" or FUD around the core product's value, when it's not about that at all. The open core model is about a particular business model that an increasing number of commercial open source vendors have chosen for its ability to both scale a business while serving communities. There are other successful commercial open source business models too, but it depends upon goals for the customers, community, and vendors to select the "right one” for their needs.

When it comes down to it, it's all about value. If the open source core adds value to the community, the project will thrive. If the commercial license adds valuable features, the vendor will thrive as well.

The moderator of the session was Dave Rosenberg, COO and GM of the Americas of RiverMuse and fellow panelists were Aaron Fulkerson, CEO of MindTouch, and Ed Boyajian, CEO of EnterpriseDB.

It was fun to participate, and I am grateful to the OSBC conference organizers for the opportunity to join the debate.

There was an interesting point raised about the copyright ownership of the core code and its implications. In my original post last year, I defined open-core licensing as when the vendor owns the core copyright codes and offers a dual license, where the commercial license has additional premium features. However, that definition excludes vendors who do not own the open source core product; yet "open core" seems to be descriptive of that business model still. In anticipation of the topic, I Tweeted a proposed modification before the panel discussion, which would modify the definition to include two variants:

1) Vendor Controls (VC) core's copyrights
2) Community Controls (CC) core's copyrights. Of course the vendor is part of community but does not have enough copyright control to dictate license. However, as a vendor backs the project, they are likely to be able to dictate some large direction of the product's roadmap.

I would like to explore the benefits and challenges of both variants a bit more, from communities', customers', and vendors' perspectives:

1) Vendor Controls (VC) core's copyrights
There are a number of benefits and potential challenges:

a) Benefits to the community:
- A commercial entity ensures value in the core open source product, with paid staff to provide support and new features

b) Challenges to the community:
- Is there a challenge in participation to the degree you wish? My feeling is this is really a FUD point. Any community will be pleased to have a productive contributor.

c) Benefits to the customer:
- customers know the core uses an OSI-approved license (probably GPL or AGPL), and they have an option to purchase a commercial license to release themselves from the GPL obligations
- core roadmap has a commercial entity methodically financing and driving a roadmap -- and innovation -- of both the core and commercial features
- customer has "one throat to choke" around both the core and commercial features

d) Challenges to the customer:
- the customer needs to understand the vendor's strategy for how features are determined to be included in the open source core and which features are reserved for the commercial product. The customer should ask the vendor to post the policy publicly to be clear if the vendor has not done so already.

e) Benefits to the open core vendor:
- vendor can offer a commercial license to ISV customers who wish to embed the product without GPL restrictions
- vendor can choose to change the open source license (eg, GPL 2 to GPL 3) or offer a commercial license
- Lower indemnification risk of vendor due to knowledge of core code
- Enforce violation of copyright of core

f) Challenges for the open core vendor:
- see 1b above. What is the best way, in terms of features, to simultaneously serve the community and drive revenue. This requires keeping a good pulse on the community's wishes and requirements. Probably if put to a vote, the community will always request more features in the open source core. But as mentioned above, it's all about value for both the open source core and the commercial features. If there is solid value in the open source core, and the community continues to download and participate, there may not be a huge requirement to move additional features into the open core. Whatever the policy, the vendor should be clear about it.

2) Community Controls (CC) core's copyrights

There are a number of benefits and challenges:

a) Benefits to the community:
- A community, whether reality or not, feels that it is free of commercial, emphatic control

b) Challenges to the community:
- Does the community have enough support? If there is a commercial entity backing it, chances are yes. But does this put point 2a into question?

c) Benefits to the customer:
- if permissive license, no commercial license required to embed core in your ISV product
- core's roadmap MIGHT NOT be dictated by vendor or single person (may be bad too)

d) Challenges for the customer:
- if GPL, probably no easy way to get out of GPL requirements when embedding
- maybe no throat to choke or difficult to find or influence someone on core's roadmap

e) Benefits to the open core vendor:
- Probably there is a large community contributing to the core which lessens the R&D cost burden on the vendor.

f) Challenges for the open core vendor:
- vendor cannot change the core license, e.g. GPL to AGPL or commercial
- vendor is financing a core for which it likely does not retain control

All in all, it's about value, and both of the variants of the open core licensing model provide both to customers and communities alike.

========

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

=======

Check out my other posts on Open-Core Licensing:

• Open Core Licensing defined (AUG08)
• New and Improved Open Core, with AGPL (FEB09)
• Open Core: the New Standard in Commercial Models (MAR09)

Open-Core Licensing: The New Standard in Commercial Software Business Models

My four posts on Open-Core Licensing:

• Open Core Licensing defined (AUGUST 29, 2008)
• New and Improved Open Core, with AGPL (FEBRUARY 2, 2009)
• Open Core: the New Standard in Commercial Models (MARCH 2, 2009)
• Variants on Open Core (March 25, 2009)

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

I am sure you can imagine how surprised I am that my first blog post (on the Open-Core Licensing business model) is the blog that just keeps on giving.

I think most of us are completely sick of hearing and debating about it, but to quote Michael Corleone in the Godfather series, “Just when I thought I was out... they pull me back in..”

Back in August when I first posted about the Open-Core model, I was simply articulating what Jaspersoft and other of the more successful commercial open source vendors were doing. I invented nothing, just articulated it. I composed that blog out of frustration and wonderment as to how industry pundits seemed to ignore the fact that the emperor was wearing no clothes. Back then the conventional wisdom was, “Red Hat is the most successful open source software company, so success must follow their model.”  I think points were ignored about the total potential size of the installed market determining how far you can go on services revenues. I simply pointed out the fact that traditional support-oriented open source vendors like MySQL over time were adding commercial features, AND … there is nothing wrong with that.

Now there is more weighing in around Open-Core:
-     “whether the Open Core model is sustainable in the long-term (I'm thinking 5-10 years).“
-    “There isn't one single model for commercializing open source, and things will continue to evolve as the market expands. What worked in the past may not always apply in the future.” No going out on a limb there. 

This all leaves me scratching my head again. Doesn’t everyone realize that the genie is out of the bottle? (sorry, all these clichés keep popping to mind.) Commercial open source is here to stay, everyone agrees. But the commercial proprietary model has been the most successful commercial model the past 30 years... Is it too outrageous of a claim to recognize the following convergence of the two, which appears to be happening before our eyes:

Open-Core is the new emerging standard in commercial software business models.

Forget open-core being popular just in open source circles, I mean commercial software in general. I predict that in 5-10 years (just about the time its diminishing importance is being predicted by some), Open-Core will be the standard for most new software companies arriving on the scene. Given the AGPL, this does not of course preclude SaaS models. The traditional proprietary MISO giants (Microsoft, IBM, SAP, and Oracle) will be considered legacy. Unless they act fast. Amazingly, Microsoft is making great strides toward open source (though they are using more of an Open-Crust, those features on top of the core, than Open-Core; still there is talk out there about open sourcing Windows. Reminds me of when I thought they were dead when Netscape arrived, and wham, they flipped on a dime! (How many clichés will I actually use in this blog?) That company re-invents itself more than Madonna. IBM is a big, obvious advocate and promoter of Open Source. Besides its investment arm, I am not aware of SAP making any big open source moves within its own software family, aside from MaxDB (what ever happened to that?). And Oracle has some open source projects here and there (SleepyCat, InnoDB), but can anyone imagine them open sourcing the Oracle RDBMS? Not likely.

Yes, you will have niche products whose creators will believe their products and ingenuity is so unique that they simply can’t divulge any secret sauces (think Ab Initio an exotic black box ETL / data integration tool – by the way how many people do you know using it? One, if you are lucky. I will reserve comment on that for a  different blog). But I think those products will be in the minority and be considered quaint ("your product is COMPLETLEY proprietary? Hey this is 2015, not 1995!").

Does this Open-Core business model drive the software industry to become a commodity industry? Perhaps... scary, ay?  But commodity only in some respects, I would imagine. Innovation may be driven with core and crust features alike, and revenue can be driven primarily with the crust features in a very successful way. This is why I think open source despite some conventional (forgetful) wisdom, and even more so with the Open-Core model, is actually a wonderful model to drive adoption of innovative technologies. Open-Core is not only for commodity core technology. And this is why zAgile has selected* Open-Core as the business model to drive wide adoption of its own very innovative core technology (released into public beta on SourceForge 1 month ago). Remember, there were some very innovative technologies driven by open source, things like: the original Unix, Apache, Mozilla browser, and the world wide web, to name a few. So why can’t open source in general and the open-core business model in particular drive wide adoption of innovative technologies too? Over the next few years, far from fading and particularly aided by the dire economy, Open-Core will become the standard in commercial software.

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

* editor's note: as of April 6, 2011, zAgile has not implemented the Open Core Licensing business model

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

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

Check out my other posts on Open-Core Licensing:

• Open Core Licensing defined (AUG08)
• New and Improved Open Core, with AGPL (FEB09)
• Variants on Open Core (APR09)

New and Improved Open-Core Licensing – Now with Affero

My four posts on Open-Core Licensing:

• Open Core Licensing defined (AUGUST 29, 2008)
• New and Improved Open Core, with AGPL (FEBRUARY 2, 2009)
• Open Core: the New Standard in Commercial Models (MARCH 2, 2009)
• Variants on Open Core (March 25, 2009)

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

 

A valuable open source product, a vibrant community, and the right licensing strategy are three keys to the success of a commercial open source software company.  This post is a follow-up to my previous blog about the open-core licensing business model, and I address these points around the topic:
-    How do you balance features between the commercial and open source versions?
-    How do you build a successful community?
-    What about the Application Service Provider (ASP) loophole?

Some Background
Last August, I proposed the name “open-core licensing” for a specific commercial open source business model which appears to be an emerging standard and acceptable in premise by corporate buyers such as CTOs. In this business model, the core technology is licensed under an OSI approved license (typically GPL), and a commercial open source vendor that owns the intellectual property can also offer a commercial license that covers both that core technology as well as premium add-on features. In other words, the term “open-core licensing” was a proposed business model name for a specific type of dual licensing or twin licensing  (i.e., if you own or control all the copyrights, you can issue a commercial license with exactly the same bits as the GPL version; it’s dual or twin licensing, but it’s not open-core licensing). This specific business model name was picked up by Matt Aslett of The 451 Group and open source industry observers such as Dave Rosenberg and Savio Rodrigues as an apparently increasingly recognized way to scale a commercial open source business model. Perhaps it is becoming even more accepted now than the previously presumed superior business model of “services only.” While there are certainly vendors out there that do not own the core copyrights of the product but provide commercial extensions, there are some benefits to owning the core copyrights, and that will be covered in a separate blog.

Achieving Balance Between Open Source and Commercially Licensed Versions
It’s a great question and still being posed: “how do you achieve balance between open source and commercial versions?” I think the answer is not a generic, precisely defined method for all vendors but rather specific to each vendor. But the overarching theme to the answer is simply put: make sure the value of the open source edition is compelling enough for broad adoption of the open source product. So, if your open source product is not being widely adopted or not being adopted quickly enough, you probably need to include more of the commercial features in the open source version.  For example, keeping a pulse on your open source download rate and forums usage are probably both a good barometer of value in the open source version.

How Do You Build A Successful Community?
There are a lot of good overviews out there (Stormy Peters, Chris Brogan, Connie Bensen / Jeremiah Owyang, and John Lilly).  Matthias Stürmer provided a detailed analysis in 2005.  I think there are some other good discussions on the topic out there. Do you have further suggestions?

The ASP Loophole
Although GPL is not the choice license of developers for everything (e.g., many libraries), it is enjoys wide adoption, and it’s increasingly the license of choice amongst commercial open source software vendors. I propose that using the GNU Affero GPL v3 license as the specific type of GPL with the open-core licensing business model seems to be the next logical step on the path for commercial open source vendor business model evolution.

The problem with GPL v2 and v3, in the view of many commercial open source vendors, is that ASPs such as Google can profit quite heavily from GPL v2 and v3 open source efforts while not contributing back to those open source projects. Of course in a large enterprise, there is quite a grey area in the use of GPL, and a bank illustrates the case. A company like Citigroup may use GPL software internally, respecting the GPL license, but some of those systems which rely on GPL code may eventually be exposed to people outside of Citigroup, i.e., the ASP loophole.  Does this violate the GPL v2? While a company such as Google would probably say “no,” most commercial open source vendors say, “yes.”

While providing many refinements over GPL v2 (see table) and pleasing companies such as Google and even Red Hat, GPL v3 received a tepid response from some commercial open source vendors due to the omission of the Affero clause which addressed the ASP loophole.  Perhaps the most outspoken critic of GPL v3, Fabrizio Capbianco, CEO of Funambol, wrote:

The provision is not there. Gone. They dropped the ball. Actually, it has been made very clear that the ASP loophole is not a loophole anymore. It is perfectly fine to change GPLv3 software and offer it to the public as a service, without returning the changes to the community.

Since GPL v3’s release, more than 3,000 projects adopted it, and the ASP loophole was addressed with a new license called GNU Affero GPL v3 (AGPL). Noted open source legal authority Mark Radcliffe wrote, “The AGPL includes a provision requiring that companies providing services over a network make the source code available to users of the services (just as if the companies had distributed a copy of the software under the GPLv3) based on the well known "Affero" modification to the GPLv2.” 

But Savio Rodrigues ponders whether the Affero clause is really necessary when a large company like Facebook contributes back code, even when it is not required to do so under a permissive license. My response in the comment section to his blog is basically, “isn’t that simply wishful thinking that all large companies will behave the same?”

I believe a comment by jrpenning on Matt Asay’s blog, points towards the right solution: 

I think we're closing in on an optimal model. The AGPL tries to correct something that needed correction, but seems to be a bit too far on the other side. Dual licensing with an AGPL base would be a move back toward the center, where hopefully the optimum lies.

Therefore, a “best of all worlds” solution for commercial open source vendors is to use the open-core licensing business model with GNU Affero v3 as the open source license for the core technology.
When the AGPL license is combined with open-core licensing, software vendors that own their intellectual property are able to have their cake and eat it too.  And commercial open source vendors, customers, and the open source community all have solid choices and preserve freedom.

While licensors should certainly be careful about license compatibility, I think AGPL v3 is the right move instead of GPL v3. Readers may presume that a product licensed under AGPL must be designed for SaaS. I propose that products for GPL consideration whose use case are 100% on-premise today but could eventually be used in a networked/web situation should be licensed under AGPL immediately in anticipation of the networked situations so that the licensor is protected. Therefore, up until the product is exposed publicly, GPL v3 conditions apply, and the Affero (ASP clause) is not pertinent. If our recent experience with web, internet, and other new technologies has taught us anything, it's that we cannot predict how software will be used.

That’s how I see things, but I am very curious to know of others’ opinions. In particular, I am curious to know about corporate adoption of GPL v3 and acceptance or criticisms of AGPL v3 – both at the executive and developer level. If corporate stakeholders object to AGPL v3, I would like to understand why.  My guess is, as expressed by a variety of people in this 2007 blog, they generally don’t care about licensing. They simply want value and the right products for the right job, and they are willing to pay for the value entailed when required.  And even if it’s really the developers, rather than executives, that are actually making the choices of open source products and their corresponding licenses in the bottom-up adoption, an open-core licensing model allows acquisition of a commercial license if that is desired.

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

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

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

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

Check out my other posts on Open-Core Licensing:

• Open Core Licensing defined (AUG08)
• Open Core: the New Standard in Commercial Models (MAR09)
• Variants on Open Core (APR09)

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

My four posts on Open-Core Licensing:

• Open Core Licensing defined (AUGUST 29, 2008)
• New and Improved Open Core, with AGPL (FEBRUARY 2, 2009)
• Open Core: the New Standard in Commercial Models (MARCH 2, 2009)
• Variants on Open Core (March 25, 2009)

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

 

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 (FEB09)
• Open Core: the New Standard in Commercial Models (MAR09)
• Variants on Open Core: (APR09)