So, I’ve been involved in the Drizzle project for about five weeks now. Brian told me about a month and a half ago what the project was about when we were speaking on the phone about something unrelated. The project piqued my interest in a number of ways, and the direction Brian wanted to take drizzle — to be a pluggable database server microkernel (nano-kernel as Mark Callaghan calls it 🙂 ) — was something I have been harping on internally at MySQL for over two years.

In addition to seeing eye-to-eye with Brian on a vision for the server kernel, I saw in drizzle the opportunity to create a real contributor community around a MySQL-derived project. Note, I say project, not product. Drizzle is a research project, not a marketable product. Do I eventually see people making money off drizzle? No. Do I eventually see people and companies making money from products build around drizzle? Yes. But that’s a long way away yet. The serious and difficult work of refactoring a crap-ton of code (to borrow Monty Taylor’s phrase) must first be done before the interfaces into the server kernel stabilize enough for plugin developers to be successful.

So, some readers may note that “long way away” is a vague term. Yes, it’s a deliberately vague term. Why? Because drizzle is not a marketable product, we aren’t under any artificial time-lines as to when certain things or features will be done. The goal of the drizzle developer team is to get back to the open source development methodology of releasing early and releasing often. And, of course, getting as much community input and feedback about the code.

What we are not interested in is adding features into the core microkernel that are only used by a very small subset of users. Those features belong in plugins or external tools and extension points will be added to allow features to be built as modules around the core server kernel. This is why the development up until this week on drizzle has been mostly about removing code, and not necessarily adding code.

This situation — of removing code versus adding/modifying code — is now changing. 85% of the removal phase has been completed, and those who follow the drizzle trunk commits will have started noticing this week patches which start to make drizzle look quite a bit different from MySQL. Some of this work is refactoring, standardization and cleanup work, for instance getting rid of custom types like my_bool. Other stuff is more radical, like ripping out the existing MySQL socket interface and de-coupling a thread from the massive THD class. For those who say that drizzle is just MySQL with stuff removed, I beg you to actually look at the code going into trunk now, and look at the differences already between the way the THD class is handled by the scheduler…

I plan to write weekly blog post series called “This Week in the Drizzle Branches” which outline the work done by the various parties contributing to Drizzle, in an effort to summarize development for those who don’t have the time to follow commit lists!

And speaking of contributors…I have been encouraged to see the enthusiasm generated by the Drizzle announcement at OSCON. I have been eager to meet and greet those of you who have joined us on Freenode #drizzle and my heart has been warmed by the outpouring of feedback and suggestions from the community. This is how open source development works and how it thrives. My hope is that the lessons we learn working on Drizzle can be ported to the MySQL development process, which has been making excellent steps in opening up, but still has a ways to go.

OK, I’m off for now…look for a blog post shortly about how the Drizzle community is using Launchpad.net and its platform services. 🙂

Hmmm, also on the docket for this week…getting off s9y and onto Habari. I’ve been delaying that way too long.