Topics for this podcast:
*Cloud M&A potential around OpenStack
*Oracle’s commercial extensions for MySQL
*Puppet Labs rolls out Enterprise 2.0, hosts PuppetConf
*Basho bolsters Riak distributed data store in NoSQL race
*Our latest special CAOS report, ‘The Changing Linux Landscape’
iTunes or direct download (25:59, 4.4MB)
Oracle last week quietelyannounced the addition of new extended capabilities in MySQL Enterprise Edition, confirming the adoption of the open core licensing strategy, as we reported last November.
The news was both welcomed and derided. Rather than re-hashing previous arguments about open core licensing, what interests me more about the move is how it illustrates the different strategies adopted by Sun and Oracle for driving revenue from MySQL, and how a single project can be used to describe most of the major strategies from generating revenue from open source software.
Like most open source-related software vendors, MySQL started out life offering support, training and consulting around the open source database. The company also saw success in offering a closed source variant of the database for embedding in closed source systems, and it was this dual licensing strategy that drove much of the company’s early revenue. That began to change with the arrival of MySQL Enterprise (initially ‘MySQL Network’ – a subscription offering that delivered monitoring and (later) backup capabilities to paying customers only. While some people see this as an example of the open core licensing strategy, as we have previously explained, it is not. While open core is an extension of the dual licensing strategy with additional extensions, MySQL AB’s MySQL Enterprise, as the graphic above illustrates, actually paired the extensions with the open source MySQL Community – a subtle difference from the MySQL Enterprise licensing strategy adopted by Oracle (more of which later).
MySQL flirted with the open core licensing model in early 2008 with plans to introduce new features into Enterprise Edition that would not be available under an open source license. Those plans were ultimately reversed at the behest of new owner Sun Microsystems. To understand why Sun did this one must consider the company’s wider strategy for open source at the time. While a software freedom philosophy played a part, Jonathan Schwartz’s map of open source downloads, each representing ‘a potential customer that cost Sun nothing to acquire’, explains how Sun was less interested in driving direct revenue from MySQL (and other open source software) as it was in helping open source users to become customers for Sun’s commodity hardware and other products and services.
Sun never got the chance to prove whether this model would have worked (I’m being polite), but in any case contrast Sun’s approach with Oracle’s strategy for open source. While the majority of Oracle’s revenue clearly comes from other products, it is not looking to drive revenue for those products via open source downloads. Witness Larry Ellison’s recent proclamation that he doesn’t care if Oracle x86 server business (typically used to run MySQL) goes to zero. Instead (for better or worse) the company is focused on driving revenue directly from each individual product, whether that is a high margin server, or closed or open source software. That has resulted in an increased investment in embedded opportunities for MySQL, as well as traditional software license agreements. While customers might choose to use MySQL Community and purchase additional support subscriptions, as of November 2010 Oracle prefers that Standard Edition and Enterprise Edition customers enter into a commercial license agreement with the company. That was a strategy that was in place in advance of last week’s addition of high availability, scalability and security features, but one that clearly looks set to continue.
Whether this is a good or a bad thing depends on your perspective. Monty Widenius does a good job of outlining the down sides to an open core licensing strategy, while Giuseppe Maxia focuses on the positives. Certainly Oracle will have to be mindful to balance the control and community aspects, but as we have previously covered (451 Group clients) there are a number of new capabilities in development for the core MySQL database itself.
Topics for this podcast:
*Our latest CAOS Special Report – Control and Community
*Red Hat releases RHEL 6
*Symbian and Oracle highlight community challenges
*The latest on government adoption of OSS from GOSCON
*Open core issue continues, now with Linux and evil twins
iTunes or direct download (31:02, 8.5MB)
Or, how we evaluate a company’s open source-related business strategy.
Godwin’s law states: “As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches”.
An online discussion about open source-related business strategies is no exception. However, long before the Nazi comparison it is inevitable that someone will ask “is MySQL open core?”.
I updated our 2009 post “what is open core, and what isn’t” recently, and received some criticism of my statement that the MySQL strategy was not open core.
Since we have recently published a report including the results of our analysis of the open source-related business strategies of 300 vendors and subsidiaries it seems appropriate that we use this opportunity to explain how we evaluate a company’s open source-related business strategy, and specifically how our analysis led us to conclude at the time of our analysis (August/September) that the open core licensing strategy did not apply to MySQL.
Given the recent changes to MySQL pricing and licensing we have also revisited our analysis, see below.
Looking at MySQL Enterprise it is easy to see why so many people conclude that the product licensing strategy being applied to MySQL is open core, since MySQL Enterprise contains extensions for which source code is not available that are not available with MySQL Community.
However, it is important to remember that products are not open core – and companies are not open core – but that open core is a product licensing strategy applied by companies to products. Therefore the question “is MySQL open core?” is inappropriate. A more appropriate question would be, “is the product licensing being used with MySQL open core?”
It is also worth noting that a product licensing strategy is just one of five elements that we at The 451 Group use to evaluate an open source-related business strategy.
The five elements we consider are: the software license for the open source software; the development model for the open source software; copyright ownership for the open source software code; the product licensing strategy; and the revenue generator. Specifically, with regards to MySQL, our evaluation went as follows:
Software license/development model/copyright ownership:
This was a relatively straightforward process for the MySQL business. The MySQL Database software is available under the GNU GPLv2, a strong copyleft license, and although the code is available at Launchpad, clearly the software continues to be developed in the cathedral model by a core group of developers, mostly employees of a vendor: Oracle. The same vendor also owns the copyright.
Product licensing strategy:
This is where things started to get a little bit difficult. Historically MySQL AB used the dual licensing strategy, making a version of MySQL Server available under a closed source license (aka selling exceptions) for enterprises. That strategy remains in use today to enable the use of MySQL embedded in closed source software. However, the version of MySQL Server in MySQL Enterprise was not closed source, and was the same GNU GPL version as MySQL Community. This provides a good example of why it is important to assess the licensing strategy, rather than the product: the open core licensing strategy uses dual licensing and adds closed source extensions to create a closed source version that is a superset of open source software (or from another perspective, an open source version that is a subset of closed source software). Since this description did not apply to MySQL Enterprise, which saw the open source MySQL Server delivered along with closed source extensions, we concluded that Oracle did not use an open core licensing strategy with regards to MySQL.
Revenue generator
The description of MySQL Enterprise, used above (open source software with additionally capabilities delivered via subscription) is exactly what we consider a value-added subscription revenue generator. There are often many ways in which a vendor generates revenue from open source software. MySQL is just such a case: Oracle generates revenue from closed source licenses embedded in closed source software, but the largest generator is the MySQL Enterprise value-added subscription.
Conclusion:
The MySQL strategy includes a strong copyleft software license, vendor-developed software using the cathedral model, and vendor-owned copyright. That much was easy. It was also easy to identify the dominant revenue generator, which was value-added subscription. That left the product licensing strategy, for which the choices were single open source (in MySQL Enterprise) and dual licensing (for embedded usage). To select single open source would be inaccurate since we could not ignore the fact that the MySQL business uses a dual licensing strategy.
MySQL Reconsidered:
In the light of the recent licensing and pricing changes for MySQL we took the opportunity to talk to Oracle about the licensing of MySQL. What we discovered was that whereas the MySQL Database previously accompanied by the MySQL Enterprise subscription was licensed using the GNU GPL, Oracle now prefers that Standard Edition and Enterprise Edition customers enter into a commercial license agreement with the company (although they will apparently be able to negotiate subscription usage with MySQL Community). This is a licensing agreement that does not impact the functionality or code of the MySQL Database itself, although clearly there continues to be additional functionality delivered with the MySQL Standard and Enterprise subscriptions, such as MySQL Enterprise Monitor and MySQL Enterprise Backup.
This changes our perspective of the MySQL-related strategy on two levels, Firstly, with regard to the revenue generator, we can now conclude that going forward the biggest revenue generator for Oracle from MySQL will be closed source licenses. While this closed source software will still be delivered via a subscription agreement, our support subscription and value-added subscription categories are reserved for products that use an open source license. It also changes our perspective on the product licensing strategy. Specifically in that our description of open core used above, (dual licensing + closed source extensions to create a closed source version that is a superset of open source software) does now apply to MySQL Standard and MySQL Enterprise.
Or, how we evaluate a company’s open source-related business strategy.
Godwin’s law states: “As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches”.
An online discussion about open source-related business strategies is no exception. However, long before the Nazi comparison it is inevitable that someone will ask “is MySQL open core?”.
I updated our 2009 post “what is open core, and what isn’t” recently, and received some criticism of my statement that the MySQL strategy was not open core.
Since we have recently published a report including the results of our analysis of the open source-related business strategies of 300 vendors and subsidiaries it seems appropriate that we use this opportunity to explain how we evaluate a company’s open source-related business strategy, and specifically how our analysis led us to conclude at the time of our analysis (August/September) that the open core licensing strategy did not apply to MySQL.
Given the recent changes to MySQL pricing and licensing we have also revisited our analysis, see below.
Looking at MySQL Enterprise it is easy to see why so many people conclude that the product licensing strategy being applied to MySQL is open core, since MySQL Enterprise contains extensions for which source code is not available that are not available with MySQL Community.
However, it is important to remember that products are not open core – and companies are not open core – but that open core is a product licensing strategy applied by companies to products. Therefore the question “is MySQL open core?” is inappropriate. A more appropriate question would be, “is the product licensing being used with MySQL open core?”
It is also worth noting that a product licensing strategy is just one of five elements that we at The 451 Group use to evaluate an open source-related business strategy.
The five elements we consider are: the software license for the open source software; the development model for the open source software; copyright ownership for the open source software code; the product licensing strategy; and the revenue generator. Specifically, with regards to MySQL, our evaluation went as follows:
Software license/development model/copyright ownership:
This was a relatively straightforward process for the MySQL business. The MySQL Database software is available under the GNU GPLv2, a strong copyleft license, and although the code is available at Launchpad, clearly the software continues to be developed in the cathedral model by a core group of developers, mostly employees of a vendor: Oracle. The same vendor also owns the copyright.
Product licensing strategy:
This is where things started to get a little bit difficult. Historically MySQL AB used the dual licensing strategy, making a version of MySQL Server available under a closed source license (aka selling exceptions) for enterprises. That strategy remains in use today to enable the use of MySQL embedded in closed source software. However, the version of MySQL Server in MySQL Enterprise was not closed source, and was the same GNU GPL version as MySQL Community. This provides a good example of why it is important to assess the licensing strategy, rather than the product: the open core licensing strategy uses dual licensing and adds closed source extensions to create a closed source version that is a superset of open source software (or from another perspective, an open source version that is a subset of closed source software). Since this description did not apply to MySQL Enterprise, which saw the open source MySQL Server delivered along with closed source extensions, we concluded that Oracle did not use an open core licensing strategy with regards to MySQL.
Revenue generator
The description of MySQL Enterprise, used above (open source software with additionally capabilities delivered via subscription) is exactly what we consider a value-added subscription revenue generator. There are often many ways in which a vendor generates revenue from open source software. MySQL is just such a case: Oracle generates revenue from closed source licenses embedded in closed source software, but the largest generator is the MySQL Enterprise value-added subscription.
Conclusion:
The MySQL strategy includes a strong copyleft software license, vendor-developed software using the cathedral model, and vendor-owned copyright. That much was easy. It was also easy to identify the dominant revenue generator, which was value-added subscription. That left the product licensing strategy, for which the choices were single open source (in MySQL Enterprise) and dual licensing (for embedded usage). To select single open source would be inaccurate since we could not ignore the fact that the MySQL business uses a dual licensing strategy.
MySQL Reconsidered:
In the light of the recent licensing and pricing changes for MySQL we took the opportunity to talk to Oracle about the licensing of MySQL. What we discovered was that whereas the MySQL Database previously accompanied by the MySQL Enterprise subscription was licensed using the GNU GPL, Oracle now prefers that Standard Edition and Enterprise Edition customers enter into a commercial license agreement with the company (although they will apparently be able to negotiate subscription usage with MySQL Community). This is a licensing agreement that does not impact the functionality or code of the MySQL Database itself, although clearly there continues to be additional functionality delivered with the MySQL Standard and Enterprise subscriptions, such as MySQL Enterprise Monitor and MySQL Enterprise Backup.
This changes our perspective of the MySQL-related strategy on two levels, Firstly, with regard to the revenue generator, we can now conclude that going forward the biggest revenue generator for Oracle from MySQL will be closed source licenses. While this closed source software will still be delivered via a subscription agreement, our support subscription and value-added subscription categories are reserved for products that use an open source license. It also changes our perspective on the product licensing strategy. Specifically in that our description of open core used above, (dual licensing + closed source extensions to create a closed source version that is a superset of open source software) does now apply to MySQL Standard and MySQL Enterprise.
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 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.)
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.
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.
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).
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 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.
Bradley M Kuhn published an interest blog post at the weekend explaining why he believes Canonical is about to go down the open core licensing route and heavily criticising the company for doing so.
My take on the post is that it is the worst kind of Daily Mail-esque fear mongering and innuendo. Not only does Bradley lack any evidence for his claim, the evidence he presents completely undermines his argument and distracts attention from what could be a very important point about copyright assignment.
The premise? Mark Shuttleworth has admitted that he plans to follow the open core licensing strategy with Canonical.
The evidence? Mark praises the strategy Trolltech took of selling proprietary licenses.
The problem? Trolltech did not follow the open core licensing strategy. Neither did MySQL, which Bradley suggests inspired Trollech’s strategy.
Both MySQL and Trolltech utilised a dual licensing strategy, which means that the same code base is available under on open source license or a closed source license (also known as “selling exceptions”. This is not open core licensing, although it is related since open core sees vendors dual licensing and offering extensions only available in the closed license version.
A significant difference between dual licensing and open core is that Richard Stallman has explained why, in his opinion, it is okay to sell exceptions to GPL code via a dual licensing strategy. In fact one of the examples he uses is… Trolltech.
So Trolltech is not open core. Or is it? Perhaps it depends on how you define it. Bradley has claimed, at least twice, that there is no agreed definition of open core.
If that were true you could forgive his confusion, but it clearly not. In fact the term open core was delivered fully packaged with a specific definition, courtesy of Andrew Lampitt. As I previously noted, you have to wonder whether many of the people that use the term open core regularly have even read Andrew’s post.
Since Mark’s comments about Trolltech are the only evidence put forward that Canonical is going open core I’m not going to debate that any further.
It is worth considering a couple of other claims Bradley makes, however – such as the idea that Nokia abandoned Trolltech’s business model. It is pretty clear that a company like Nokia has very different motivations and business drivers compared to a company like Trolltech. A strategy that works for Nokia does not mean the strategy that worked for Trolltech was wrong.
However, it is worth noting that in fact Qt business continues to operate the dual licensing strategy. What has happened is that the company has added a new LGPL option and launched a public repository for the software and abandoned the previous requirement for copyright assignment.
This is not a change in business strategy – this is a change in the licensing, development and copyright strategies. Just because Nokia is in a position to open up the development project to encourage more collaborative development (which I agree is a beneficial arrangement for everyone) does not mean that Trolltech’s closed development strategy wasn’t successful.
Undoubtedly Trolltech’s insistence on copyright assignment limited its outside contributions, but copyright assignment does not equal open core, despite Bradley’s insistence that there is “no other plausible & logical conclusion”.
We saw a similar reaction last month in reaction to Diaspora’s copyright assignment policy. However, open core is by no means the only possibility. Dual licensing is another. And as we have seen that comes with RMS’s own seal of approval… except where it results in a version of the code that is only available as closed source (such as open core).
Richard Stallman’s advice on that issue is to “insist that the contribution agreement require that software versions including your contributions be available to the public under a free software license. This will allow the developer to sell exceptions, but prevent it from using your contributions in software that is only available under a proprietary license.”
This is good advice for any developer concerned about open core, and this is the message that gets lost amid Bradley’s anti-open core agenda.
It is absolutely fair to ask why Canonical demands copyright assignment, but to insists that the only reason that they do so is because they are going open core, especially on such flimsy and misleading evidence, is scaremongering and distracts attention from the real issue – which is copyright assignment.
It should be noted, incidentally, that Bradley and Mark have some previous when it comes to copyright assignment, which was also, I believe, caused by confusion rather than malice.
See also this poston the difference between copyright assignment and participation agreements.
One of the issues that has arisen from the ongoing debate about the open core licensing strategy is the continuing confusion about open core compared to the use of open source components in a larger proprietary product – such as IBM’s use of Apache within WebSphere.
To some people there is no difference between the two (since they both result in products that make use of open source but are not open source), however it is clear to me that while the end result might be the same these are very different strategies that involve different approaches to engaging with open source communities/projects.
While open core has a clear definition there is no agreed term or definition for the latter category.
Over the years we have used a variety of terms to describe it, including “open and closed”, “embedded open source”, “open inside” and “open complement”, while Jack Repenning has referred to it as “open infrastructure”.
Our next categorization of open source-related business strategies is still a work in progress but the current thinking is as follows:
(This categorization is a work in progress, we welcome and encourage any feedback)
Open core and open foundation have different evolutionary lineages: open core is a variation on dual licensing as practiced by the likes of MySQL and Sleepycat that also borrows heavily on the value-added subscription model as practiced by Red Hat and JBoss. Meanwhile open foundation has its roots in the commercialization of BSD, which pre-dates the concepts of open source and free software, as well as Apache.
From a practical perspective, the easiest way to think of the distinction between open core and open foundation is via an example:
PostgreSQL is an independent, community-developed open source project. EnterpriseDB offers extensions to the PostgreSQL core, such as Oracle-compatibility, in the form of Postgres Plus Advanced Server.
PostgreSQL has also been used by many other vendors to create commercial products. For example Greenplum used PostgreSQL as the foundation of its Greenplum Database (for other examples see this post). This allowed the company to build on proven database technology and avoid reinventing the wheel, but it also involved the creation of an entirely new product, rather than extensions to an open source project (the company initially actually started a new project, Bizgres, and created extensions to that but Bizgres was last seen in August 2008).
So 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.
The example used above highlights three important points to consider when comparing open core and open foundation strategies:
1/ While open core is most readily associated with vendor-controlled projects it can also be used as a strategy to monetize community-controlled projects.
2/ Open core strategies can be used in conjunction with complementary strategies. In the Greenplum example the company’s relationship with Bizgres was open core, while the relationship with PostgreSQL was open foundation. Similarly there is an open core relationship between Actuate’s BIRT products and the Eclipse BIRT project, and an open complement relationship between Actuate 10 and the Eclipse BIRT project. Meanwhile there is an open core relationship between Day Software’s CRX content repository and the Apache Jackrabbit and Sling projects, and a open foundation relationship between CQ5 and Jackrabbit, Felix and Sling – as well as the numerous other Apache projects that Day contributes to.
3/ Open core and open foundation are licensing strategies used as part of a larger business strategy for engaging with and commercializing open source software, which highlights the futility in trying to pigeon-hole companies as “open core vendors” or “open source vendors”.
Finally it is worth thinking about the different tensions that the open core and open foundation strategies create with their respective communities.
As Jorg Janke notes, “looking for an income stream as an open source vendor always results in some sort of conflict with the community. So, you have to pick the community you want to ‘offend’.”
With a vendor-controlled open core strategy the community is a user community, and as we have previously discussed the conflict is in deciding what features belong in the core and what features don’t.
With an open foundation strategy the community is the open source project developer community, and the conflict lies in deciding what features and resources to contribute to that project.
A community-controlled open core strategy arguable results in conflict with both the user and developer communities, although since the vendor does not own or control the project the relationship is much more comparable to the open foundation strategy.
We will be writing more about other strategies for generating revenue from open source software, in a follow-up to our Open Source is Not a Business Model report, which is due to be published latter this year. It will provide more context for the economic motivators and issues involved in the various models, as well as updated research on which vendors are following which strategies, and why, as well as a survey to uncover what software users make of it all. The report will be freely available to CAOS subscribers. For more details of the CAOS research practice, and to apply for trial access, click here.
In the first part of this post I discussed the underlying division that drives the debate about open core, and the futility of arguing about what constitutes an “open source company” without any relevant definition.
Since then Monty Widenius has proposed a definition that would exclude any company that does not produce open source software (including open source support providers) and any company that does not provide access to 100% of its code (which would often exclude Red Hat as it moves to open source acquired code).
In the meantime others have declared that there is no such thing as an open source company and decided instead to discourage use of the term altogether. This is the logical conclusion of the argument that Open Source is Not a Business Model, and while this seems like a nuclear option, it does at least mean that we can hopefully avoid repeated arguments about whether company X is an open source company or not.
Since we seem to be able to move on from the theoretical argument about whether open core vendors are open source or not, it is an opportune moment to turn the debate towards a more practical assessment of the open core strategy and its strengths and weaknesses.
This second blog post turns attention to the open core strategy itself and examines some of the common criticisms. Some of them are valid, some exaggerated, and some are misunderstandings. If the debate is to progress it is important to stop fixating on issues that fit in the latter two categories and focus on those that fit in the first.
There are plenty of criticisms to choose from, and this is a complicated subject, so this is a long post. I have tried to cover all the major issues in one go in order to give a thorough representation of my views on the subject.
For an overview of the open core model itself and how it compares to other strategies for generating revenue see this post. With that in mind (deep breath) here goes:
Crippleware
Since open core relies on generating revenue from proprietary extensions to an open source core it is often asserted that the open source core will be crippled in some way to ensure that users opt for the proprietary version.
That is like claiming that open source support providers deliberately make open source projects difficult to work with in order to sell more support contracts.
Any strategy that worked like that would be flawed. That is why the open core strategy does not work that way.
Like the open source support strategy, open core relies on having a ubiquitous, fully functional, open source project.
Instead of selling support, open core vendors sell value-added features that are designed to be of value to paying customers. Of course the strategy relies on segmenting the audience for the product and delivering features that would be appropriate to each.
As Simon Phipps wrote:
“The community edition is used by a group of people who have the time and skills to deploy by themselves and who have no need of the many differences of the commercial versions. The commercial versions are feature-rich and effectively lock their users into a traditional commercial ISV relationship with the vendor.”
I’m sure open core vendors would dispute the reference to lock-in, but Simon’s comment makes it clear that there are two audiences for two separate products.
This distinction is important in understanding how Likewise Software can claim that customers drive open core: “The added functionality in Enterprise benefits a very specific segment of our community, and we work closely with our enterprise customers to ensure we provide value here.”
The point is that paying customers, as opposed to open source users, see value in the proprietary features and are prepared to buy the product. The strategy will fail if open source users also see value in those features but are denied them, or are forced to pay to adopt them.
The phrase “bait and switch” is often used to criticize the open core approach (indeed the term open core was promoted specifically to provide an alternative vocabulary to bait and switch) and suggests that users are either tricked or forced into taking the proprietary features. Clearly any strategy that relies on misleading potential customers is going to be short-lived.
It is true that some vendors are not great at communicating the differences between the open source core and the proprietary version in the past, but our previous transparency test indicated that they have got a lot better in that regard.
To some extent this is as a result of pressure from open source advocates. More than that though, I believe, it is the result of vendors realizing that a successfully executed open core strategy relies on transparency and in not attempting to sell anything to community users (and vastly improving the quality of their marketing communication).
While open core vendors have in the past been guilty of treating the community a sales pipeline, we have observed that the next generation of start-ups has learned that the best way to encourage a frictionless relationship between a vendor and its community is not to attempt to “convert” users at all.
It goes without saying that forcing users to use the proprietary extensions is going to be flawed – the open core strategy depends on keeping both users and paying customers happy, independently.
Managing that is not easy, as our research has confirmed. As previously noted, our CAOS report into how open source changes approaches to sales and marketing included a few choice quotes from open core vendors on its challenge:
“Number one [challenge] is differentiation between core and commercial.”
Clearly, the difficulty with open core is in deciding what features to put in which version, and what proportion of a company’s engineering effort should be focused on the open source project.
“We can compete with ourselves; i.e., our commercial product may not be purchased because our open source/core product contains sufficient functionality to solve customer problems.”
It is a significant challenge and some vendors have been better at it than others but it does not follow that because this challenge exists then the core must be crippleware. Indeed the success of the strategy depends on it not being crippleware.
“Continuing to maintain the right balance of functionality between the freely downloadable open core and the commercial extensions is both art and science. It’s critical to get that right so the model continues to grow and advance.”
Are there some open core open source projects that are lacking in quality? Of course, but that doesn’t mean that all open core open source projects are crippleware. There are some pretty crappy “fully functional” community-developed open source projects – that does not mean the community development model is flawed.
Half a product
In response to Larry Augustin’s statement that “Well over half of our engineering effort produces code that is released under an OSI approved license”, Tarus Balog commented:
“Well over half? Well, that’s pretty good, but is open source code something that can be divided? Can I say “here is the product, but you only get to use half of it under an open source license”. Who decides which half? If I look at it in binary, do I just get to use the ones or just the zeroes?”
I am assuming Tarus is deliberately misunderstanding Larry’s statement in order to be facetious/mischievous (the last line certainly suggests so) but the statement highlights another misconception of the open core strategy – that the vendor starts with a fully-featured product and then divides it into the basic core (open source) functionality and the value-added (proprietary) extensions.
As we have already stated, however, in order for the strategy to work the core project must be widely adopted. For that to happen it needs to be a complete project. As Jack Repenning notes:
“if the open parts accomplish their goal fully and well… then the open-source product deserves to be assessed on its own terms. If there are also commercially licensed, or even proprietary/closed things associated with it that together accomplish some larger goal, that’s a different product, not a betrayal of the open one.”
The biggest issue that open core has, in my opinion, is that it attempts to bypass Clayton Christensen’s law of Conservation of Attractive Profits, which states that “When attractive profits disappear at one stage in the value chain because a product becomes modular and commoditized, the opportunity to earn attractive profits with proprietary products will usually emerge at an adjacent stage.”
It is this law that explains why it is difficult for open source support vendors to generate significant profits (since they have commoditized their own stage of the value chain). The same is true of open core vendors, except that that are attempting to commoditize only a portion of their value chain – the core functionality offered by the open source version, while betting that their value added extensions are sufficiently differentiated to retain the ability to generate profits.
Christensen’s law dictates that it will always be easier to generate profit at an adjacent stage. Or, as Matt Asay explains in the context of the OpenStacks project: “The reason OpenStack may be a big winner is that Rackspace doesn’t need OpenStack to make money. At least, not directly.”
Community matters
Cloudera recently told The 451 Group that 50% of its engineering effort is focused on open source projects (specifically Hadoop and its related projects) with the other half focused on the proprietary capabilities that are delivered in Cloudera Enterprise.
No one would suggest that Apache Hadoop is a limited or crippled project, simply because Cloudera (and IBM, Karmasphere and others) are offering closed-source complementary products.
Of course the difference between Hadoop and SugarCRM community (or many other open source core projects) is that Hadoop is a community-developed project, while in vendor-led open core projects are dominated by a single vendor.
This enables accusations of lock-in and a lack of community contributions to the development process. I’ll address the first issue shortly, but with reference to community development it is undoubtedly true that the majority of vendor-led open core projects do not enjoy the benefits of a collaborative development process.
Carlo Daffara explains how the strategy is a tradeoff between monetization and contributions, noting that “it is simply not possible to get something like Linux or Apache with open core”.
That is true, but then that is also not the aim of open core. Vendor-led open source projects are invariably more focused on creating ubiquitous platform and lowering barriers to adoption than they are on creating ubiquitous platforms for collaborative development.
Not all open source software projects are collaboratively developed. Whether this is a concern is very much a matter of personal opinion – is it enough that software is under and open source license, or does it also have to be developed collaboratively?
It is a problem, of course, if a company actively avoids contributions from elsewhere on the grounds that that doing so would impact their proprietary extensions. Simon Phipps notes that one of the reasons NASA involved itself in the OpenStacks cloud projects was due to frustration with Eucalyptus Systems’ reluctance to accept contributions that competed with its closed extensions.
Clearly this highlights a potential problem for open core vendors, but it is one that actually contradicts the accusation that open core users have no choice but to accept the proprietary extensions. While there is lock-in associated with any software choice, one of the weaknesses of the open core approach is users could decide to fork and/or develop open source versions of the proprietary features.
Similarly, Dana Blankenhorn reports that SplendidCRM has already replicated the user interface delivered in SugarCRM’s paid-for versions and made it available in its own community edition.
It is important to note, however, that while issues related to the community contributions are a symptom of the open core licensing strategy, they are by no means exclusive to open core.
The recent debate about open core was kicked off my this post by former Compiere CEO Jorg Janke about the apparent failure of Compiere’s strategy in putting too much emphasis on the closed extensions (as well as mistakes related to the partnership model).
In a follow-up post Jorg turned his attention to the project’s lack of external contribution. While it is clear that this was an issue that was exacerbated by the open core strategy it is important to note that the development model was dictated by a decision that was taken prior to the open core strategy being adopted.
Similarly the vast majority of the developers of the MySQL database have always been employees of its owner (first MySQL, then Sun and now Oracle). The shift towards open core (and it hasn’t got there yet) came much later than the decisions that prompted the development model.
Development costs
One area in which the lack of community does matter, of course, is in the R&D costs of open core vendors. The greater a proportion of employees that you have focused on development (of open source or proprietary code) the greater your development costs are going to be. This is undoubtedly a valid criticism of the open core model as the company is failing to benefit from R&D cost savings in terms of both the open source core and closed source extensions.
Arguably, the company is also impacted by higher development and testing costs since the closed source extensions do not benefit from exposure to the open source user community. How significant this additional cost might be depends on the significance of the extensions and the relative size of the community (since the vendor will still go through the traditional alpha/beta testing with its paying customers).
Another cost, arguably, is the loss of quality in the proprietary extensions resulting from the smaller testing group and the lack of open source code review. Again this is a valid criticism, but it is one that belongs in a much larger debate about the relative benefits of open source and proprietary development strategies.
Venture-capitalist tool
Jorg’s initial post also discussed how VC investors had pushed Compiere towards the open core approach, and another criticism is that it is the chosen OSS-related business strategy of VCs. Again this is a valid argument. There is no doubt that VCs are attracted to the open core strategy and have encouraged its wider adoption.
However, it is also worth noting that there are exceptions to the rule. OpenLogic is a VC-backed company that has been vocally critical of open core, while xTuple is a self-funded open core vendor (there are other examples).
I would also point out that VCs are also fully aware that for the strategy to be successful it depends on a ubiquitous, full-functional open source core, and that attempts at crippleware will fail.
Lock-in and other problems
Perhaps the most obvious criticism of open core, from an open source perspective, is that it perpetuates the use of proprietary software. Again this is valid, and I have previously covered why I think open core vendors are limiting their opportunities by focusing on product-led strategies and leaving themselves open to accusations of lock-in.
Again these are really issues for a larger debate about the relative merits of proprietary and open source licensing.
Finally (one hopes) the other major criticism of open core vendors is that they are misusing the term open source to describe themselves (or as Henrik Ingo put it “So if I don’t call myself ‘open source vendor’, then everything is fine? (yes)”
Assuming the decision to avoid using terms like “open source company” are maintained, this becomes less of an issue, but it is worth noting that the attempts at policing the term have been counter-productive.
The point is this: if you want open core vendors to refer to themselves as “open core companies” rather than “open source companies” then demonizing the open core strategy is not the way to go about it. Is it any wonder that Larry Augustin does not want SugarCRM to be seen as open core when accusations of crippleware are being thrown around?
Previously, Redmonk’s Stephen O’Grady noted that there is the potential for serious collateral damage in the way the debate about open core licensing is progressing.
Henrik Ingo notes that companies like CollabNet (which is not open core) is “concerned about the negative image now attached to open core and worried that his company would then be suffering from the negative image too.“
There are many ways in which an open core strategy could fail, but that does not mean that all open core strategies will fail. Open core is just the strategy -how you execute that strategy determines whether you succeed or fail.
I agree with CollabNet’s Jack Repenning that the conversation needs to move “a bit towards how to do it right, and away from confrontation”.
That was my aim with these two posts. I am sure there are plenty of people who will disagree with plenty of the things that have been written above. My intention is not to be confrontational but to take a balanced view of the potential problems related to the open core strategy.
We will be writing more about other strategies for generating revenue from open source software, in a follow-up to our Open Source is Not a Business Model report, which is due to be published latter this year. It will provide more context for the economic motivators and issues involved in the various models, as well as updated research on which vendors are following which strategies, and why, as well as a survey to uncover what software users make of it all. The report will be freely available to CAOS subscribers. For more details of the CAOS research practice, and to apply for trial access, click here.