The development model for MySQL Enterprise took a big step forward with the
new community process Karen Padir announced in her Tuesday keynote. This is
great for both the open source server as well as enterprise customers, because
the closer the tie between the community and the development path, the better
the quality and faster the progress towards new functionality. I'm not entirely
sure everyone at Sun still completely understands why a working community
process is a benefit for the enterprise customer base, but I'm happy steps are
made in the right direction, and it seems to me that
Karen Padir is going to be a good leader for the product.
A big improvement, for sure, and still there's more to improve here. To
borrow the words of
Baron Schwartz, MySQL currently "has" a community, while it would really be
in everyone's benefit if instead MySQL would "be" a community. I would suggest
that the goal should be not monthly "community" releases from Sun, but a
completely out-in-the-open development process with the community members being
on the driving seat regarding patch acceptance, quality management and
releases, much like the Fedora process works. Sure, there's a role for
corporate sponsorship and project management, but it's a distinct difference of
responsibility. The Drizzle project is another good example of how this can
work. An important point to realize here is that there is a difference between
the community, an active partner in the process of making the software better,
and the unpaid userbase. The latter is an acquisition and conversion vehicle
for the former, but they're separate entities.
The announcement of the 5.4 server was at the same time an encouraging as
well as confusing example of the changes. I would like to be enthuastic about
it, but we've seen MySQL (if not Sun) announce pre-announce releases that
didn't appear before, and it's a long way to the promised release time. I asked
two questions from many, many MySQL staff members during the week: why is it
that 5.4 was announced now, but is slated to be released GA only in
December when it clearly demonstrates massive scalability improvements
already, and why is it that the feature list for the final 5.4 release is
much longer than what's already completed? I did not get a really coherent
answer from anyone. Best I could decipher, there is somewhere a faceless
"marketing" which decided that a) there should only be one release announced
and b) 40% demonstrated improvement is not good enough when it's not the only
improvement that can be made. I also learned that it's not unlikely that much
of the work which has gone to 5.4.0-beta would be backported to the 5.1 branch
and released in a 5.1 point release before the actual 5.4 release, because in
fact they can be considered bugfixes.
I consider myself not an entirely unexperienced in the decision processes
for release management, and know intimately the clarity hindsight provides to
well-intentioned choices made with best available information. I know there are
many areas to consider, and every decision made is a compromise. I still can't
bring myself to completely understand what exactly led to this particular
approach. Lets recap:
- Improvements already made are announced and made available in beta test
form, but beta does not contain everything planned for the release
- Final release is intentionally delayed by 7 months adding significant
project risk to it, despite having no previously committed release
schedule
- Former release version is planned to by improved by making significant
performance-altering changes in a point release in order to offset the
delay
- Such a release adds risk to maintenance roadmap and steals away upgrade
motivation from the upcoming version
How this plan serves either Sun, the community, the free userbase or the
enterprise customers is a mystery to me. It would certainly seem far simpler
and clearer to take an aggressive quality assurance and release testing
position with the intent to push 5.4 out as a rock-solid replacement upgrade to
5.1 as soon as possible, and only then continue with further updates as a 5.5
release. This would definitely be welcomed by everyone but the class of
enterprise customers who like to hear about future versions two years in
advance - but keep in mind that such conservative enterprises are not MySQL's
primary customer base anyway, and if MySQL is to make inroads there, rapidly
improving the quality and performance of the product in the meantime would
still be a sensible step.
There is the argument that if I want to get those performance features now,
I can use
Percona/XtraDB or MySQL 5.1 plus the InnoDB
Plugin. While technically that route does work, and clearly is worth
pursuing as a user, it does have its drawbacks in terms of requiring multiple
sources and it's hard to see how it supports MySQL/Sun's commercial interests,
the latter surely having been a consideration in the 5.4 release plans.
Thus far in the argument I have ignored one new component - Oracle. That's
because to my understanding the process I've discussed did not consider the
acquisition, which was unknown to most people before Monday. Clearly this
changes a few points. It's not necessarily in the interests of Oracle for MySQL
to continue making inroads to enterprise customers, though if someone's going
to be cannibalizing Oracle's database sales, it might as well be Oracle. InnoDB
Plugin will also be a product from the same company as MySQL Server in the near
future - in fact, in a future likely to be fact before the final GA release of
MySQL 5.4. What is the role of a delayed 5.4 release in this equation,
then?
