List:Packagers« Previous MessageNext Message »
From:Robin H. Johnson Date:September 11 2007 12:33am
Subject:Re: Distro packaging decisions and the non-public Enterprise source
View as plain text  
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@stripped
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Attachment: [application/pgp-signature]
Thread
Distro packaging decisions and the non-public Enterprise sourceRobin H. Johnson10 Sep
  • Re: Distro packaging decisions and the non-public Enterprise sourceJoerg Bruehe10 Sep
    • Re: Distro packaging decisions and the non-public Enterprise sourceRobin H. Johnson11 Sep
      • Re: Distro packaging decisions and the non-public Enterprise sourceMichael Shigorin11 Sep
      • Re: Distro packaging decisions and the non-public Enterprise sourceColin Charles18 Sep
        • Re: Distro packaging decisions and the non-public Enterprise sourceMichael Shigorin18 Sep
        • Re: Distro packaging decisions and the non-public Enterprise sourceJeremy Cole19 Sep
          • Re: Distro packaging decisions and the non-public Enterprise sourceColin Charles19 Sep
          • Re: Distro packaging decisions and the non-public Enterprise sourceJoerg Bruehe20 Sep
            • Re: Distro packaging decisions and the non-public Enterprise sourceJeremy Cole20 Sep
              • Re: Distro packaging decisions and the non-public Enterprise sourceJoerg Bruehe20 Sep
            • Re: Distro packaging decisions and the non-public Enterprise sourceCristian Gafton21 Sep
        • Re: Distro packaging decisions and the non-public Enterprise sourceRobin H. Johnson19 Sep
    • Re: Distro packaging decisions and the non-public Enterprise sourceMichael Shigorin11 Sep
  • Re: Distro packaging decisions and the non-public Enterprise sourceColin Charles18 Sep
    • Re: Distro packaging decisions and the non-public Enterprise sourceRobin H. Johnson19 Sep
Re: Distro packaging decisions and the non-public Enterprise sourceJeremy Cole11 Sep
  • Re: Distro packaging decisions and the non-public Enterprise sourceColin Charles18 Sep
    • Re: Distro packaging decisions and the non-public Enterprise sourceMichael Shigorin18 Sep
      • Re: Distro packaging decisions and the non-public Enterprise sourceColin Charles18 Sep
        • Re: Distro packaging decisions and the non-public Enterprise sourceRobin H. Johnson19 Sep
        • Re: Distro packaging decisions and the non-public Enterprise sourceMichael Shigorin19 Sep
    • Re: Distro packaging decisions and the non-public Enterprise sourceJeremy Cole19 Sep
      • Re: Distro packaging decisions and the non-public Enterprise sourceColin Charles19 Sep
Re: Distro packaging decisions and the non-public Enterprise sourceCristian Gafton21 Sep