This is inconsistent to the original MySQL business model. The main strength of MySQL has always been that all MySQL source code was freely available. It was thanks to this that MySQL got widely adopted and got to be used by tens of millions of users.
This was a fact that the MySQL board and Sun understood. Closing the MySQL server code base in any manner would be bad for long term business.
It's true that we in MySQL Ab did have some people, notable persons who came from the commercial world and did not understand or believe in free software, that spoke strongly for an open core model where some parts would be open and others closed. Initially they could not do this, mainly thanks to the founders shareholder agreement which guaranteed that the MySQL server would be open source. When Sun bought MySQL, and the shareholder agreement expired, they saw their chance and announced that backup would be a commercial closed source extensions. This initiative was however quickly killed by Sun's management who did understand the true value of MySQL as an open source project and by making it closed source they would have made it less valuable.
One of the reasons MySQL AB did not need an open core model for it's business was that since MySQL is an infrastructure product that is easily embeddable into other products, we could sell licenses to those who wanted to embed MySQL into their product but did not want to make their product open source. (Dual licensing).
So what's so wrong with Open Core?
As a business model, especially to bootstrap a business, Open Core is not a bad idea. It gives you some leverage with your users to get part of your development paid for. This is however done at the cost of fewer users and a less adopted project. Many projects however abandon Open Core models when they grow as open source gives them more users and thus more value.
What is most important to understand about an Open Core project is that it has nothing to do with an open source project. If you are depending on a single closed source component then you have to regard the whole project as a closed source project as you lose all the benefits of open source:
- You are depending on one vendor.
- You can't do any bug fixes yourself and you can't contract anyone except the original vendor to get things fixed.
- You can't examine and improve the product (not any part of if).
- You can't use any open source or commercial extensions from anyone else. This is true also for any plugins that access any internal parts of the product (which is true for most MySQL plugins).
- You are limited to the platforms that the original vendors makes available. (In MySQL's case you can't for example use the new commercial features on RedHat 6 as it's not a supported platform).
- The builds you are using are not tested anymore by millions of users (more bugs).
- The product is not checked by the open source community for security problems or back doors.
- The new features will not be adopted by (and may even cause conflicts with) other open source projects.
- You are subject to one vendor's price politics which they can change at their convenience.
The new pluggable authentication, which makes the new PAM authentication possible, was developed and contributed to Oracle by Sergei Golubchik at Monty Program Ab.
The good news is however that the most important feature, the improved thread pool, is easily duplicated in MariaDB. We have had a thread pool in MariaDB since 5.1 (better than was in MySQL 5.1) and we are working on a new one for MariaDB 5.5 which we expect will have similar speed gains as MySQL enterprise. MariaDB don't yet have PAM authentication but the MariaDB developers are prepared to develop that if there is a need for it or if someone contributes the code to us. This should be relatively easy as we have the same pluggable authentication protocol as MySQL.
Read also Stewart Smith's thoughts and the comments to his blog about this subject.
Posts
