Celebration of forks?

This blog post was inspired by Masood Mortazavi's comment: "OSCon to be somewhat disappointing this year -- many low quality sessions and a celebration of forks"

I did not attend OSCON, even though I live in California. I did not even bother to submit a presentation proposal, even though people who attended my talks at the MySQL Conference and Expo earlier this year and the year before, all greatly enjoyed it. I have even received emails from people suggesting that I present the talks at OSCON, FOSDEM etc. Just to clarify: I have not submitted any proposals, anywhere (except a tentative volunteer at a MySQL Los Angeles Meetup, mostly because it's on the route home that I drive. Note to self: I need to confirm a date).

I must admit that my enthusiasm for MySQL has been on the wane since there has been so little interest in proactively incorporating the work that I have done. I haven't done any hacking on MySQL (or any of its forks) in several months.

Sun/Oracle must fix the mistakes of the past and cannot continue to develop MySQL in the same way that MySQL has been developed for the past 4 years. The development needs to be open and embrace the work that is happening outside of Sun. MySQL first started alienating open-source developers by persevering with using BitKeeper for several years past the point where it should have been abandoned and Sun has continued the alienation by having a closed development process - which left seasoned developers, such as myself, surprised with the MySQL 5.4 announcement.

Open source does not like surprises.

Today, it still seems that "official" development is still very closed. We only see intermittent pushes to the "public" LaunchPad pushes: The 5.4 repository is 3 weeks old; the 5.1 and 5.0 repositories are about 2 weeks old. In the bad-old BitKeeper days, the community can see the repository via bkbits but now, nada.

Sun! Please! Open up the development and interact with the community before the goodwill of the MySQL brand disappears. It is not good enough just to continue as how MySQL AB was handling the development during the last few years before it was acquired: That was broken already. Have all your developers push to public repositories. Make the pushbuild results public. Proactively work to incorporate contributions with the knowledge that the contributors are often not paid to work on MySQL: They are a volunteers with only a small amount of time available.

My regular employment at Google does not involve any MySQL development work. Google does not (and probably never will) use my external stored procedures patch for MySQL, for example. Some of you are probably thinking "Googlers have 20% time": So what? Perhaps I want to spend my "20% time" doing something more fun and productive than continuously merging a patch which will never be pushed? And just whose fork of MySQL am I supposed to develop and contribute to?

Just my 2¢.