 | I joined the number of those who have a public opinion on the open core debate. Roberto Galoppini has graciously accepted to host a post on this topic in his Commercial Open Source Software blog. Please read it directly from there: Open to the core - The pragmatic freedom Enjoy! |
There’s lots of buzz lately about the so-called “open-core” business model of Marten Mickos’s new employer. But this is nothing new. Depending on how you define it, InnoDB is “open-core,” and has been for a long time. The InnoDB Hot Backup (ibbackup) tool was always closed-source. Did anyone ever cry foul and claim that this made InnoDB itself not open-source, or accuse Innobase / Oracle of masquerading as open-source? I don’t recall that happening, although sometimes people got suspicious about the interplay between the backup tool and the storage engine. Generally, though, the people I know who use InnoDB Hot Backup have no gripes about paying for it.
What is the difference between open-source with closed-source accessories, and crippleware? I think it depends on how people define the core functionality of software. Some might say that backup is core functionality for a database; and others would point to mysqldump and say that InnoDB isn’t crippleware as long as there is some alternative.
I think InnoDB is an interesting case that illustrates what can happen when commercial and GPL play together. Part of that story is the appearance of XtraBackup, an open-source competitor to InnoDB Hot Backup. Everyone’s subject to the rules of the game, unless they restrict the “core,” which would make it non-open-source to begin with.
Related posts:
If the recent debate about open core licensing has proven one thing, it is that the issue of combining proprietary and open source code continues to be a controversial one.
It ought to be simple: either the software meets the Open Source Definition or it does not. But it is not always easy to tell what license is being used, and in the case of software being delivered as a service, does it matter anyway?
The ability to deliver software as a hosted service enables some companies that are claimed to be 100% open source to offer customers software for which the source code is not available. Coincidentally, James Dixon has this week highlighted one example in the form of Nuxeo Studio, a configuration and customization environment for the Nuxeo ECM offerings, which is delivered as a hosted service to Nuxeo’s Connect – Developer subscribers.
The nature of Studio’s license came up in a conversation I had recently with Nuxeo CMO Cheryl McKinnon, and I had been meaning to write a post on the subject of hosted subscription services ever since.
Nuxeo Studio is the latest in a line of value-added subscription services that blur the lines between open and closed. It started, arguably, back in 2001 with Red Hat Network, a hosted monitoring and management service. The stand alone Red Hat Network Satellite followed two years later but it wasn’t until June 2008 that the code officially became open source, as project Spacewalk.
Similarly, JBoss Operations Network was first introduced as JBoss Network, part of the JBoss subscription, in March 2005. The code for that was made available in the form of the Jopr project in 2008.
Meanwhile MySQL introduced MySQL Network Monitoring and Advisory Services as part of MySQL Enterprise in October 2006 as it continued its shift towards subscription revenue (and away from its traditional dual licensing approach).
More recent examples include Nuxeo Studio and Acquia Network’s remote site management services.
In his post James Dixon argues that the delivery of a service like Nuxeo Studio is effectively the same as the open core licensing model, in that it is the delivery of proprietary extensions to an open source core. Florent Guillaume, director of R&D at Nuxeo, and Eric Barroca, Nuxeo CEO, have responded in the comments to that post and Eric’s original to argue that it is not.
My own feeling is that Nuxeo’s approach is not open core, since the original definition of open core concerned proprietary products. However, the existence of Nuxeo Studio means that Nuxeo is clearly not 100% open source.
For that reason, I have come to believe that we need to add a new revenue trigger category to our open source business strategy model, that makes a clear distinction between support subscriptions for 100% open source code, and value-add subscriptions that offer additional hosted services.
It is also a reminder of the importance of transparency. Open core vendors are regularly attacked for misleading potential customers with the promise of open source while delivering traditional licensing. Our recent transparency test indicated that for the most part open core vendors are clear about what features are in which version, and with which license.
I spent some time the other day investigating the web sites of various OSS-related vendors and unfortunately the same cannot be said of all vendors (whether they are open core or “pure” open source).
Too often phrases like “open source subscription license”, “commercial open source license” and “value-added component” are thrown around without any explanation of what exactly is meant, and the so-called open source purists are not immune to glossing over the details.
Simon Crosby recently commented that everybody making money with open source actually has a proprietary angle. I don’t think that is 100% true, but it is getting harder and harder to identify the open source purists.
Last week I presented “From support services to software services – the evolution of open source business strategies” at the OSBC event in San Francisco.
The presentation was effectively a work in progress update on our research into the various strategies employed by technology vendors to generate revenue from open source software.
It included a partial explanation of my theory that those strategies do not exist in isolation, but are steps on an evolutionary process, and also introduced our model for visualizing the core elements of an open source-related business strategy.
I provided a number of examples of how the model could be used to compare the strategies of various open source businesses. Here, for example, is the visualization of MySQL’s strategy.
I was pleased with the response to the presentation, not least the number of people who asked us to send them the slide so they could fill it in for their company and send it back to us.
This is definitely something we would like to do in the future but before we do I would like to ensure we have dealt with any problems related to the model. For now I would be more interested in hearing from companies that feel their strategy is NOT covered by the model.
As Jack Repenning has pointed out, the model does not offer the granularity to express some of the nuances of the various “open complement “ strategies where open source code is not monetized directly but via complementary products (and in my own presentation I had to go beyond the model to discuss “open inside” – building proprietary products on open foundations, and “open edge” – using open source to drive innovation on top of a closed platform).
My initial feeling is that there will always be a level of detail that cannot be expressed in a simplified model such as this, although if I can build them in I will.
The development model category also needs some tinkering, not least to cover “gated community” approaches.
Additionally, of course, the model is not great when it comes to multi-product companies (although multiple models can be used to explain a larger strategy).
So anyway, if you think your company does not fit our model, do please tell us how. To help you understand how the model works, here’s a quick user guide and glossary of terms.
Revenue triggers:
These are the things that paying customers actually pay money for (apart from advertising which is an indirect relationship). They should be pretty self-explanatory. When we refer to “support services” we mean support, training, consulting, implementation services etc. “Software services” refers to SaaS and cloud delivery. Vendors can have multiple revenue triggers for a single product.
Software license:
For the purposes of this exercise we are interested in whether the company has a preference for permissive or reciprocal licensing for the underlying open source project, or uses both.
End user licensing:
What licensing strategy is applied to the product that customers pay for (as opposed to the project that it is based on)? It could be the same open source license (single open source) or a combination of open source licenses (assembled open source). It could be that the same code is available using open source and commercial licenses (dual licensing) or that commercial extensions are available (open core). Alternatively, a vendor may not monetize the open source project itself, but offer complementary software or hardware products (open complement), or may turn the open source code into a fully proprietary product (closed). Pick one.
Development model:
This requires a two-part response. Is the open source code developed in public, in private, or a combination of the two (public/private)? Pick one.
Is the development effort dominated my employees of a vendor, or the result of true community collaboration, or an aggregate of multiple projects? Pick one.
Copyright:
Who owns the copyright for the open source code? Is it the vendor in question, a foundation, a distributed collection of companies/individuals, or another company (withheld)? Normally this would be a matter of picking one of the four options, although if a portion of the copyright is withheld, that could be used along with one of the other three.
Do your worst.
Jay has already provided a good overview of the debate related to the apparent decline in the usage of the GPLv2. I don’t intend to cover the same ground, but I did want to quickly respond to a statement made by Matt Asay in his assessment of the reasons for and implications of reduced GPLv2 usage.
He wrote:
“as Open Core becomes the default business model for ‘pure-play’ open-source companies, we will see more software licensed under the Apache license”
I don’t doubt that we will see more software licensed under the Apache license, and also more vendors making use of permissively-licensed code, but I don’t see a correlation with the Open-Core model.
In our report, “Open Source is Not a Business Model“, report we found that 23.7% of the 114 vendors we covered were using Open-Core as a vendor licensing strategy. Looking at the stats, over 70% of Open-Core strategy users also used a variant of the GPL or LGPL.
The main reason for the correlation of the L/GPL and Open-Core is, as Matt notes, that “the GPL makes sense in a world where vendors hope to exercise control over their communities”. Carlo Daffara agrees: “the GPL is not a barrier in adopting this new style of open core model, and certainly creates a barrier for potential freeriding by competitors”.
Carlo cites as an example the use of the GPL by the usually Apache-focused SpringSource for its SpringSource dm Server as a means of restricting the commercial opportunities for potential rivals, something that we covered here.
As Matt explains, however, “if the desire is to foster unfettered growth, Apache licensing offers a better path”. Savio Rodrigues offers an example of a usually L/GPL-focused company - Red Hat/JBoss - choosing the Apache License for its new HornetQ messaging software because “the project team felt that the Apache license would ensure that the project’s code could be more easily included into products from the ecosystem.”
1-1 then. But this isn’t about point scoring. What the examples demonstrate is that vendors choose licenses for individual projects/products based on pragmatic business reasons rather than dogmatic commitment to licensing philosophy, and that - as we previously suggested - there is actually some benefit in the proliferation of different licenses.
Of course it is also important to remember that many vendors don’t have the luxury or choosing a license for the project they attempt to commercialize. Mike Olson notes that adoption has been a factor related to the Apache licensed Hadoop project - but what came first commercialization or adoption?
I believe we are seeing increased adoption of permissively-licensed open source software by both new open source specialists, such as Mike’s Cloudera, and also proprietary vendors such as Oracle, SAP and - as recently discussed - Day Software.
In these cases, the commercial vendor doesn’t choose the Apache license for software to encourage widespread adoption, it is encouraged to choose Apache-licensed software because of widespread adoption (not to mention the low cost and high quality advantages of being part of a true developer *community*).
That has more to do with the patron model, as discussed by Day Software’s chief marketing officer, Kevin Cochrane, than it does Open-Core.
Additionally, as Carlo notes, it is a product of the shift towards what he calls “consortia-managed projects”. Or as I previously stated: “if Open-Core was a significant revenue strategy of open source 3.0 (vendor-dominated open source projects such as MySQL, JasperSoft), then Embedded [as I was referring to the patron model at the time] is one of the commercial open source strategies of open source 4.0 (vendor-dominated open source communities such as Eclipse, Symbian).”
So while we expect Open-Core to remain a significant business model for ‘pure-play’ open-source companies, and we expect to see more software licensed under the Apache license, we don’t see the two as being directly related.
Anyway, this was supposed to be a quick post. That’s enough for now.