The two key questions I brought to the MySQL conference this year, and laid out in my first blog for the conference, concerned the future course of MySQL in an environment with:
- Many new and intriguing alternatives to relational databases (NoSQL)
- Multiple versions of MySQL itself (MariaDB and Drizzle)
The most complete--and most positive-minded--answer to these came on Wednesday night from Monty Widenius, the creator of MySQL and current head of a company called the Monty Project, which maintains MariaDB. Monty said he has always respected other open source projects, and respects the NoSQL work now. He claims that the majority of relational database users find some NoSQL projects interesting and are open to trying them, whereas the people using the NoSQL tools still see the value of relational databases. Only a few trolls try to create enmity and promote one project by denigrating others. (This attitude is echoed by Brian Aker, creator of Drizzle, who talks of an ideal he calls "SomeSQL.")
Monty got furious shortly after the Sun purchase of MySQL AB because Sun, which had previously thrown a lot of support toward PostgreSQL and hired developers to work on it, suddenly forced all the PostgreSQL coders to leave the company. Monty had always maintained pleasant relations with the PostgreSQL leaders and had looked forward to an intense dialog between PostgreSQL developers and MySQL developers within Sun, which he thought would be been a good learning experience and would have let each database port good ideas from the other.
A database, after all, is just a place for data. You can make it fancy with cross-linking and even stick in stored procedures, but it remains a passive repository that takes on value only as a part of a surrounding environment for processing. There are more tools for manipulating data than ever. The various solutions called as NoSQL have value in their own right and in conjunction with MySQL.
Uniting and dividing
I started this blog with a "let's all get along" message, which the main MySQL developers carry through with Monty Program, the Drizzle community, and Percona developers. But forking still has consequences on the community. If you want to improve MySQL, you have to choose which project to support. If you want to support more than one, you have to divide your time.
The dilemma was obvious on Wednesday morning, when all three keynoters--Brian Aker for Drizzle, Monty for MariaDB, and Sheeri Cabral for the Oracle MySQL code base--stressed the importance of community and appealed directly for code contributions.
(Appropriately, Thursday keynotes featured Jono Bacon, Ubuntu community leader and author of O'Reilly's Art of Community.)
I asked a Monty Program employee how many of their contributions come from outside the company, and he estimated 5 to 10 percent. (Naturally, any estimate like this is totally crude and subjective. There's no objective way to measure the size or importance of each contribution.) While it sounds small, I think 5 to 10 percent is actually pretty cool. It's like a conventional company getting a 5 to 10 percent discount on their supplies--and what finance department wouldn't find that a big boost? Still, MariaDB is far from being a community project.
Monocultures are dangerous and diversity is strength, but all these projects are going to have to increase the sizes of their communities in order to be put on a firmer footing. But there are a lot of benefits to open source and community-building that take time to develop, of course. One of the main outside contributions to MariaDB came from a student at a Google Summer of Code, and that person may well use that learning experience to benefit MariaDB and many other projects in the future.
Zmanda, an open source company that handles backups and has a long history of support for MySQL, shows the value of openness in ways that go beyond opening code. I talked to Chander Kant, CEO, who emphasized that they avoided choosing the odd, unintuitive formats for backup images that many other tools create. Instead, they simply create a standard tar or ZIP file containing all the files that they user requests to be backed up.
Then comes a cool trick: the first block contains operating-system commands to unpack the tar file. As long as one can read the first block, one can restore the backup. Finally, the collection is compressed using a standard compression algorithm (GNU zip). Kant says the use of long-standing formats (tar and ZIP) along with the inclusion of the commands means it's pretty likely that a user will always be able to find tools to unpack a backup, even decades from now, and even without access to any Zmanda software or documentation.
With this straightforward use of common tools and formats, Zmanda can back up databases, applications, or filesystems from physical or virtual environments, with no vendor lock-in on customer data. They now even provide a cloud backup service.
A successful conference
Over 1400 people registered for the conference this year, and another 200 viewed parts of it streaming online. I find this a very comfortable size. The conference is big enough that I find interesting new people at every turn. But it's small enough that I can find my friends just by walking around and can find time talk to everyone I want.
I mentioned in my opening blog that I found the tutorials very sophisticated. Because I was busy doing video interviews and trying to strike deals this year, I went to fewer sessions than usual but found them valuable too.
Maybe (or maybe not) the quality of the attendees is indicated by a story I heard from Arjen Lentz, who co-authored O'Reilly's High Performance MySQL and started the support company Open Query. He decided at the start not to do fire-fighting, but instead to teach clients how to keep their systems in good shape so fire-fighting isn't necessary.
I don't believe that attitude is as widespread in the Silicon Valley or larger development community as it should be. (I may be daunted by horror stories I heard from a friend who's a QA engineer, who has to work twice as hard as she should because nobody keeps her informed, and who never receives credit for her efforts because nobody understood they were needed in the first place.) But here at the MySQL conference, Arjen was impressed with how many people got the point, and how many leads he developed.
But most persuasive, for me, was the sense of necessity I heard from attendees. Several told me they don't travel much but felt it would be important to come long distances and cross oceans to get to the MySQL Conference. And now they're glad they came.