Sun + Oracle and Misguided EU Policy
I originally wrote this to the Bloomberg reporter who wrote a piece about Oracle's attempt to purchase Sun Microsystems. I hope to go into more detail here than I did in that e-mail, just to lay out the case for myself. I believe the EU Competition Commission has made inaccurate and misdirected (although not misguided) claims about the impact that Oracle ownership of MySQL will have on the database market. Feel free to let me know what you think. I want to use this to solidify my thinking on the subject.
Oracle's best argument is easy. While I doubt they will argue this publicly, it is well known in MySQL circles that they already did things which might have been said to hurt MySQL. In doing so, they may have hurt MySQL but they plantedseeds for the continued expansion and growth of the relational database market when dissatisfied users of MySQL turn(ed) to other products.
The most important thing Oracle did which eventually strengthened MySQL was buying InnoDB. InnoDB is the "engine" which actually stores the data in a MySQLdatabase. With MySQL, engines are pluggable, meaning you can replace one engine with another as your requirements change. The engine manages the on-disk storage format, in various file formats, of the data stored in the database. Engines provide the core functionality of the database, things such as ACID compliance, transactions, and other features that make a database a database. MySQL's default engine is MyISAM but the most popular engine with power users is InnoDB. InnoDB's features are what make MySQL similar to (but hardly as powerful as) Oracle. In the 4+ years since Oracle bought InnoDB, they have let it languish, and it has been eclipsed by other storage engines.
Oracle's failure to innovate with InnoDB led to the Maria and XtraDB projects. XtraDB is a direct fork of InnoDB. The same would happen if they tried to kill MySQL. Users concerned with this change in affairs would begin adapting the last version of MySQL for their own purposes. Since the source code is open, they already have the power and freedom to do this. This negates the EU's argument that forking is insignificant. Many significant open source projects are the result of forking, a well known example of which is the OpenBSD operating system which was forked from the NetBSD project.
Wait! MySQL has already been forked!!
Drizzle, which is also open source, is a fork of MySQL due to MySQL's (and now Sun's) slow progress in giving customers what they have asked for in MySQL. MySQL/Sun was lambasted for taking so long to release the 5.x series of MySQL. Even the founder of MySQL, Monty Widenius, publicly disparaged Sun and the actual software release for its bugginess, slowness and the long time required to ship it. (He did this while still employed by Sun.) While the 5.x series of MySQL has improved, there are still features which people will have to wait until the 6.x series to see them ship in MySQL. These are features available in other commercial and open source databases.
Then factor in the outside contributions to MySQL from Facebook and Google, among others. Don't forget Percona, the creators of XtraDB (and founded by former MySQL employees). All of these companies - today - have contributed software to the MySQL project, some of which has made it into the shipping product but much which has not. While they use MySQL because it fits their needs, there are other products which they are likely evaluating, products which seek to displace MySQL or otherwise address perceived MySQL shortcomings.
Don't let the EU argument mislead you. The EU will try to make a point that these MySQL patches that Google and others have released are not for the layman to use. A novice could not apply these patches to MySQL's source code and get a product as full featured as Oracle. This is true. However, a layman is not likely to use MySQL in the first place. A layman is not likely to use Linux, the most popular platform for deploying MySQL. This point, should the EU pull it out, is moot. The people who do use MySQL are VERY likely to apply these patches. A representative example of this type of power user is SmugMug, an online photo sharing service for professionals. SmugMug is famous for their technical acumen, and thus having the ears of technology vendors because of their scale, their technical demands and the fact that they are a paying customer. However, SmugMug's technical staff get their hands dirty with the code in order to squeeze every bit of performance and functionality out of MySQL. THESE types of customers have no problem applying patches to the MySQL source code and recompiling it. That is the Internet ethos at work.
The founder of MySQL, Michael "Monty Widenius", founded the MariaDB project.
Now we come to the point about the future of the relational data model in the modern, Internet-connected world. Relational database management systems (RDBMSes) are well known but that doesn't mean they are the "best" solution to every data problem. The world has seen the emergence of many types of data management systems designed to address specific problems, many of those problems being with scale and performance (Those are 2 different but related concepts.) There are in-memory databases, streaming databases and column oriented databases. Both of the companies referenced here were started by one of the pioneers in the RDBMS world, Mike Stonebraker. This is not a niche.
There are also simpler database systems designed to address specific data management problems of scale, but stripping away a lot of the complexity inherent in RDBMSes. One of the big concepts now is key-value stores, such as Redis, Tokyo Cabinet, Memcached, Mnesia and Amazon's SimpleDB. You have wide-column stores like Google's BigTable (Google only), Hypertable and HBase (both modeled on BigTable) and Cassandra, given to us by Facebook.
There are document oriented databases such as CouchDB and MongoDB. Let's also not forget eventually consistent key-value stores like Amazon's dynamo, LinkedIn's Project Voldemort and dynomite.
That seems like a lot of data storage choice to me. Some of it is traditional RDBMS, like MySQL, while some of it is implementation of cutting edge concepts in data storage. All of the projects are addressing particular issues that people have in real world usage. Some use SQL as their query language, while some have other methods. So the loss of MySQL would not be a huge loss in a very real sense. There are plenty of other options, just in the open source world.
We still have classic, open source RDBMSes which already compete with MySQL, including Stonebraker's PostgreSQL. Firebird. Then there are commercial RDBMSes on the market. Sybase has SQL Anywhere. Informix is still shipped by IBM, as is DB2. (I totally forgot about DB2.) Even Drizzle, which is a stripped down MySQL, is still a relational database, just stripped of much of MySQL 5.x's bloat.
As for the business of open source, we've already mentioned InnoDB. Let's not forget that Oracle also owns Berkeley DB via their acquisition of Sleepycat Software. Berkeley DB was and still is open source, available online for free downloads. Keep in mind that if Oracle tried to do anything to the actual code of any open source project code it owns, there would be mass downloads and forking of the last open versions of the code. This is what happened with SSH when Tatu Ylonen - the inventor of SSH - changed the license terms on versions after 1.2.12. The OpenBSD project forked that version into OpenSSH, which is far more popular now. While SSH Communications makes a business in providing a commercial SSH software suite, The OpenSSH project ships more SSH code and has more code in people's hands, being used daily. Even Sun integrated OpenSSH into Solaris back in the days of Solaris 9, giving the world SunSSH.
Oracle does have economic interest in MySQL if this merger goes through no matter what happens to MySQL itself due to owning InnoDB. MySQL/Sun dual licenses the MySQL software. This is the same business model that Sleepycat Software, the creators of Berkeley DB, has. Sleepycat is now owned by Oracle. MySQL/Sun customers who have paid for MySQL, either in the form of support contracts or consulting, will then look to Oracle to provide those services. That's real money, even if it is a pittance to Oracle as a percentage of their gross revenues. That's customer goodwill. That's potential upgrades to Oracle's core database product. So there is a certain amount of harm to itself that Oracle will seek to avoid once it owns MySQL.
Also keep in mind that Oracle has been a player in open source for a while, especially as they entered into the Linux market. Oracle is the biggest backer of Btrfs, a Linux filesystem under active development. This filesystem is seen as Linux's best shot at competing with the features of Sun's ZFS. The code is open, so if Oracle decided to no longer support Btrfs in favor of ZFS (which is a core part of Sun's Solaris and OpenSolaris operating systems), there is already a community around it which could keep Btrfs alive. Much the same could, and likely would, happen if Oracle ceased active involvement in MySQL or moved to close the code.
Oracle may eventually represent a threat to MySQL. However, the biggest threat due to Oracle's presence in the MySQL ecosystem is the indirect threat of Oracle being out innovated, out maneuvered, and whether intentional or not, allowing MySQL to atrophy. While there will be others who pick up the MySQL mantle, many have already moved on to projects and products that better suit their uses than MySQL does. Better than MySQL has for some time. As the owner of MySQL, it is in Oracle's interest to avoid that outcome, at least for a little while.
The Competition Commission's fears are overblown. Right now, the EU is headed toward destroying a competitor to HP and IBM -- thus, reducing competition in the systems market -- by holding up the Oracle acquisition of Sun. That's the real risk here. Sun is losing $100M USD per quarter, according to Larry Ellison. What does the competitive landscape gain if Sun dies? MySQL will still be open source, still be popular, and will still lose ground (slowly) to other competitors for other reasons. The EU will achieve none of its stated goals, so the real question is, are the goals it ostensibly claims it's real goals?
Oracle's best argument is easy. While I doubt they will argue this publicly, it is well known in MySQL circles that they already did things which might have been said to hurt MySQL. In doing so, they may have hurt MySQL but they plantedseeds for the continued expansion and growth of the relational database market when dissatisfied users of MySQL turn(ed) to other products.
The most important thing Oracle did which eventually strengthened MySQL was buying InnoDB. InnoDB is the "engine" which actually stores the data in a MySQLdatabase. With MySQL, engines are pluggable, meaning you can replace one engine with another as your requirements change. The engine manages the on-disk storage format, in various file formats, of the data stored in the database. Engines provide the core functionality of the database, things such as ACID compliance, transactions, and other features that make a database a database. MySQL's default engine is MyISAM but the most popular engine with power users is InnoDB. InnoDB's features are what make MySQL similar to (but hardly as powerful as) Oracle. In the 4+ years since Oracle bought InnoDB, they have let it languish, and it has been eclipsed by other storage engines.
Oracle's failure to innovate with InnoDB led to the Maria and XtraDB projects. XtraDB is a direct fork of InnoDB. The same would happen if they tried to kill MySQL. Users concerned with this change in affairs would begin adapting the last version of MySQL for their own purposes. Since the source code is open, they already have the power and freedom to do this. This negates the EU's argument that forking is insignificant. Many significant open source projects are the result of forking, a well known example of which is the OpenBSD operating system which was forked from the NetBSD project.
Wait! MySQL has already been forked!!
Drizzle, which is also open source, is a fork of MySQL due to MySQL's (and now Sun's) slow progress in giving customers what they have asked for in MySQL. MySQL/Sun was lambasted for taking so long to release the 5.x series of MySQL. Even the founder of MySQL, Monty Widenius, publicly disparaged Sun and the actual software release for its bugginess, slowness and the long time required to ship it. (He did this while still employed by Sun.) While the 5.x series of MySQL has improved, there are still features which people will have to wait until the 6.x series to see them ship in MySQL. These are features available in other commercial and open source databases.
Then factor in the outside contributions to MySQL from Facebook and Google, among others. Don't forget Percona, the creators of XtraDB (and founded by former MySQL employees). All of these companies - today - have contributed software to the MySQL project, some of which has made it into the shipping product but much which has not. While they use MySQL because it fits their needs, there are other products which they are likely evaluating, products which seek to displace MySQL or otherwise address perceived MySQL shortcomings.
Don't let the EU argument mislead you. The EU will try to make a point that these MySQL patches that Google and others have released are not for the layman to use. A novice could not apply these patches to MySQL's source code and get a product as full featured as Oracle. This is true. However, a layman is not likely to use MySQL in the first place. A layman is not likely to use Linux, the most popular platform for deploying MySQL. This point, should the EU pull it out, is moot. The people who do use MySQL are VERY likely to apply these patches. A representative example of this type of power user is SmugMug, an online photo sharing service for professionals. SmugMug is famous for their technical acumen, and thus having the ears of technology vendors because of their scale, their technical demands and the fact that they are a paying customer. However, SmugMug's technical staff get their hands dirty with the code in order to squeeze every bit of performance and functionality out of MySQL. THESE types of customers have no problem applying patches to the MySQL source code and recompiling it. That is the Internet ethos at work.
The founder of MySQL, Michael "Monty Widenius", founded the MariaDB project.
Now we come to the point about the future of the relational data model in the modern, Internet-connected world. Relational database management systems (RDBMSes) are well known but that doesn't mean they are the "best" solution to every data problem. The world has seen the emergence of many types of data management systems designed to address specific problems, many of those problems being with scale and performance (Those are 2 different but related concepts.) There are in-memory databases, streaming databases and column oriented databases. Both of the companies referenced here were started by one of the pioneers in the RDBMS world, Mike Stonebraker. This is not a niche.
There are also simpler database systems designed to address specific data management problems of scale, but stripping away a lot of the complexity inherent in RDBMSes. One of the big concepts now is key-value stores, such as Redis, Tokyo Cabinet, Memcached, Mnesia and Amazon's SimpleDB. You have wide-column stores like Google's BigTable (Google only), Hypertable and HBase (both modeled on BigTable) and Cassandra, given to us by Facebook.
There are document oriented databases such as CouchDB and MongoDB. Let's also not forget eventually consistent key-value stores like Amazon's dynamo, LinkedIn's Project Voldemort and dynomite.
That seems like a lot of data storage choice to me. Some of it is traditional RDBMS, like MySQL, while some of it is implementation of cutting edge concepts in data storage. All of the projects are addressing particular issues that people have in real world usage. Some use SQL as their query language, while some have other methods. So the loss of MySQL would not be a huge loss in a very real sense. There are plenty of other options, just in the open source world.
We still have classic, open source RDBMSes which already compete with MySQL, including Stonebraker's PostgreSQL. Firebird. Then there are commercial RDBMSes on the market. Sybase has SQL Anywhere. Informix is still shipped by IBM, as is DB2. (I totally forgot about DB2.) Even Drizzle, which is a stripped down MySQL, is still a relational database, just stripped of much of MySQL 5.x's bloat.
As for the business of open source, we've already mentioned InnoDB. Let's not forget that Oracle also owns Berkeley DB via their acquisition of Sleepycat Software. Berkeley DB was and still is open source, available online for free downloads. Keep in mind that if Oracle tried to do anything to the actual code of any open source project code it owns, there would be mass downloads and forking of the last open versions of the code. This is what happened with SSH when Tatu Ylonen - the inventor of SSH - changed the license terms on versions after 1.2.12. The OpenBSD project forked that version into OpenSSH, which is far more popular now. While SSH Communications makes a business in providing a commercial SSH software suite, The OpenSSH project ships more SSH code and has more code in people's hands, being used daily. Even Sun integrated OpenSSH into Solaris back in the days of Solaris 9, giving the world SunSSH.
Oracle does have economic interest in MySQL if this merger goes through no matter what happens to MySQL itself due to owning InnoDB. MySQL/Sun dual licenses the MySQL software. This is the same business model that Sleepycat Software, the creators of Berkeley DB, has. Sleepycat is now owned by Oracle. MySQL/Sun customers who have paid for MySQL, either in the form of support contracts or consulting, will then look to Oracle to provide those services. That's real money, even if it is a pittance to Oracle as a percentage of their gross revenues. That's customer goodwill. That's potential upgrades to Oracle's core database product. So there is a certain amount of harm to itself that Oracle will seek to avoid once it owns MySQL.
Also keep in mind that Oracle has been a player in open source for a while, especially as they entered into the Linux market. Oracle is the biggest backer of Btrfs, a Linux filesystem under active development. This filesystem is seen as Linux's best shot at competing with the features of Sun's ZFS. The code is open, so if Oracle decided to no longer support Btrfs in favor of ZFS (which is a core part of Sun's Solaris and OpenSolaris operating systems), there is already a community around it which could keep Btrfs alive. Much the same could, and likely would, happen if Oracle ceased active involvement in MySQL or moved to close the code.
Oracle may eventually represent a threat to MySQL. However, the biggest threat due to Oracle's presence in the MySQL ecosystem is the indirect threat of Oracle being out innovated, out maneuvered, and whether intentional or not, allowing MySQL to atrophy. While there will be others who pick up the MySQL mantle, many have already moved on to projects and products that better suit their uses than MySQL does. Better than MySQL has for some time. As the owner of MySQL, it is in Oracle's interest to avoid that outcome, at least for a little while.
The Competition Commission's fears are overblown. Right now, the EU is headed toward destroying a competitor to HP and IBM -- thus, reducing competition in the systems market -- by holding up the Oracle acquisition of Sun. That's the real risk here. Sun is losing $100M USD per quarter, according to Larry Ellison. What does the competitive landscape gain if Sun dies? MySQL will still be open source, still be popular, and will still lose ground (slowly) to other competitors for other reasons. The EU will achieve none of its stated goals, so the real question is, are the goals it ostensibly claims it's real goals?
Labels: technology
posted by Khyron at 02:23
7 Comments:
Hello,
You made quite competitive analysis of current MySQL state and forks.
As primary developer of XtraDB let me comment. XtraDB was started due to
lack of significant progress in InnoDB development during last 4 years. InnoDB got outdated and not being able to work on modern hardware. Increased activity in InnoDB development I correspond with fact that XtraDB was getting more and more acceptance between advanced technical users.
I expect that same happens with MySQL. You are correct that anybody can fork MySQL, however there is significant economical entry barrier, in Monty's analysis
he says it requires 5-10 mil ($, Euro) per year to have the competitive fork.
To finalize, if there will be lack of development in next 3 years and if someone will want to fork it, most likely it will be dead RDBMS at that time.
To saying that let me highlight that Percona is neither not against nor for deal. We accept it as business and will adjust our strategy in depends on outcome.
Vadim Tkachenko,
CTO, Percona
Vadim,
I get that. Responding to the point about the economics of a fork, I would ask if that 5 - 10M (EUR or USD) is really as big of a barrier as it appears?
What occurs to me is that there will be upfront (CapEx) and ongoing (OpEx) costs. However, will that 5M in cost come all upfront, or spread out over time? If it is all upfront, then yes, I can see that as a significant barrier. However, if we're spreading most of that out over time, then the wall gets lowered. Is it still significant? Of course. I doubt just anyone would take that on, but there are organizations, even small ones such as Percona, that could and would. At least, that's my thinking. Many of them will have revenue from other sources - consulting, support, other projects - so those costs may not be as imposing in the long run.
At least, that's my thinking. Did I miss anything?
Khyron,
I think that is annual recurring cost, however I did not do full calculation, just rough sum up.
Let's assume we need 10 good full-time developers with $100K/year salary and comparable amount of managers, administrative and support team ( and do not forget bug- and documentation team). MySQL in good old times had 40 full-time engineers.
That easily gives us couple millions of $ per year.
I think it is very hard to do without attraction of VC capital.
With VC investments, yes, it is quite possible, but not clear if
VCs are interested in.
Vadim,
Do you think a new project could ever replicate the success of PostgreSQL? Firebird will be somewhat interesting to watch going forward, in this regard. Can the community sustain a SQL database project without the levels of investment that you describe?
For something as visible as MySQL, I tend to think it can. I think supporters and sponsors will arise (if they don't already exist) because MySQL has brand equity, installed base, and there is such a wide body of institutionalized knowledge about it. While some of these might change in a fork -- such as loss of brand value due to a name change -- the project would not be starting from zero. It would also get lots of attention from the media, bloggers, geeks, etc. Percona may not be involved in it, but you and Peter would likely discuss this transition in various forums. (Your blog, for instance?)
Otherwise, based on what you've said, if MySQL were led to fork, then it's a dead product. Maybe a dead man walking, because the community may not get the message until much later. However, even if MySQL died, I think there are enough solutions available -- both open source and commercial -- that the crux of the EU and EC policy would still be incorrect.
MySQL is not the only SQL database available now, and even in Oracle's hands, how can it be said that too much power is consolidated with them? IBM has Red Brick, Informix and DB2. (Does Red Brick still exist?) No one is claiming that they have a lock on the database market.
Cheers!
Khyron,
I do not know if new project will reach popularity of PostgreSQL.
I think to get significant traction of users, the project should have next characteristics:
- Handle hundreds of GBs and provide
easy management tools for that amount of data
- Scale both SMP and MMP ways
- Have integrated caching solution
- Stable and flexible replication
- Detailed performance profiling tools
- Fast Backup and Recovery
- Have good pluginable architecture
- Actively accept third-party contributions
(Do I ask too much ? )
I think the project that comes with mentioned solutions will get
significant popularity.
It may be PostgreSQL, FireBird, MySQL / MySQL-fork, etc..
Actually Drizzle has goals similar to what I listed, but I am not sure
how Drizzle is financially stable to continue many-years development.
Also I do not believe that Oracle
will be interested to have MySQL with all these features ( meaning that MySQL will lose popularity and will lose to new project)
It also can be one of key-value project you mentioned in post.
One or couple of them will get more mature than right now and may win the race.
Basically we live in interesting time :)
Happy New Year!
Yeah, I don't see Oracle making MySQL as competitive with it's primary software product(s) as you would like. They'll position it as the "gateway drug" for 11g/Exadata, which makes sense to a degree. It's understandable, in an "Innovator's Dilemma" sort of way.
I think the ultimate point of the blog post remains unchanged. There's a plethora of options for SQL databases, commercial and open source. So I think the EU argument is weak, at best.
My feeling is that the Competition Commission has a silent directive to keep a lid on the expansion of American companies. I also feel that the CC and EU are trying to "defend" a European company. It seems like they are trying to make a political statement rather than preventing this merger for real competition reasons. Also, let's consider the 2nd order effect of reducing competition in the server market -- Unix, Linux and Windows -- if Sun goes out of business. This is a much more likely outcome if Oracle's acquisition of Sun fails.
How do you feel about the overall argument by the EU? Do you think there is limited choice in the database market? Do you (personally) think Oracle's purchase of Sun will limit choice? Yes, it may threaten MySQL's future, but the whole point of this blog post was that there were plenty of other competitive offerings if MySQL disappeared. The EU seems to be willfully overlooking these competitive offerings, again, in my opinion, for political reasons.
Khyron,
I think the question on competition is not simple and has no single answer. There also should be considered market data and numbers I have no access to.
On the one hand, the merge will definitely decrease competition on
MySQL vs Oracle battle. I personally
know many customers who switched from Oracle to MySQL. Also one of marketing direction MySQL was following is to Oracle->MySQL migration. Now this direction is closed afaik.
On the other hand it may actually even heat up market. Some big players will need to catch up Oracle with their dual system ( MySQL for entry-level users, Oracle for big customers) and come up with something similar. So MS and IBM probably will make steps to limit Oracle's market share in Web.
Post a Comment
<< Home