MySQL 5.1 and development models

The MySQL development team decided to celebrate the (US) Thanksgiving holiday with the release of MySQL 5.1.30, the first "general availability" (read "production-ready") release in the 5.1 series. There is a lot of good stuff in 5.1.30, including table partitioning, row-based replication, a new plugin API, a built-in job scheduler, and more; see the nutshell summary for more information. It's a celebration point for a long development series; the MySQL developers are to be congratulated for what they have accomplished with this release.

Behind the celebration, though, one can hear the grumbling from unhappy developers and users. This release has been a long time in coming; the first 5.0 GA release was in October, 2005 - just over three years ago. The first 5.1 release candidate (5.1.22) came out in September, 2007; seven more "release candidates," many with major changes, were announced over the following 14 months. So the 5.1 production release came rather later than desired, but some developers feel that it was still to soon; the complaints reached a climax in this lengthy posting from Michael "Monty" Widenius, the original creator of MySQL. His point of view, in short, is that this release has fatal bugs, and that these bugs come from a number of flaws in how MySQL development is managed.

Your editor cannot claim to be an expert on the MySQL development community. But Monty, presumably, is an expert on this community, so his observations have a higher than usual likelihood of reflecting something close to reality. Reading various dissenting posts (example) has done little to make your editor feel otherwise. And, in any case, much of what Monty says rings true when compared against experiences from elsewhere in the free software community. As projects grow, they must occasionally revisit their development models. There is little happening here which is truly unique to MySQL.

Monty asserts:

Two things jump out of that statement. One is that MySQL apparently suffers from an inadequate testing community. Needless to say, that is not a problem which is unique to this project; testing is a scarce resource throughout our community. MySQL users who are unhappy with the results of the development process might want to ask themselves if they are doing enough to help with the testing process. Like it or not, testing software and finding bugs is one of the costs of "free" (beer) software. If this testing doesn't happen during the development cycle, it will end up happening with the "stable" releases instead.

The other attention-getter above is the statement that MySQL developers have been unable to make major changes since early 2006. One need only think back to the 2.4 kernel days to see the kind of damage that can result from pent up "patch pressure." Developers get frustrated, major changes start to find their way into "release candidate" code, and the number of bugs tends to increase. The existence of a separate MySQL 6 development branch helps, perhaps, in reducing patch pressure, but it can also only serve to distract developers from stabilizing current release candidates.

Related to this is another assertion:

Review would appear to be a big part of the problem in general. It may well be that a failure of review has caused the introduction of new bugs with fixes. But one could argue that the problem is deeper than that: any code which failed to stabilize over fourteen months of release candidates should, almost certainly, never have been merged into the MySQL trunk to begin with. It seems that there are not enough eyeballs being applied to major new features before they go in.

Your editor has resisted the temptation to make comparisons with other relational database manager projects, but there is value in comparing this state of affairs with the review problems faced by PostgreSQL in recent years. An inability to get additions to PostgreSQL properly reviewed resulted in those additions not being merged. That, in turn, leads to delayed releases with fewer than the desired number of features, neither of which is particularly pleasing for users or developers. But, on the other hand, PostgreSQL does not appear to have the same kind of trouble stabilizing its major releases.

Perhaps the key point to take away from all of this, though, is here:

MySQL is very much a corporate-owned, corporate-driven project, and it has been for a long time. Decisions on what to include are made internally; there is little discussion of development decisions on the project's mailing lists. It is hard to find information on how to contribute to the project; some of the available information still tells prospective contributors to use BitKeeper. All code is copyrighted by MySQL (now Sun), which reserves (and uses) a right to distribute that code under proprietary licenses.

All of the above reflects an arrangement which has worked well for years, and which has produced an immensely valuable database manager used by vast numbers of people. But it is not a community project, so development decisions will not necessarily reflect the best interests of the wider user or developer communities. If, as Monty suggests, those decisions are made in ways which favor features and deadlines over quality, there will be little that the community can do about it.

---

(Log in to post comments)