<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: MySQL Community Version</title>
	<atom:link href="http://www.pythian.com/news/1142/mysql-community-version/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.pythian.com/news/1142/mysql-community-version/</link>
	<description>News and views from Pythian DBAs</description>
	<lastBuildDate>Fri, 10 Feb 2012 13:01:25 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: Nicklas Westerlund</title>
		<link>http://www.pythian.com/news/1142/mysql-community-version/#comment-246667</link>
		<dc:creator>Nicklas Westerlund</dc:creator>
		<pubDate>Tue, 29 Jul 2008 16:02:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1142/mysql-community-version#comment-246667</guid>
		<description>For what it&#039;s worth, it&#039;s a bit of a double-edged sword.

If I&#039;m a paying customer, I want bug fixes quickly obviously. 
But, I don&#039;t want that on the cost of having to &quot;test&quot; the software for the community users, so I would prefer to see a model where new functionality goes into community first, and when properly verified and tested by the mass, goes into enterprise. Whereas bugfixes go into the enterprise release first.  (Security fixes should go to both)</description>
		<content:encoded><![CDATA[<p>For what it&#8217;s worth, it&#8217;s a bit of a double-edged sword.</p>
<p>If I&#8217;m a paying customer, I want bug fixes quickly obviously.<br />
But, I don&#8217;t want that on the cost of having to &#8220;test&#8221; the software for the community users, so I would prefer to see a model where new functionality goes into community first, and when properly verified and tested by the mass, goes into enterprise. Whereas bugfixes go into the enterprise release first.  (Security fixes should go to both)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Xaprb</title>
		<link>http://www.pythian.com/news/1142/mysql-community-version/#comment-246057</link>
		<dc:creator>Xaprb</dc:creator>
		<pubDate>Mon, 28 Jul 2008 20:40:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1142/mysql-community-version#comment-246057</guid>
		<description>I think your idea is actually the reverse of what I&#039;d want to see.  Enterprise should be an older, less bleeding-edge version of Community.  That&#039;s not the only change I&#039;d like to see of course.</description>
		<content:encoded><![CDATA[<p>I think your idea is actually the reverse of what I&#8217;d want to see.  Enterprise should be an older, less bleeding-edge version of Community.  That&#8217;s not the only change I&#8217;d like to see of course.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lukas</title>
		<link>http://www.pythian.com/news/1142/mysql-community-version/#comment-246021</link>
		<dc:creator>Lukas</dc:creator>
		<pubDate>Mon, 28 Jul 2008 19:27:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1142/mysql-community-version#comment-246021</guid>
		<description>3) should be clarified. There should not necessary be less releases, just less binary releases.

Anyways your proposal makes no sense. Sun/MySQL should get back to doing open source. Right now they do not use the community to find bugs for their Enterprise users, they do not use the community for development (Drizzle is the new path for this I guess). They solely use the community to write apps for them to grow the market opportunities. How this makes business sense is beyond me, especially since MySQL has a serious quality issue, I would be happy to get as many testers for the binaries I ship to my Enterprise customers.</description>
		<content:encoded><![CDATA[<p>3) should be clarified. There should not necessary be less releases, just less binary releases.</p>
<p>Anyways your proposal makes no sense. Sun/MySQL should get back to doing open source. Right now they do not use the community to find bugs for their Enterprise users, they do not use the community for development (Drizzle is the new path for this I guess). They solely use the community to write apps for them to grow the market opportunities. How this makes business sense is beyond me, especially since MySQL has a serious quality issue, I would be happy to get as many testers for the binaries I ship to my Enterprise customers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Marten Mickos</title>
		<link>http://www.pythian.com/news/1142/mysql-community-version/#comment-246018</link>
		<dc:creator>Marten Mickos</dc:creator>
		<pubDate>Mon, 28 Jul 2008 19:20:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1142/mysql-community-version#comment-246018</guid>
		<description>Sheeri,

Thx! We are certainly open to suggestions, and we are not denying that the model isn&#039;t perfect yet. (But it also isn&#039;t entirely wrong, judging from the rapidly growing numbers of subscription customers we have)

Your proposal has been discussed before. Some people say it won&#039;t work because they feel that the Community edition should be *newer* than the Enterprise one, so that paying customers of Enterprise would receive something that the community has already tested.

Every model has its pros and cons, of course. Will be great to see what other comments you get on this blog posting. And thanks again for helping us perfect the model.

Marten</description>
		<content:encoded><![CDATA[<p>Sheeri,</p>
<p>Thx! We are certainly open to suggestions, and we are not denying that the model isn&#8217;t perfect yet. (But it also isn&#8217;t entirely wrong, judging from the rapidly growing numbers of subscription customers we have)</p>
<p>Your proposal has been discussed before. Some people say it won&#8217;t work because they feel that the Community edition should be *newer* than the Enterprise one, so that paying customers of Enterprise would receive something that the community has already tested.</p>
<p>Every model has its pros and cons, of course. Will be great to see what other comments you get on this blog posting. And thanks again for helping us perfect the model.</p>
<p>Marten</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Giuseppe Maxia</title>
		<link>http://www.pythian.com/news/1142/mysql-community-version/#comment-246015</link>
		<dc:creator>Giuseppe Maxia</dc:creator>
		<pubDate>Mon, 28 Jul 2008 19:13:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.pythian.com/blogs/1142/mysql-community-version#comment-246015</guid>
		<description>Sheeri,
Although the official position of my company is different, I am with Baron in thinking that the current split is bad for customers.
(http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/)

IMO, but this is my personal view, we should remove the binary differentiation, and release to the community first, and after some weeks of testing we should recommend the release to paying customers. This is what I was doing as a consultant before joining MySQL, and thus my recommendation to the decision makers is to remove the differentiation at all.

Giuseppe</description>
		<content:encoded><![CDATA[<p>Sheeri,<br />
Although the official position of my company is different, I am with Baron in thinking that the current split is bad for customers.<br />
(<a href="http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/" rel="nofollow">http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/</a>)</p>
<p>IMO, but this is my personal view, we should remove the binary differentiation, and release to the community first, and after some weeks of testing we should recommend the release to paying customers. This is what I was doing as a consultant before joining MySQL, and thus my recommendation to the decision makers is to remove the differentiation at all.</p>
<p>Giuseppe</p>
]]></content:encoded>
	</item>
</channel>
</rss>

