But last month, when Aker announced the general availability of his fork, Drizzle, it looked like the decision he made in 2008 was nothing short of brilliant, given that MySQL has now ended up in the clutches of Oracle, a company that does not seem overly friendly to free and open source software.
Forks of free and open source software can sometimes become better known and more widely used than the original branch. More often, they die away or are taken up only by niche markets.
Hence, one figured that it would be interesting to ask Aker something about what looks being a fortuitous occurrence.
Sadly, the man himself was not contactable but senior Drizzle developer Stewart Smith (pic below), a former president of Linux Australia, and a longtime FOSS hacker, was more than willing to speak for the project. Smith currently works for Rackspace and was formerly an employee of MySQL and then Sun.
iTWire: When did the fork from MySQL take place?
Stewart Smith: Brian started a tree around June 2008, although ideas had been floating around for a while beforehand (we typically say this traces back to the 2005 MySQL Customer Advisory Board meeting).
The first commit to the source tree was 2008-06-24, aptly with the commit message "clean slate". It was a couple of days later, on the 29th that my first set of patches were merged into the tree.
At first it was just a few of us, working on it after hours, until the public announcement at OSCON.
Why did the fork happen?
A number of reasons. We saw a couple of problems: 1) the new features in MySQL 5.0 weren't really applicable to large scale websites, a traditional stronghold and 2) the code base was aging and in desperate need of large scale refactoring.
It boils down to a number of people thinking that we could build a better database for large scale web and cloud applications than what we currently had.
With hindsight, it looks like a very wise decision. How did it look at the time?
I thought it was a great idea at the time too. Forking the project is not always met with a positive reaction, it was certainly a different and bold step to take. To their immense credit, Sun saw the potential that Drizzle had and provided a great place for a number of us to work on it.
Aker gave a talk about Drizzle at the LCA in 2009. At what stage was the project at that time?
It was at a less mature state than it is now. We still had features to implement and bugs to find and fix. We now have a stable release. I'll never use the phrase "production ready" as the only way you can prove that is by having *other* people running it in production for a decent time and loudly saying so.
That being said, there have been people deploying Drizzle into production environments pretty much since the start.
What are the strengths of Drizzle when compared to Monty's Maria DB? And when compared to PostgreSQL?
We each focus on different things. Within the Drizzle community we're very much about using the right tool for the right job.
Drizzle is aiming for being the database optimized for cloud and web applications. This means we make different decisions. If there is a choice between optimising for 32 concurrent connections or optimising for 1024 concurrent connections, we choose the 1024 route. We need to be pluggable, fitting into infrastructure, not dictating it.
MariaDB aims for full backwards compatibility with MySQL. Drizzle doesn't. We've taken the direction of removing features that don't work well in large scale web/cloud environments. We've also changed the way various things operate, to help prevent users from making mistakes or entering in invalid data (that was valid in MySQL).
PostgreSQL also solves a different set of problems than Drizzle does. Some application architectures are much more suited to PostgreSQL than others. It is certainly more Oracle-like than MySQL-like - and that works brilliantly for some people and some applications. We get on really well with PostgreSQL people (and indeed view many as friends).
Looking ahead, what are the milestones that are planned?
Some exciting things that have been worked on recently:
Multi-sourced replication, where a database server can apply changes from several different servers. This allows you to do multi-master replication topologies, which some people are quite eager to have.
Recently we merged in Percona's xtrabackup tool and now Drizzle is the first in the MySQL family to ship with an online backup tool that isn't just a SQL dump.
I'm also working on CATALOG support, a feature that will enable true database level multitenancy (essential for the delivery of good and efficient database-as-a-service).
How many people are involved in hacking on Drizzle and what kind of geographical spread do they have?
We've consistently had over 20 different people committing code each month and around 1000 commits. In total, I think we've had about 80 unique code contributors to the project. This doesn't count people who've helped with various bits of infrastructure (for example, build machines, website).
We also have an active community giving feedback about various design decisions, which can be invaluable to get from people who spend their entire lives managing database systems.
I'm pretty sure we're missing Antarctica in places that contributions have come from!
Do you have a business model for the project or is a community project that hopes to live on donations?
We've always wanted it to be possible for people to build businesses around Drizzle. Companies that have sponsored development have done so because they've seen value to their company through investing in the technology.
We're currently seeing interest from several companies in offering support and services around Drizzle. A healthy ecosystem around the project is very healthy for it. We would like Drizzle to be much like the Linux kernel where it is not controlled by one company and is not purely an army of volunteers.
I expect there to be some very interesting announcements next week at the MySQL User Conference and Expo.