On Tue, Sep 18, 2007 at 05:57:47PM +0200, Colin Charles wrote:
> The Enterprise value proposition is to: pay money to save time
So why persuade those who prefer to invest time to distribute
"inferior" Community version? If they have time and expertise
they're going to just hate your sales/marketing/management --
whoever gets mentioned as coming up with technically dumb ideas
-- but not recommend paying company which took this vector.
For clients, adding matters, not subtracting.
> >- 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?
"Maybe" is weak business case IMO.
> >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
> Not providing any binaries for community users is not a
> scalable solution.
There are different communities of community users probably.
This might be not 100% solution but that's not "non-scalable".
> We have Windows and OS X users to also worry about
Maybe it's their part to worry about paying MySQL AB just as well
as they're paying Microsoft and Apple if there's no-one else to
prepare competent builds for them?
There will always be people who would just cash out to any
problem, whether it's solvable by cash or not, and people who
would rather rely on themselves if at all possible. Trying to
put them in one boat -- _that_ seems like no scalable solution
> And as a company selling support, we cannot tell people to take
> their gripes to distributors first.
But they will. And distributors will often work as the first
line support for no money.
> 24/7 support, with an answer guaranteed in under 30 minutes -
> this is not something a distributor can deliver
I don't need that, for example. And if I do, I would prefer
sticking with distro binaries as long as possible (even if that
means bugging or helping maintainer(s) to bring the build closer
to what MySQL would consider OK).
> >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...
So why should distro packagers *not* use and provide them?
> Incidentally, MySQL has plans to have distribution
> repositories, so in due time, it might just be an apt-get or
> yum install away
This usually fails miserably: vendors just **** hard at providing
distribution support. Much worse than distros at supporting
whatever is getting packaged, usually.
Would be much better to work with distro maintainers and not
spend extra money (were you willing to increase income or
spendings anyways?) for duplicating what they do for themselves.
Our distribution glibc folks have helped with pulling some
MySQL-related changes upstream several years ago IIRC (maybe
Egor Egorov would remember, or I have that archived); MySQL AB
probably isn't going to build packages for ALT Linux, and if they
would, the result would have to comply with our quality policies
which are rather strict in quite a few parts where e.g. RHEL
would happily pass it. sanja@mysql could probably elaborate
We also were talking through considering certification of MySQL
on ALT Linux as "proper build" but first the glibc issues were
being solved (which were mostly attributed to broken MySQL
threading design, and I think rightfully so), then everyone
had enough business by themselves -- we just didn't return
to this with Egor. It was back in 2002 or 2003 IIRC.
You should have learned from other companies who were 100%
proprietary but had to deal with Linux/FLOSS; and your sales
seem to do much harm for not having done their homework on
No time to hate, especially those who could recommend buying
your support -- a year ago with lighter heart than today.
---- WBR, Michael Shigorin <mike@stripped>
------ Linux.Kiev http://www.linux.kiev.ua/