From: Michael Shigorin Date: September 18 2007 5:16pm Subject: Re: Distro packaging decisions and the non-public Enterprise source List-Archive: http://lists.mysql.com/packagers/351 Message-Id: <20070918171602.GG13893@osdn.org.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 ------ Linux.Kiev http://www.linux.kiev.ua/