List:Packagers« Previous MessageNext Message »
From:Colin Charles Date:September 18 2007 3:57pm
Subject:Re: Distro packaging decisions and the non-public Enterprise source
View as plain text  
Robin H. Johnson wrote:

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

Yes, this has been brought up, and everything you've mentioned before 
has also been brought up. Our canned answer for this is that the 
internal server QA processes have improved tremendously, and there are 
many many test cases and an impressive test suite, hence MySQL has 
decided to try a "reverse Enterprise" model

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

Please keep in mind that the messaging isn't targeted at 'seriously' 
technical users, especially ones that use Gentoo!

> - "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?.

So, the above is what MySQL calls Enterprise Monitor. Yes, a lot of 
people will find it easier to use Nagios or script things, but then 
there are also a lot of people that will find it much easier to pay 
MySQL, to have all these tools ready

The Enterprise value proposition is to: pay money to save time

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

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

Yes

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

Enterprise has this, as well

> - Indemnification: how many customers have actually taken MySQL up on
>   this?

Clearly not enough, or we'd have differentiated just based on this

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

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

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

Popcon isn't accurate, but its a good metric. MySQL is in the top 100 
installed packages, the last time I checked (May, this year)

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)

> 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

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

Where did adaniels mention what you've said?

Incidentally, MySQL has plans to have distribution repositories, so in 
due time, it might just be an apt-get or yum install away

	hope this helps

-- 
Colin Charles, Community Relations Manager, APAC
MySQL AB, Melbourne, Australia, www.mysql.com
Mobile: +614 12 593 292 / Ekiga/Skype/Gizmo: colincharles
Web: http://www.bytebot.net/blog/

MySQL Forge: http://forge.mysql.com/
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