As I mentioned before, it seems that thanks to Git and Bzr introducing distributed version control workflows, the open source community is now living in a phase where forking is easy and happens frequently - referred to by Brian Aker as the Cambrian Explosion of open source. We certainly see that happening in the MySQL Community.

Assuming you have the competence and know your way around a codebase, forking a proper open source project isn't that hard. You create your own project on GitHub or Launchpad and copy the source code. 1 But one thing you need to do is to change to using the new name (Drizzle, Percona, MariaDB, MepSQL....). Typically you want to keep using the original command line and file names (mysql, mysqld_safe, libmysql...), yet the product name as it appears in your installation packages is changed to distinguish it from the parent project.

In the life of an open source project a name change is a relatively rare occurrence. Most projects never fork or change their name. So it is not surprising that all the tools and methods we use while programming assume that the product name is a constant. It turns out it is hardwired into build scripts here and there. Sometimes excessively: when building DEB files the word "mysql" is used over a hundred different times!

• 1As noted in previous posts, if everything isn't fully open source, which is the case with MySQL, you have a challenge in reproducing from scratch the missing parts, like documentation, build system, etc...

This is the third post in a series about developing the MepSQL build system. In the previous posts we chose BuildBot running in the Amazon EC2 cloud. In this post we actually get a closer look at how the packages are being built (to be followed by even closer looks in later posts :-)

One of the things missing when you fork MySQL is the build system. (The other main missing component being the manual.) It is possible for anyone to compile MySQL from source, but the actual build system (scripts, testing, etc) used by MySQL itself is not public. The same is true for the automated testing. MariaDB uses the open source tool called BuildBot for both of these tasks - in this post we are mainly concerned about the building of packages. Actually, we are mainly concerned with BuildBot itself and the details about building packages is saved for a later post. I will document both the MariaDB system and the MepSQL system which was derived from that.

This is the first part of many posts in a series of blog posts where I want to document how the MepSQL packages were built. By doing that, I will also end up covering the MariaDB build system (which this is based on), some of BuildBot, Amazon EC2 cloud and packaging DEBs and RPMs just in general, so it could be interesting from many perspectives. In this first part I'll simply scribble some notes about reviewing the OpenSuse Build System, Launchpad PPA service vs using your own servers and automating the builds with BuildBot.

Originally I just wanted to work on some new ideas on the automated build and QA system used by MariaDB. But since leaving Monty Program I didn't have access to any of those servers anymore, so as a first step I had to look into what alternatives there are for building binary packages for many operating systems and hardware platforms. In fact, this was another thing I had wanted to learn more about for a while. For instance Michal Hrušecký uses OpenSuse Build Service to build both MySQL and MariaDB packages for all RPM based distributions in the blink of an eye - I was interested to find out what's behind that magic.

Some time ago Stephen O'Grady and Brian Aker had an interesting Blogo-dialogue about what they call the "Cambrian Explosion" of open source development. The Cambrian Explosion means that we increasingly see forks of projects being developed in different directions, where traditionally we are used to open source development happening in relatively hierarchical and easy to follow upstream and downstream relationships. This is exactly what happens in the MySQL community currently, where in total there is more progress than ever before, but that progress is divided among several competing forks, none of which is strictly in an upstream-downstream hierarchy with each other.

I used to be a bit frustrated about this state of affairs, believing that if at least most of the forks could co-operate on a common tree, we would see even faster progress. But when I left MariaDB some months ago, I realized that the situation is what it is and since all existing MySQL variants are associated with a commercial vendor, there wasn't an obvious choice for me to continue contributing, which I still want to do. So I thought I might as well embrace this Cambrian Explosion thing and just publish my own fork as a contribution to the community.

And this is where I today announce the new MepSQL project and the immediate availability of MepSQL 5.1.52-alpha1.

Last week I finally uploaded to Drupal.org the Vineyard theme - ie the theme I created and use for openlife.cc. Releasing the theme as open source is something I always planned of doing, but never really got round to it. I'm especially proud of the fact the theme looks different than most Drupal themes I've seen, so I hope others can use this as a basis for creating nice sites.

It seems last week was a popular weekend for programming hobby projects, as it wasn't only me who was having fun with some recreative programming. Yesterday I published a new version of my Footnotes module for Drupal.

I was sitting in a train in the middle of rainy Ireland when I received a mail that Nokia has bought Symbian and is releasing it as Open Source. I didn't believe a word of it. But the web was full of news about it, so it was true. This is an amazing turn of events that I didn't anticipate at all. (You may or may not know that in my previous job I was heavily involved with Symbian programming. Ironically, one reason I left just 6 months ago is that I wanted to work in an Open Source environment :-)

I was wrong in my last post, it seems that all Sun database developers are now part of the same organisation, including PostgreSQL's Josh Berkus.

MySQL has the pluggable storage engine architecture, which is unique in the industry. The idea is you pick from among a suite of storage engines the most suitable one. PostgreSQL on the other hand has a plugin architecture for programming languages you can then use for stored procedures. And the cool thing about Open Source...

Someone went as far as to implement a PostgreSQL plugin of LOLCODE, a funny programming language I didn't know about until recently. So now you could do this with PostgreSQL: