List:Packagers« Previous MessageNext Message »
From:Robin H. Johnson Date:September 19 2007 9:26am
Subject:Re: Distro packaging decisions and the non-public Enterprise source
View as plain text  
On Tue, Sep 18, 2007 at 05:57:47PM +0200, Colin Charles wrote:
>> 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.
> Yes. But the bottom-line is that MySQL revenues aren't expanded. And if a 
> knowledgeable consultant is retained, maybe she will recommend MySQL 
> Enterprise?
I'd call that overly optimistic, when they can bill for more time
deploying Nagios etc instead of MySQL Enterprise Monitor (EM), and integrate
the rest of the clients needs with Nagios better, rather than trying to
integrate with the unknown of EM. I haven't seen ANY documentation on EM
anywhere on dev.mysql.com/doc/ - there are a couple of articles, but
nothing to build ground-level support to encourage users to look at EM.

> A lot of non-paying users use MySQL provided by the distributions. We don't 
> have exact statistics, but this number is high
>
> Those that are downloading binaries, are ones that have "laggard" 
> distributions, or want to try the newest greatest stuff. Of course, the 
> Enterprise users get our "certified" binaries as well
And which set of those users is more likely to convert to the paid
Enterprise version? I'd say neither.

> We have spoken to Debian, and Debian have decided to go MySQL Community for 
> their next release. Ubuntu has done similarly, as they just pull from 
> upstream. SuSE has expressed interest in continuing with Community, and 
> Fedora/RHEL are the only special case, in where they are bound to ship 
> Community (unless its in their Stacks package, where they ship Enterprise)
Aside from the possible maintainer load (human reasons) and contractual
obligations (legal reasons), there is no technical reason stopping
distributions from shipping both CS & ES as Gentoo does.

For distributions with good build and packaging systems, I'm reasonably
certain that the maintainer load for building isn't overly high either.
I was the sole Gentoo maintainer of MySQL for 2 years (2003-2005), and
then the backup for two years while we had two other developers with a
stronger MySQL interest (and I had other things going on), but the past
6 months, I've been back as the sole maintainer, as they had other
things now. The package maintenance requirements for MySQL are
considerably lower than some of the other packages I maintain, thanks to
a large (but not quite perfect) testsuite.

The Gentoo ebuilds for ES vs. CS have a very large degree of common code
(in mysql.eclass), and the only unique code per version is specific
disabling of broken test cases (Some versions have NDB that doesn't like
the sandbox for example). I put two hours in prepping the latest MySQL
releases in Gentoo the other evening, and that got me the latest 5.0
enterprise and 5.1 beta, on 3 architectures. I have NOT pushed them to
the main tree yet, pending the outcome of this discussion, and me
tracing the one test failure of mysqlclient.

>> 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.
> Not providing any binaries for community users is not a scalable solution. 
> We have Windows and OS X users to also worry about.
Making choices to lessen your non-paid support load was the idea here.

> And as a company selling support, we cannot tell people to take their 
> gripes to distributors first. 24/7 support, with an answer guaranteed in 
> under 30 minutes - this is not something a distributor can deliver
>
>> 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.
> These fixes aren't "withheld" so to speak. They are just delayed. The 
> source tree online has them...
And next time the tree gets a fix (specifically one that might be
important to some user, but isn't an issue for many other users), say a
week after the CS version is released, that means 80+ days to wait for
the next quarterly release while putting up with the bug.

Is it MySQL's hope that the user is sufficiently pissed off that they
will pay (for Enterprise) to get the fix, while not resourceful enough
to get the changeset and apply it themselves?

> Where did adaniels mention what you've said?
He responded to Kaj's post on "Communication Challenges"
http://www.planetmysql.org/kaj/?p=124#comment-18318

-- 
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