Commentary

Serdar Yegulalp
 

Melody: Movable Type, Reloaded

It's always compelling news when an open source project of some renown is forked. It's twice as compelling when it's a fork of a project you use and rely on personally. I speak of Melody, a spinoff of the open-source branch of the blogging and publishing system Movable Type.

It's always compelling news when an open source project of some renown is forked. It's twice as compelling when it's a fork of a project you use and rely on personally. I speak of Melody, a spinoff of the open-source branch of the blogging and publishing system Movable Type.


More Software Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

Melody's mission statement: "... an open source content management system for bloggers and publishers where its community of users and contributors is its most important feature." It's being developed by a clutch of folks who worked on Movable Type itself -- Byrne Reese, Jay Allen, Tim Appnel, among others.

One of MT's own senior figures, Anil Dash, sits on the Open Melody Software Group's board of directors as well. So to my eyes this isn't a "hostile fork" (to coin a not-terribly-accurate phrase), where someone simply picks up existing source code and runs off in another direction with it. "Fork" is probably too generic a word, anyway. What they want to do is create something that Movable Type itself can benefit from as much as anyone who uses Melody.

The idea, according to the Melody FAQ and other published details, is along these lines:

  • Take the open source Movable Type core product as a starting point. The original MT didn't originally exist in a 100% open-source GPL-licensed implementation; that edition of the product came later. Melody starts and remains as open source.
  • Remain compatible with the native MT language, templates, plugins, etc., so that existing MT users can work in Melody without breaking anything and contribute needed feedback.
  • "Decouple" the core product (their word, a good one) from features that are advanced and intriguing but aren't deployed by the vast majority of users and add complexity that isn't really needed.
  • "[Build] bridges to other successful developer communities outside our own, like the greater CPAN and jQuery communities, and [work] with them to incorporate the outstanding work they are already doing. ... [W]e need to embrace those components and libraries that have greater mind-share than the ones we rely on today or the ones we could build ourselves."
  • Build a product where the community of users and its needs came first.

This is all ambitious and good to hear, especially since I'm one of those very users. My own personal site is powered by Movable Type and has been for some time now, and sports a good many of my own personal tweaks and enhancements.

After hearing about the Melody announcement, I decided one of the best ways to help them out would be to participate directly. I'm not about to upgrade my current live installation of MT to Melody, though -- I have a sandbox installation that I'm setting up and which I'll synchronize my data to as a testbed, to see how it behaves in comparison to the "real thing".

As much as I have loved MT, I cannot deny there have been some frustrating things about it -- features which feel like they should be there but simply aren't, or which are provided in a very uninspired way. To see a new way for the same framework to be improved, and to allow for feedback and suggestions that stem from my own use, is deeply heartening. In short, I wouldn't be doing any of this if I wasn't already an MT fan. If I wasn't, I would have moved to a competing product a long time ago.

Let's see where this heads. Expect some dispatches from me in the future about Melody's progress, and my own progress with Melody.

InformationWeek Analytics has published an independent analysis of the current state of open source adoption. Download the report here (registration required).

Follow me and the rest of InformationWeek on Twitter.


Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

InformationWeek encourages readers to engage in spirited, healthy debate, including taking us to task. However, InformationWeek moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. InformationWeek further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
T-Shirt Giveaway T-Shirt Giveaway: Each week we're selecting one great comment from our readers. The author of the comment will receive an InformaitonWeek Community t-shirt. So get posting!
Subscribe to RSS

Resource Links