Videos of the sessions from Drupal Camp London have started to appear on YouTube including some vox-pops style interviews from attendees. In this short interview [YouTube], MySQL co founder David Axmark gives a warning to the Drupal community.

David makes a couple of observations about Drupal, drawing parallels between it and MySQL. After saying that most of the money made by MySQL was with small companies using MySQL for consulting, projects, and building websites, he says:

"you have LOTS of companies building Drupal websites, they are the base bone of the Drupal community, it's not the big guys."

He later compliments Drupal's innovation, and comments on the policy of not requiring backward compatibility:

"The Drupal thing with not being backward compatible, is an absolute pain for people who need to upgrade, but it also ensures innovation… if you have to be backward compatible for a very long time … what you can do gets more and more limited and Drupal not having to be backward compatible allows for more innovation, which is why Drupal is where it is."

David's totally right, and there's much more to it than this. The lack of backward compatibility allows each version of Drupal core to make huge advances. This is a pain for people upgrading, but it has other consequences as well. Remember the slow uptake of Drupal 6? With Drupal 6 it took contrib modules a long time to catch up, and because you needed key contrib modules to do anything useful there was a long lag between a stable D6 and widespread adoption in the Drupal community. This was improved in D7 because it removed the dependency on CCK by moving fields into core, and will again be improved by moving lots of useful stuff from contrib into Drupal 8 core (including Views). In addition to this, with each new version, developers, site builders, and themers have to learn new ways of working. But, that's a small price to pay for the innovation and improvements it allows, and as David says, it's "why Drupal is where it is" today.

Later on he is asked if there is anything he would have done differently if he were to do MySQL from the beginning again:

"we developed things [enterprise users] asked for, stored procedures, triggers, views, stuff which databases had for decades at that point, which almost no website ever used. the alternative of course would have been to develop it for the web users which would mean lots of simple queries, faster, and … oh … nosql. so if we'd have developed that way the big rush for nosqls might never have happened. but the question is we couldn't figure out how to make money of it, and the people who paid us money wanted different features so. but we basically developed things that our biggest group of users didn't want…"

There's a hint of humour in David's voice as he says this, and he prefaced it with "I'm not even sure if I'd do this, but it would be interesting to think about", but it's clear he thinks developing the features that the big enterprise clients wanted prevented them from innovating and developing cutting edge features that would have helped their biggest user base. Perhaps there would have been no need for MongoDB, if MySQL had innovated and introduced these features?

So where is the message for the Drupal community in this? We all look forward to Drupal 8 later this year, which is in many ways a big departure from Drupal 7. There are some big innovations, and there are features that will support Drupal's further adoption by enterprise.

How far down the enterprise route do we have to go before backwards compatibility becomes an issue? Is it inevitable that Drupal's innovation would have to slow to allow for this?

I certainly hope not. I look forward to the challenges, and the learning, that each new version of Drupal core brings. I enjoy working on large projects, with the challenges that brings. But, let's not forget, as David says, it's lots of small companies that make up "the base bone of the Drupal community, it's not the big guys."

If Drupal was to become the big, reliable, MySQL of the web CMS world, what opportunities does that bring? And, what would the equivalent of nimble, innovative MongoDB be in that picture?