Gallery

Is forking good for open-source software?

Posted on 26 Aug 2009 at 12:07

Simon Brock debates the pros and cons of open-source projects splitting off in different directions

Forking’s been a hot topic of conversation in the open-source community for the past couple of months. It’s the process by which a group of developers choose to take a project in a different direction from the original project.

For example, Ethan Galstad, the author of Nagios, has written a number of articles defending people’s right to fork a project while not being completely happy that it’s happened.

The Icinga project has decided to fork away from Nagios. MySQL seems to have been forked in a number of different ways including MariaDB and Drizzle. MariaDB is interesting because it was founded by Michael “Monty” Widenius, who was one of the original creators of MySQL. Drizzle is also interesting, because it’s about cutting down MySQL into a smaller form – to some extent returning MySQL to its roots on the web and removing some of the “big database” functions it’s picked up over the last few years to make it more attractive to corporate users.

Forking has allowed projects that were stalled to go on to bigger and better things

Forking can be good, and in many cases has allowed projects that were stalled to go on to bigger and better things. In some cases, the new project has actually been eventually folded back into and replaced the original project, the most notable being the GNU C Compiler (gcc), which was forked as the EGCS project and then folded back in.

However, forking can also be a bad thing as it may lead to a dilution of the effort that’s going into a particular project. Suddenly a project that was created for the benefit of “all” no longer does that, and any changes only benefit users of that particular fork of the product. This seems to be the case with Nagios, where the fork could have been established within Nagios rather than outside it. Looking from the outside in, it seems that this didn’t happen, but might happen later.

MySQL split

The MySQL cases are more interesting, and probably more worrying. MySQL hasn’t had an easy few years. First there were rumours that Oracle was trying to buy it, then Oracle went off and bought the companies behind the BDB and InnoDB storage engines instead (InnoDB is a key component of many MySQL installations).

After that Sun did buy MySQL, but it seemed a marriage made very far from heaven. Key people left and when a new release of MySQL did emerge (version 5.1), its quality was criticised both inside and outside MySQL. For our own part, we did upgrade to 5.1, only to discover that some parts didn’t work even though they’d been documented as features for almost two years.

MySQL responded to the criticism and talked about going back to its old policy of releasing quickly and often. It also brought out a fork of its own – the 5.4 release – which was designed for machines with multiple cores using InnoDB. And as the final twist, Oracle has now bought Sun.

Does all this matter to the many users of MySQL? The concern has to be that MySQL may have lost momentum. Many small users of MySQL would probably be happy with the facilities of 4.1 rather than 5.x or even 6.x, and so will continue to use and upgrade as required. However, it’s the other users who are going to worry – they have one eye on the new features because they’ve probably reached some limitation of the existing MySQL.

A key component of MySQL is its storage engine, the choice of which dictates the speed and functionality of database queries. In normal MySQL instances, the MyISAM engine is fast but doesn’t support transactions, while InnoDB is slower but does support transactions.

MariaDB, mentioned earlier, is another storage engine and MySQL 6 was meant to have a new storage engine called Firebird. These choices not only lead to confusion but also to dilution. If you’re a user of, say, MyISAM and already know its performance limitations, you may not want to move database engine but rather want those limitations fixed.