4 min read

If there’s one golden rule of open source, it’s this: Major projects can and will be forked. Multiple versions of just about every open source app of repute have been spun off from the original.

These splits happen for reasons that are more often political than technical. Look at the clamor building around MySQL, where people concerned about the future of the project under Oracle’s stewardship want its code copied out into another, separately managed project that won’t (as they see it) end up as a corporate lapdog.

The blogging system Movable Type, now in its fifth major revision, is also undergoing a code schism of sorts. A number of Movable Type developers and contributors became frustrated with what they felt was an emphasis by MT’s corporate owners on the wrong features, as well as a lack of transparency in the development process for the product. Rather than attack Six Apart (Movable Type’s parent company) directly, they chose instead to do an end run—to take the now open-source code base for Movable Type and create a new product from it: Melody.

The theme behind Melody

Melody extends on Movable Type’s legacy in four basic ways. Take what already exists in Movable Type, keep what’s best about it, remove from the core product features which make things substantially more complex but which are only used by a minority of users anyway, and move Melody forward in ways that show the developers are directly attuned to the needs of the new user (and developer) base.

How these things manifest in Melody can be summed up in a few key points as shown below.

Backwards compatibility

Since most of the initial user base for Melody will consist of Movable Type users and developers, it only makes sense for Melody to be heavily backwards-compatible with MT.

This doesn’t just mean that a MT database can be imported into a Melody installation as-is. This also means things like plugins and transformation filters will still work correctly. Both are crucial, since so much of MT’s appeal is in how it can be bent and shaped to fit user’s needs—and those same needs will carry directly over into Melody. (If anything, they’ll have to be satisfied all the better in Melody, since Melody’s being written specifically from the perspective of allowing such customization to be all the easier and more powerful to implement.)

The exact degree and scope of Melody’s backwards compatibility with Movable Type is still being wrangled out, but it’s likely to be as friendly as possible to existing MT developers as a way to gain their immediate support. One thing that has become clearer is that people looking to make a straight upgrade from MT to Melody will at this point be best served by an upgrade from the 4.x branch of MT than the current 5.x branch. This is probably due to Melody being more derived from the former than the latter, but there’s nothing that says in time a clean 5.x migration path can’t be created.

A more developer-friendly culture

“Developer” doesn’t just mean people who write Melody or Movable Type’s own code. It means people who create the above-mentioned add-ons, and—in some ways the most visible type of third-party development—people who create themes and templates for the system. A better culture for those people to thrive in means more.

Another concrete way for developer-friendliness to manifest is with better use of existing CPAN (for Perl) and jQuery (for JavaScript) libraries and community-developed code. A lot of what was written for earlier versions of Movable Type duplicated functions that were available in those repositories. Not only did this mean MT’s code had to be maintained separately, but it also meant Movable Type didn’t leverage what was available in CPAN and jQuery as effectively as it could.

Indirect contribution to Movable Type itself

What Melody’s developers hope to create is a project that doesn’t so much steal marketshare from Movable Type as it does give Movable Type itself a chance to become a better project, too. Melody could become a model for how MT itself might evolve, and since Melody’s licensed under the same terms as MT itself (GPLv2), there’s nothing preventing significant chunks of Melody—or even the whole project—from being back-adopted into MT.

Even the Melody developers themselves don’t see everyone ditching Movable Type. For one, the enterprise-level editions of Movable Type have a bevy of features (not least among which is paid support) that won’t show up in Melody any time soon. That and Melody’s developers don’t see it as being part of their project’s focus to try and eclipse MT’s high-end, paying-customers features. (Melody’s own FAQ discourages using the paid-support add-ons for MT with Melody, because of the licensing and support-contract restrictions involved.)

Melody’s current interface is based on the 4.x branch of Movable Type, and so most closely resembles that program with only minimal changes.

LEAVE A REPLY

Please enter your comment!
Please enter your name here