Posted on 1 Comment

MySQL projects on launchpad, sourceforge, google code and forge.mysql.com

While doing some work for the MySQL MMM project, I got distracted and browsed around for a bit. I started searching for MySQL on google code, and then expanded that search into launchpad, sourceforge and of course forge.mysql.com.
I found that there are literally thousands of FOSS MySQL projects on these sites. No surprise really, but still not something we stop to think about every day.
I thought I would share that with you here so you can go and have a look for yourself to see if you see anything that might be useful to you. Of course if you do, please blog about it so we can all benefit from it.

DISCLAIMER: many of these projects are in development, it depends on the project really. Before you go off and use a new tool you have never heard of in production, make sure to test it properly beforehand.
Finding out some tool doesn’t work as advertised on a production system is pretty nasty.

Posted on 1 Comment
Posted on

Modular vs Integrated

There’s actually no single “correct” answer! It all depends on

  1. where in a stack the component lives;
  2. the state of the market for that component region;
  3. sometimes even geographic location of the user comes into play.

Yes, for OSS projects modularity is handy in terms of handling contributions, but modularity may not be the best way to deal with a problem in a certain market state and situation!

Research has shown (see, for example, “The Innovator’s Solution” by Clayton Christensen) that the “integrated” region over time actually shifts to a subcomponent of an original integrated component that has since gone modular. An interesting example of this for MySQL its pluggable storage engine interface since version 5.1. MySQL is more modular now, but individual storage engines are tightly integrated for performance reasons, and in some cases they are even proprietary. It’s important to realise that this too is just a phase and not a final state.

But sticking with OSS for this story, distributed version control with (among other things) decent branching/merging make contributions to the core are entirely feasible and even easy. It’s a matter of using a toolchain that supports the most suitable work process, rather than hinder it or force another unsuitable wok process. Good distributed version control systems: bzr (Bazaar), hg (Mercurial), git.

(note: svn/subversion, even with some “distributed” hacks on top of it, does *not* qualify as it’s architecturally unsuitable. The other tools have excellent migration plugins available to get your work process -and your code- out of svn hell. It’s a bit of work but can be a stepwise process to unwarp your work processes and get a sane and more productive development workflow.)

At Open Query we particularly like bzr, because with Launchpad it provides an excellent environment for tracking of bugs, features and ongoing work, merge reviews, and so on. The admin side of Launchpad has some user interface issues, but it is workable.

Sometimes the core of a particular component does need fixing – but the time may not be right for modularity, and it’s important to not get distracted by that geeky desire of “everything modular” as swimming against market forces can be very painful.

Posted on