Re: Distro packaging decisions and the non-public Enterprise source

From: Robin H. Johnson <robbat2(at)gentoo.org>
Date: Mon Sep 10 2007 - 20:33:31 EDT

On Mon, Sep 10, 2007 at 11:08:28AM +0200, Joerg Bruehe wrote:
> For all external readers who did not get that yet, I will describe the
> conflicting goals of the enterprise - community split:
I'd also like to point these folk to one of Kaj's blogposts: http://www.planetmysql.org/kaj/?p=124

> - From a financial point of view, MySQL AB has an interest that
> companies become paying customers and use the "enterprise" version.
> Several of our sales people fear this will not happen sufficiently if the
> sources of that version remain publicly accessible,
> or if those customers do not receive a faster delivery than the non-paying
> community users.

The sales people in that case are after a tangible - having the paying users have fixes before the non-paying users. I don't think that's a suitable way to differentiate between the groups of users.

> - Also on the technical side, it is difficult to draw the line between a
> bug fix (which has to go into enterprise packages) and any other change in
> behavior (which the community should receive first, to get feedback about
> its usability etc).

I'd like to point out the Fedora/RHEL model here, as mentioned by the folks at LWN (http://lwn.net/Articles/245629/): All changes go into Fedora first, and the fixes of that are then applied to RHEL as they are validated by existence in Fedora.

> - From a technical point of view, MySQL AB has an interest to deliver
> changes to the community as fast as possible.
> However, building community packages comes with an effort (resource load
> which may conflict with enterprise builds).
The downloads page (http://dev.mysql.com/downloads/) along with the feature list (http://www.mysql.com/products/enterprise/features.html) attempt to differentiate ES and CS, however I think they fail in that regard:
- "Automated notifications": -announce lists and reading the ChangeLog. - "Proactive, visual notification... optimal performance.": available   from MySQL AB or anybody offering MySQL consulting (enabled by the   MySQL certification programs, but those are certainly not a   requirement for a consultant).
- "Continuous monitoring of systems": Nagios can fill this role, as can   the Dashboard that is available with silver and up levels. - "Replication status monitoring": Again the field of Nagios. - "experienced technicians": see again consultants. The only thing going   for MySQL AB is that their folk have the most experience actually   developing in the codebase of MySQL.
- "Fast resolution and commited response times": at last, something   saleable - the value of being able to pass the problem on to somebody   more knowledgeable and get a response in a suitable timeframe. Be   careful however, consultants can also fill this role, but 24x7, 1 hour   response time is tough - maybe somebody internal could say how often   they have had to put out Hot Fix builds per the gold and platinum   levels?.

What is different between the paying user and the non-paying user of MySQL?
- To state the obvious first, they fact that they don't pay MySQL AB.   However this does not mean that they don't pay anybody. They may have   an employee or retained consultant that is very knowledgeable about   MySQL.
- Size of deployment: while not a solid fixture, I would hazard that   they larger they are, the more likely they are to be a paying customer   of MySQL AB.
- Extended life-cycle support: Most of the community should be moving   faster than big business. Witness the hosting facilities that still   give customers RedHat7.2.
- Indemnification: how many customers have actually taken MySQL up on   this?

> Obviously, MySQL AB is still working on finding a way that satisfies all
> these goals simultaneously.

I do realize that it's putting them between a rock and a hard place. The services market by it's nature can require more ongoing effort than providing a tangible product.

Here's a question that the folks at MySQL might be able to answer from their data. What proportion of the non-paying users are using MySQL provided by their distribution, vs. those that are downloading the binaries (not the source) provided by MySQL AB?

Linux popularity is always tough, but it's probably safe to say that Ubuntu, Debian, Suse, Fedora/RHEL together cover 70% of the machines. Glancing at the MySQL packaging for those distributions, they seem to use the community version along with back-porting their own fixes from newer enterprise versions. (Additionally, Debian's popcon suggests only 20-40% of Debian users have mysql.*server packages installed).

How about making paying customers get binaries and not providing any binaries for community users (or releasing the same enterprise binaries with a few versions lag). Strongly encourage non-paying users to use their distribution's provided files, and to take support issues to their distributor first. Simply put, those that provide binaries/packages of MySQL, should be the first line of support.

This would probably mean the DorsalSource folk would switch to providing binaries - and are responsible for support of those binaries.

Would this really be an issue?

> > The Changelog for ES 5.0.48
> > (
http://www.mysql.org/doc/refman/5.0/en/releasenotes-es-5-0-48.html)
> > lists fixes for issues that I'm certain I'v seen in production.
> > [[...]]
> > Average of 64 days between releases, however 67 days have passed since
> > the last community release, and I don't know when the next community
> > release will be. The BK commitlog shows nothing for the last 10 weeks
> > (
http://mysql.bkbits.net:8080/mysql-5.0-community/?DATE=-12w..&PAGE=changes).

> Changes are transferred from the enterprise sources to the community sources
> in larger batches, not one by one as they are developed.
And with Kaj's blog post talking about making community releases more frequent, you could just as easily make them source-only from a single code line. As adaniels noted, withholding needed fixes only reflects badly on those considering MySQL for enterprise usage. It's a hell of a lot easier to install MySQL with your distribution's package management system that to go and apply for a trial of the Enterprise version.

> > So what do we do? Responses, kudos, flames, I want to hear it all.

> I hope this will raise more replies than just mine, and maybe we even find a
> solution that pleases both the community and the sales people ?
I'm going to try and direct the other distro developers to come and join the discussion.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


application/pgp-signature attachment: stored

Received on Mon Sep 10 20:33:39 2007