We need a shared blog format

21

Author: Joe 'Zonker' Brockmeier

We have open and shared formats for word processing, spreadsheets, vector graphics, audio and video, site subscription feeds, and all sorts of other computing activities — but every damn blogging and content management system (CMS) package is an island unto itself. It’s time for a shared format that lets users move content from one package to another.

As I’ve said in the past, I use WordPress to publish my Weblogs, and I’ve found it to be one of the best tools for a single user blog. Over the past few years, I’ve recommended WordPress to several friends and co-workers, and it’s been quite popular with new bloggers. However, the response is always the same when I recommend WordPress to people who are already using another package — “Sounds great, but how would I convert to WordPress from my current software?” Data lock-in sucks, even when users are locked in to a specific free software package.

WordPress does have a few conversion tools, but it doesn’t have tools for everything. For example, one of my friends uses pMachine, and another uses Drupal. So far, I haven’t found conversion tools for either of those. (Since readers often know about software that I’ve missed, I hope that a helpful NewsForge reader will point out import tools for those packages as well.)

And it shouldn’t be a one-way street. As much as I like WordPress, it’s not for everybody. If someone spends six months working with WordPress and decides that it’s not the CMS for him, then he should be able to move to a new package more easily than he can now. Why should it be harder to switch CMS software than it is to move to a different word processor or spreadsheet application?

Why do we need portability?

It’s not at all uncommon to start a site with one package only to find that it no longer fits your needs — either because development falters, the project moves in a different direction than you’d like, or because you find a new package that fits your needs better than the original package.

Over the years I’ve used WordPress, Slash, phpWebLog, Blosxom, Mambo/Joomla, Movable Type, and Geeklog, for my personal sites and/or for work. The lack of portability between packages causes some serious headaches when it comes time to move to a new tool. Companies and individuals face losing their old content, finding a way to convert from one package to another, or maintaining two packages.

Here’s what we need

Each CMS and blogging package has different features, so it would be almost impossible to provide a portable format for themes, users, and other random assorted features that you’d find in something like Drupal, but not WordPress — or the other way around. But it should be possible to have a generic format for content and comments that could carry from one package to another — if not an identical database schema, perhaps an export/import format that is supported by every open source blog and CMS package.

Almost every CMS holds the same basic information: A headline or title, a post or article body, the author of the post, the timestamp, a category or categories for the post, status of the post, whether comments are being accepted, and so forth. Comments also tend to have the same basic information across different packages: A title, comment author, email address, timestamp, the comment body, which post the comment is attached to, and whether the comment has been approved.

Surely it shouldn’t be that difficult to develop a common export/import format that works across CMS software in the same way that the comma-separated values (CSV) format works for spreadsheets and other software.

Why developers should care

Why should WordPress, Joomla, Drupal, or other open CMS developers care if their soon-to-be ex-users have headaches trying to move away from their software? Because the odds are they’ll be gaining users from other packages as well — and a common format would save time and headaches in trying to create filters for each individual CMS.

It would also be a way of assuring users that they have long-term options if development stops on their current package. It would be reassuring to know that it wouldn’t be as big a hassle to move content to a new system in the event that things go south with the package you’re using right now.