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.
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.
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.
Getting Into It
As of this writing, Melody’s a pre-1.0 project; it hasn’t even been released in a publicly-usable alpha-grade build yet. The only way to obtain the program is to go to the Melody code repository on Github, check out a copy of the code, set it up on your own server, and give it a whirl. There’s as yet no "appliance" version of the program—much as there is with Movable Type on Jumpbox—which would make testing that much more straightforward.
If you already have experience with Movable Type, though, it’s not that difficult to test out the pre-1.0 build of Melody, since the setup process is fundamentally the same.
- At the Github page for the project, click "Download source" and obtain a ZIP archive or tarball of the source (pick whichever archive format you and your server are most comfortable with).
- Upload the archive to your server and unpack it there into a subdirectory specifically for executables (like, /cgi-bin/melody). You can also unpack it locally and upload it piecemeal, but there’s no reason to do that if you can extract the archive remotely since that’s likely to be much faster.
- Set the permissions for the program. All of the files ending in .cgi in the main application directory should be given the permissions 755.
- Most of the time, you shouldn’t need to change default directory permissions, but if you do they should be owner read-writeable.
- The mt-static directory, which is normally within the main program directory, should be world-readable and owner read-writeable. If your system is set up so that anything within cgi-bin or wherever executables are stored is not world-readable, move mt-static somewhere else (like, off the root folder) and change its permissions. You’ll need to point to it during the setup process but this shouldn’t be too difficult.
- Create a database for Melody. Most people will be using MySQL as the database product for Melody, although it also supports SQLite if that’s available. On the whole, you’ll want to use MySQL whenever you can—it’s more or less the de facto standard database for products of this kind, and the number of installations that don’t support it is vanishingly small. You’ll be able to specify within Melody which database user to connect with, so make sure you have an appropriate user configured for that database with the full gamut of permissions.
With all the appropriate files and data structures in place, you can now start Melody’s own setup.
Note that the Movable Type logo is still being used in the setup process; this is only because a lot of the branding within the product hasn’t been replaced yet.
- Open a web browser and navigate to the mt.cgi file within your Melody installation. This would probably translate to something like http://www.yourdomain.com/cgi-bin/melody/mt.cgi, but the exact path will vary depending on where you unpacked everything. If the directory in question allows anonymous browsing, you can simply go to the directory itself (like, http://www.yourdomain.com/cgi-bin/melody), where you’ll reach a landing page that’ll let you pick a language (English, German, Spanish, French, Japanese, Dutch) and kick off the setup process in earnest.
- The first thing Melody does is check whether or not you have all the needed Perl modules to run the program. Note that even if this check passes, you may still need to do some manual configuration later on so that certain other functions will work correctly. Example: Some servers don’t have the Image::Magick Perl package installed by default, and so you’ll need to specify an alternate image driver (for things like avatars or creating thumbnails from uploaded images).
- Next, you’ll choose the database type and provide the database name, username and password to connect to it. Some hosts may automatically append your user-account name to the head of the database name, so make sure you have the exact name of the database if the "Test Connection" function doesn’t work.
- Next you’ll pick how you want mail to be delivered from within Melody, for admin notifications. Most systems should be able to use the sendmail option without any modifications.
- Next you’ll create an administrator account within Melody itself. For this you’ll need an email address, which can also double as the system email.
- Finally, you’ll be asked to create a single blog for starters. For this you’ll have to provide a name, a web URL for the blog, a path to a directory on the server where the blog’s files will be written. (You can also set a local timezone for the blog.)
After that, you’ll be sent to the main system dashboard, where you can immediately start posting or managing entries.
Note that if you’re curious about testing cross-compatibility with your existing Movable Type installation, you can test things out by creating a new database for Melody and copying the existing data from your old MT database into it. If you’re using phpMyAdmin to remotely manage MySQL, you can do this from the Operations tab for the database. The exact options to use may vary; if you aren’t allowed to create databases directly through phpMyAdmin on your server, be sure to uncheck the "CREATE DATABASE before copying" option.
Don’t attempt to test Melody with a database from a Movable Type 5 installation, since there are enough changes to the schema to break normal behavior. For instance, the default path for blogs isn’t interpreted correctly from the MT5 schema, so it defaults to a path based on your current Melody installation. Press Publish and you could theoretically overwrite files you don’t want to touch.
If you want to test Movable Type plugins in Melody, they should install exactly the same way as in Movable Type. Most of them should behave as-is, although there are no guarantees at this stage. The development team is interested in hearing feedback about plugins that don’t work, since a big part of what drive Melody development is providing a good culture of third-party plugin development.
Where the Project Stands
Original estimates for a public alpha version of the program were aimed at late 2009. There’s no precise timeframe on when a 1.0 milestone will be reached; in an email on the Melody mailing list, Tim Appnel, a longtime Movable Type developer and one of the main Melody developers, noted that the holiday season and the fact that many Melody developers are themselves small business owners (presumably with their own for-pay coding to take care of) contributed to the delay. The other thing that’s been holding things up a bit is devising proper unit testing, something the Melody developers take seriously as an adjunct to taking performance itself seriously. None of these delays have proved fatal, though.
Development traffic on the project remains strong, with commits and checkouts on the code happening on a daily basis, so a full 1.0 revision shouldn’t be more than a few months around the corner. Once Melody’s formally released in a public version, I’ll take a full-blown dive into it and talk about how it shapes up against Movable Type, detail-for-detail.
If you have read this article you may be interested to view :