October 20th, 2010 — Business strategies, Software
This is an updated version of a post that was originally published in July 2009. It has been updated in response to ongoing confusion about open core licensing.
There has been a significant amount of interest in the open core licensing strategy since Andrew Lampitt articulated it and its benefits for combining open source and closed source licensing.
There remains considerable confusion about exactly what the open core licensing strategy is, however, which is strange since the term arrived fully packaged with a specific definition, courtesy of Andrew. Recently I have begun to wonder whether many of the people that use the term open core regularly have even read Andrew’s post.
I feel somewhat responsible for this given that our Open Source is Not a Business Model report was partly responsible for the increased use of the term open core, and since I remembered that it was this post about commercial open source strategies that prompted Andrew to define open core in the first place.
Additionally, since business models related to open source are evolving constantly, I thought it was worth revisiting the definition of open core and putting it in some context.
What is open core?
According to Andrew’s original post it is a licensing strategy whereby a vendor combines proprietary code with open source code, where “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”.
At first Andrew was very specific about the use of the GPL license and a development model dominated by a single vendor. However, it quickly became clear that a company like EnterpriseDB, which provides proprietary extensions on top of the community-developed, BSD-licensed PostgreSQL database, also fits the general model.
Therefore, Andrew clarified that there were Vendor Controlled (VC) and Community Controlled (CC) variants on open core.
Incidentally, Andrew did not create the open core strategy. As he himself admitted, he “invented nothing, just articulated it”. Credit goes to Barry Klawans and Paul Doscher (Jaspersoft co-founders), as Andrew noted.
In fact our research indicates that the formation of companies using the open core licensing strategy had already peaked by the time the term was coined – but more on that another day.
What isn’t open core
Sometimes it is easier to define what something is by explaining what it isn’t. Open core is a commercial open source strategy, but just as “all of Alma Cogan is dead, but only some of the class of dead people are Alma Cogan”, not all commercial open source strategies are open core (and more specifically, given recent statements, not all strategies that involve copyright agreements are open core – more on that another day as well).
So, to clear up some apparent confusion:
- Red Hat’s strategy is not open core
Red Hat reserves support and features for paying customers, but it does not do so using closed source licensing (a prerequisite of open core). Instead Red Hat gives away the source code but withholds the compiled, binary version for paying customers.
(N.B. Beware companies claiming to be following “The Red Hat model” as they invariably aren’t – most often I find they mean that they use a subscription revenue model. Very few companies have copied Red Hat’s model for a variety of reasons – a subject I’ll leave for another post.)
- Dual licensing is not open core
In fact, as Andrew Lampitt explained in his definition, open core is a variant of dual licensing (or proprietary relicesing, as some like to call it, or indeed “selling exceptions”). The important thing to note is that in the dual license strategy a single code base is available under an open source or closed license, while with open core the closed source licensed code is a superset of the open source code. Both result in closed source software, but only in the open core strategy is the closed source version functionally different from the open source version.
- The MySQL strategy is not open core (yet)
One of the reasons for the confusion is that MySQL originally started out with a dual license model but changed over time to the subscription revenue model, and flirted with open core. At this point the strategy for MySQL remains dual licensing. It remains to be seen whether the MySQL Server code for Enterprise Edition 5.5 will be different from Community Edition with the inclusion of MySQL Enterprise Backup (which would make it open core) or if the new capabilities will be delivered as a subscription service.
- Subscription strategies are not open core
Although they are a step in that direction. The subscription model provides vendors with a mechanism to distribute value-added features to paying customers. Until now the additional capabilities in MySQL Enterprise (such as Enterprise Monitor) have been delivered as a service via the MySQL Enterprise subscription. Although the code for Enterprise Monitor has not been made available, we would see this strategy as distinct from open core since open core results in a product with a different code base, where as the MySQL Server code in Enterprise and Community is the same. To differentiate from regular support subscriptions I have used the term value-added subscription to refer to this type of subscription. Other examples include Canonical’s Ubuntu Advantage and Nuxeo’s Connect. I would also put Red Hat Network and JBoss Operations Network in this category, although the source code for those value-added services was originally closed, it has now been made available as open source (as previously discussed).
Open foundation is not open core
Vendors such as IBM, Cisco, Oracle and SAP (in fact just about every software vendor) include open source code within larger closed source software packages and hardware products. There is a fine line between the two, but as I previously explained while open core involves offering proprietary extensions targeted at a segment of the open source project user base, open foundation involves using open source software to create entirely new products, targeted at a different user base.
Microsoft’s open source strategy is not open core
Microsoft is undoubtedly making use of more open source and encouraging open source development on its platforms, but its strategy is by definition not open core since it is extremely unlikely the core will ever be open source. In fact, as previously discussed, Microsoft’s strategy turns the open core strategy on its head by encouraging open source development around a commercial core, and has been described by Microsoft as open edge, and by Andrew Lampitt (more amusingly) as open crust. We have adopted the term open edge to describe this strategy and have seen it adopted by a small number of players beyond Microsoft.
June 21st, 2010 — Business strategies
The latest 451 Open source strategy Spotlight was published last week with a focus on private cloud comouting software provider Intalio.
It is fascinating to observe how Intalio has evolved from being an open source specialist, operating a form of the dual licensing strategy, towards what we have referred to as an Open Inside model – building proprietary software products around open source software projects.
This is an evolution that The 451 Group had predicted we would see some open source specialists follow as they focused more on the complementary proprietary products and extensions, rather than the core open source projects.
What I found when I spoke to Intalio’s CEO Ismael Ghalimi was even more fascinating that I had appreciated, as it turns out that the company is operatiing a combination of Open Inside and open source specialist business strategies.
Previously best known as an open source business process management specialist, Intalio has made a series of acquisitions and altered its strategy to focus on offering a subscription-based (but not open source) private cloud software stack.
However, open source remains central to its strategy – not least the company’s original Business Process Management System (BPMS) software and Jetty, the lightweight Java server which was the focus of Webtide, which was acquired in August 2009.
The BPMS and Jetty businesses continue to operate as standalone entities and are required by the company to be profitable in their own right and employees of the BPMS and Jetty businesses are dedicated 100% to the projects unless they are contracted by Intalio’s Cloud group to contribute to Cloud products.
In terms of direct monetization of open source, Intalio offers training, consulting, support and custom integration for Jetty, as well as the associated CometD Web event routing bus, while operating a variation of the dual licensing model for BPMS.
Open source is integral to Intalio’s strategy beyond the company’s own open source assets, however. It would not have been economically possible for Intalio to assemble the portfolio of software packages that it has without being able to build on open source software, and the PaaS platform in particular (Intalio also offers SaaS and IaaS platforms) is based on the company’s ability to integrate multiple open source software packages.
The company’s various PaaS Application Engines are based on numerous open source projects including Jetty; Apache ODE; Drools Flow; JBoss Drools; JasperReports; Apache Camel; Nuxeo DM; Liferay; Funambol; and the Central Authentication Service project. Projects based on the Mondrian OLAP server; the Apache Cassandra distributed database; and the Gluster file system, are also in the works.
The Open source strategy Spotlight also includes details on how those various open source projects are and will be used by Intalio, as well as the company’s acquisition strategy, a look at how the dual licensing strategy for BPMS is shifting towards 100% open source, not to mention an overview of the Intalio Cloud stack.
March 25th, 2010 — Business strategies, Conferences, Software
UPDATE An updated version of the business strategy framework can be found here. UPDATE
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.
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.
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.
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.
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.