Why Drizzle Will Succeed

Posted in: MySQL, Technical Track

I have not said much about Drizzle here; that is because there is not much to say. It is premature, really, to say anything about it at this point. Some have said they will support Drizzle; as Pythian supports several database systems, it is very likely that we will support Drizzle as well. Particularly since there is in-house Drizzle expertise already. But I digress; my point is that it is premature to really say much about Drizzle.

My involvement in Drizzle goes back to around the end of April/beginning of May 2008. Given my early involvement, I have seen much of what was discussed, at least that which was on the mailing list and I was included on (I am sure there were many discussions I was not, and am not privvy to). While Brian has done a lot of work, there’s plenty of work being done by other people, and while it started out as Brian’s idea (most likely with Mark Atwood’s opinion and support)…..well, it’s beyond the scope of just one person right now.

Through it all, I have been amazed at the humility of the main developers on the list. And I believe that this is what will lead Drizzle to success, and that deviations from this may very well be Drizzle’s demise.

During an OSCon panel entitled “Does Open Source Really Need To Be Organic?” Brian stated (in the video, this starts at 20:07, ADDED: audio of the quote so you can hear it straight from the horse’s mouth):

You know, there’s a misconception in the open source developer community about what “commit access” means. People seem to think that “commit access” is this great badge that allows them to just push feature after feature after feature with no control. Where really the model should be, instead, that “commit access” actually means you’re a worker bee. It should be drudgery work.

You’re the garbage man.

And that’s really what it means to actually commit code if you’ve actually got it in your head correctly. It does not mean a free will to push features, it means that you’re the garbage man and you collect everything, you sort everything, you make it all happen. And that is something that is [pause] I still think that many individuals in the open source community don’t understand.

There are a handful of folks (I believe the count is at 3, but it may be more at this point, like 5-6) who have commit access. And from the discussions I’ve seen back and forth, the folks with commit access really are taking the opportunity to teach and learn from other developers. Though my involvement at this point is very small, I am very proud to be a part of a community of IT folks who actually believe in humility, and do not hold that their opinion is The One True Way.

(Perhaps MySQL started out this way, and if that’s the case, here’s hoping Drizzle takes a different path.)


Interested in working with Sheeri? Schedule a tech call.

2 Comments. Leave new

I wholeheartedly agree re commit access. As a former maintainer for Gentoo Linux, I had commit access to the entire portage tree. Sure, there was a sense of elite power, but that lasted all of maybe 1 week. Once you start having to deal with upstream changes and user-submitted patches and maintaining stable vs unstable versions, it becomes a chore. You quickly become the servant more than the master of the project.

At least, that is how I saw my role progressing.


Hehe, as one of the ones with commit access, I couldn’t agree with you and Brian more. The *only* times I have committed to trunk is to merge other people’s code after merging and build/testing locally. Commits to trunk should only be that: merges from developer branches (Brian? ;) ). It *is* drudgery work, but it’s absolutely necessary to keep commits to trunk to a minimum. Development happens in branches outside of trunk and trunk is merely the merging of development outside trunk into trunk once a branches’ code tests and builds cleanly…



Leave a Reply

Your email address will not be published. Required fields are marked *