List:Packagers« Previous MessageNext Message »
From:Michael Shigorin Date:September 18 2007 5:16pm
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:
> 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
> >support.
> 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
to me.

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

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

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