Search This Blog

25 July 2009

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¢.

2 comments:

Eric Bergen said...

We've been banging the open development drum for years now. It's mostly fallen of deaf ears until recently. It seems like the tide is turning slowly with enterprise and community being reunited. I hope that the success of the drizzle model will serve as an example for future mysql development.

Entry 23 Eco of Kristofer said...

How can you _not_ predict the evolution of MySQL?

The core product is a (boring day-to-day) engineering work to satisfy customer needs, and it is exactly what you will expect from a successful and price-worthy investment. Development is a mutagen and it will not always increase income. Predictability will however as long as you're in the market window.

However, because of the market shifts towards "clouds" and because of the relative cost of maintenance I think that the predictability has become an issue (rather than the opposite).

It is very good that MySQL finally seeds some forks so that the magic of genetic algorithms will bootstrap us into the future.