Thursday, 9 August 2007

Communication Challenges for the MySQL Community Team

With the my blog entry yesterday on Refining MySQL Community Server, did anything really change? If so, was it for the better or for worse for the community?

My answer is "not much", and "for the better", but feel free to disagree.

Judging from some reactions in the community, a lot changed, and for the worse.



Strong words.

So let me expand on the "not much" part:

The negative reactions that I experienced on the #mysql-dev channel in the Freenode IRC chat stem (like Mike Kruckenberg's blog) from the removal of the source code of MySQL Enterprise Server from ftp.mysql.com. I argue that while this may feel or appear like a step away from Open Source, the real effect on the core MySQL community member is minuscule. And this is by design. We don't intend for the change to adversely affect core MySQL community members' usage. What we do intend is related to positioning: MySQL Community Server is for our users, MySQL Enterprise Server is for our paying customers. We want people to associate MySQL Enterprise Server with a commercial relationship to MySQL as a company.

Hence, we thought about what we could do to encourage the use of MySQL Community Server, in particular by the Linux distributions. Part of that is discouraging the use of MySQL Enterprise Server, and that's why we set a signal by removing the source code of the Enterprise incarnation of the MySQL Server code.

But I want to underline that we also took a number of positive measures -- carrots, if you will -- which brings me to the "for the better" part.

First and foremost: We stopped adding new features to a GA release. No more new patches to 5.0. Adding new features to 5.0 is the "that" that I was above all referring to in IRC when saying (as now quoted by Jeremy)
<kaj> JeremyC: Our past 10 months since Oct has been a struggle to make that work, and we’ve failed


Having a stable release which gets new features is like squaring the circle. It's not doable in Euclidean geometry. This is also where I feel Jeremy's pain. There are plenty of reasons to want to have new functionality into a stable release, without the burden of the destabilisation introduced by other new functionality.

As I understand Jeremy's non-Euclidean solution (and there are other geometries than that of Euclid), he wants to pick and choose individual patches, and build an abundance of binaries with a free combination of those patches. While that may be technically feasible, it gives MySQL Community Server a different role from the one intended by MySQL AB. MySQL AB gave two mandates to MySQL Community Server: being experimental, and being the main one used by the MySQL user base. The mandate of MySQL Enterprise Server was the opposite: being stable, and being the one used by customers entering a commercial relationship with MySQL. That equation is the other "that" which hasn't worked in the past ten months at MySQL AB.

Now, yesterday's announcement recognised that these requirements are conflicting. That's where we failed. The community doesn't want to merely experiment, it wants to use a stable version. And the changes announced yesterday are about making Community Server stable. On top of that, we increase the predictability and planned frequency of Source releases (which we do to encourage Distributions to use MySQL Community Server). Jeremy correctly points out that the frequency doesn't change much compared to our actual track record on release frequency during the last 6-7-8 months. Personally, I wouldn't necessarily count it to our disadvantage that we've released more frequently than planned (which was twice a year). The more-frequent-than-planned releases is another indicator of the failure of the double mandate ("experimental" plus "main version"), that yesterday's announcements are supposed to improve.

Another solution, which I suppose would have pleased Jeremy, is to fix the situation by removing the mandate of MySQL Enterprise Server to be associated with a commercial relationship with MySQL. Then we would have one stable and one experimental variety of MySQL Server, regardless of the dimension of paying vs. non-paying. That would dissociate the brand of "MySQL Enterprise Server" with paying-only. And different branding of servers, in turn, is one of the basic current assumptions of Community versus Enterprise. I do understand that this distinction is not one that the Community particularly cares about. However, indirectly, a successful commercial company behind MySQL fuels the virtuous circle from which the community benefits in the form of new GPL features developed by MySQL AB.

Speaking of GPL: I want to make it perfectly clear that we have no intentions of moving MySQL Enterprise Server to another license. Yes, we are evaluating GPLv3 instead of GPLv2, but our plan is for both Community Server and Enterprise Server to remain GPL.

So in summary, I do say "not much" has changed. We have recognised some impossible requirements on the Community Server, and made the difference between Enterprise Server and Community Server consist mainly of the packaging (release schedule and availability). Same features, same bug fixes, different schedule, different branding.

I hope to now focus on making the best out of both Enterprise and Community server, feeding the virtuous circle of open source software.

5 comments:

  1. [...] Kaj réagit aux discussions d’hier. Mais qu’est ce que cela va changer pour le user landa? Va-t-il se tourner vers la version enterprise? Sachant que j’ai encore des serveurs qui tournent MySQL du 3.23, du 4.0 et du 4.1, cette restructuration aura-t-elle un impact pour moi? Non je ne crois. Pour des grosses sociétés, tous les bugs sont trouvés en phase de test… si la version courante est buggé, je prendrais la précédente. [...]

    ReplyDelete
  2. [...] http://www.planetmysql.org/kaj/?p=124 [...]

    ReplyDelete
  3. I disagree with You in that the separation is a good thing.

    In my work I have always favoured open source, and MySql has been one of my choices.

    The main reason for this is that I believe that an open source commuity with ALL source code available is the best solution in the long run.

    The road You have selected now says to me that the MySql company uses more of its resources on making even more money.

    So the next step from You will likely be another move in that money direction

    I feel that You have started a direction that will lead to the fact that a MySql solution after a while will hav taken it self away from the potition it has today, as the obvious choice.

    Stick to the "make money on service" way....

    gvenaas

    ReplyDelete
  4. java.org »
    http://javam.org/mysql-kapaniyor/
    MySQL kapanıyor !!!
    MySQL kaynak kodu enterprise’a eklenerek ücretli hale getirildi.
    Özetle:
    * Açık kaynak topluluğu kendi haline bırakılacak
    * Para ödeyen enterprise kullanıcılarına öncelik verilip onların dertleriyle ilgilenilecek...

    ReplyDelete
  5. Everyone smiles in the same language.

    ReplyDelete