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.
InternetNews.com yesterday published an article based on an interview with Red Hat CEO Jim Whitehurst asking the question “Is Red Hat Interested in the Database Market?”
In truth there was no real need to ask the question, as Whitehurst’s comments made it pretty clear that Red Hat is interested in the database market, and specifically the NoSQL database market.
“When I say I don’t want to be a database company, I’m saying that I don’t want to be a SQL database company,” Whitehurst said.
In case the implications of that statement were not entirely clear, he later added:
“But we would be very interested in a NoSQL type database or Hadoop type thing,” Whitehurst said. “Those are interesting as they represent net new.”
The article adds that Whitehurst would not specifically state whether Red Hat will or will not actually acquire anyone, as is to be expected, but the comments are the clearest indication yet that Red Hat sees value in a potential NoSQL acquisition.
This is something that we have seen for some time, pointing out in May 2010 that “We have consistently noted that the database remains a missing layer in Red Hat’s software stack… and would see advantages in adding an open source NoSQL database to its portfolio to target MySQL users.”
We are by no means the only people to have highlighted the database-shaped hole in Red Hat’s portfolio, but while Red hat has previously shied away from speculation linking it with a relational database vendor (seemingly in order to avoid disrupting its relationship with Oracle) as Jim points out, NoSQL and Hadoop are far more attractive given their growth is based on new projects, rather than the much tougher proposition of competing for incumbent database projects.
So what emerging open source projects might be of interest to Red Hat? Its OpenShift PaaS launched with support for 10gen’s MongoDB and later added support for Couchbase’s Membase, which makes them obvious contenders. We suspect that avoiding overlap and delivering compatibility with Red Hat’s JBoss Enterprise Data Grid technology would be a key part of the decision-making process.
As for Hadoop – Cloudera is the obvious choice but we imagine that any move would be likely to start a bidding war from which Red Hat might not emerge victorious. Hortonworks has only just emerged from Yahoo, of course, but might be an option for a more services-led approach.
Then there is DataStax, which could give Red Hat the opportunity to kill two birds with one stone with its Brisk Hadoop distribution and Apache Cassandra-related software and services.
InternetNews.com yesterday published an article based on an interview with Red Hat CEO Jim Whitehurst asking the question “Is Red Hat Interested in the Database Market?”
In truth there was no real need to ask the question, as Whitehurst’s comments made it pretty clear that Red Hat is interested in the database market, and specifically the NoSQL database market.
“When I say I don’t want to be a database company, I’m saying that I don’t want to be a SQL database company,” Whitehurst said.
In case the implications of that statement were not entirely clear, he later added:
“But we would be very interested in a NoSQL type database or Hadoop type thing,” Whitehurst said. “Those are interesting as they represent net new.”
The article adds that Whitehurst would not specifically state whether Red Hat will or will not actually acquire anyone, as is to be expected, but the comments are the clearest indication yet that Red Hat sees value in a potential NoSQL acquisition.
This is something that we have seen for some time, pointing out in May 2010 that “We have consistently noted that the database remains a missing layer in Red Hat’s software stack… and would see advantages in adding an open source NoSQL database to its portfolio to target MySQL users.”
We are by no means the only people to have highlighted the database-shaped hole in Red Hat’s portfolio, but while Red hat has previously shied away from speculation linking it with a relational database vendor (seemingly in order to avoid disrupting its relationship with Oracle) as Jim points out, NoSQL and Hadoop are far more attractive given their growth is based on new projects, rather than the much tougher proposition of competing for incumbent database projects.
So what emerging open source projects might be of interest to Red Hat? Its OpenShift PaaS launched with support for 10gen’s MongoDB and later added support for Couchbase’s Membase, which makes them obvious contenders. We suspect that avoiding overlap and delivering compatibility with Red Hat’s JBoss Enterprise Data Grid technology would be a key part of the decision-making process.
As for Hadoop – Cloudera is the obvious choice but we imagine that any move would be likely to start a bidding war from which Red Hat might not emerge victorious. Hortonworks has only just emerged from Yahoo, of course, but might be an option for a more services-led approach.
Then there is DataStax, which could give Red Hat the opportunity to kill two birds with one stone with its Brisk Hadoop distribution and Apache Cassandra-related software and services.
Opscode appoints a new CEO. SugarCRM gains a new CFO. And more.
# Opscode named Mitch Hill as CEO, with Jesse Robbins becoming Chief Community Officer.
# SugarCRM claimed billings up 58% in Q2 and appointed a new CFO.
# Tasktop released Tasktop Dev 2.1 and announced Tasktop Sync 1.0.
# Pentaho delivered improved support for Hadoop and various NoSQL database projects.
# The openSUSE community approved its strategy document.
# Dustin Kirkland described the Ubuntu Orchestra Project.
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.
When we published our 2008 report on the impact of open source on the database market the overall conclusion was that adoption had been widespread but shallow.
Since then we’ve seen increased adoption of open source software, as well as the acquisition of MySQL by Oracle. Perhaps the most significant shift in the market since early 2008 has been the explosion in the number of open source database and data management projects, including the various NoSQL data stores, and of course Hadoop and its associated projects.
On Tuesday, November 9, 2010 at 11:00 am EST I’ll be joining Robin Schumacher, Director of Product Strategy from EnterpriseDB to present a webinar on navigating the changing landscape of open source databases.
Among the topics to be discussed are:
· the needs of organizations with hybrid mixed-workload environments
· how to choose the right tool for the job
· the involvement of user corporations (for better or for worse) in open source projects today.
You can find further details about the event and register here.
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.
There is much excitement this week (understandably) about the formation of the Document Foundation and the LibreOffice fork of Openoffice.org.
Alan Bell sees correlation with the previous fork of Joomla from Mambo and has illustrated the potential impact that forking a project can have with a Google Trends chart, where Mambo is the blue line, and Joomla is the red line:
A similar chart for Debian (blue) and Ubuntu (red) is also instructive:
Or what about Nagios (blue) and Icinga (red):
Hmm. Maybe not the best example. After all, as we reported, the Icinga fork had some commercial motivations attached to it, and it’s not exactly the highest profile fork.
What about something a bit more comparable, like MySQL (blue) and MariaDB (red):
Oh.
Which is not to say that LibreOffice will not be a success, but when it comes to forking, creating the fork is clearly just the start. It takes time, and a lot of effort, to generate the momentum for a fork to be truly successful. There is bound to be an initial spike in developer and user interest. Turning that into a meaningful and productive community will be the hard part.