One of the reasons I like open source is that vendor lock-in is less likely. Often, open source applications are built on open file formats and open standards, and files can be edited in different applications. The reason people stick to specific applications is that they happen to work for them. There’s something in each app that makes them suitable for specific tasks. This is not always optimal; for example, currently OpenOffice.org/LibreOffice is the best implementation of all OpenDocument features (i.e., if you want metadata and templates to work properly, you use these applications, because other applications are likely to mess things up), but if you want to just get access to the file content, there’s plenty of applications that read ODF files and can write ODF format files.

But there is one application that illustrates that you can get into vendor lock-in hell in open source world.

This application, of course, is MediaWiki.

Don’t get me wrong: MediaWiki is an excellent piece of software, and it is probably one of the best and most versatile wiki packages ever, especially for larger wikis like Wikipedia. If you use it as intended - as a single hub for your data - it’s a wonderful piece of software.

But it’s not exactly a wonderful piece of software if you want to get data in or out. I made the mistake of picking MediaWiki when, in retrospect, a smaller package (MoinMoin) would have been much better.

It’s just that I can’t move to MoinMoin right now.

I assume my silent readership has gone up by 200% and I have at least one reader now. For the benefit of my new readers, a summary of my basic situation is this: I have an internal wiki “encyclopaedia” for Avarthrel-related notes. These notes form the “canonical” description of Avarthrel. The wiki has been on a couple of different platforms: Instiki (a grim spectre of things to come, because basically the same thing that happened on current setup happened with this software), SnipSnap, and for most of its lifetime, MediaWiki.

I’m all about openness in world design, so the crucial question people might be asking is this: why isn’t the “encyclopaedia” of Avarthrel out in the web?

There’s a simple reason for that. MediaWiki won’t let me do that.

Providing this encyclopaedia of internal notes would be fairly trivial if I could just export the wikipages as HTML. There’s a MediaWiki extension called dumpHTML, which would let me to export the wiki to a set of HTML files; I’d just need to provide some sort of a skin for it, and hey, there it is. Based on the state of this awesome encyclopaedia dump project, can you guess how well this script actually works? Right.

MediaWiki does, these days, also support SQLite, so I could stick this wiki on the webhost. There’s just one small problem: Migrating MediaWiki from MySQL to PostgreSQL wasn’t exactly easy, and involved recreating user accounts and re-uploading files. Migrating from PostgreSQL to SQLite would probably involve same stuff. And there’s always the fact that MW extensions are not extensively tested on PostgreSQL; it’s likely that if the software fails to work on PostgreSQL to its full capacity, it won’t work too well on SQLite either.

That’s the sad secret of MediaWiki: the actual software works pretty well, but the data migration and data exporting is hell; the tools work to varying extents, and you’ll probably lose a lot of work. There are tools to dump the data into backup files, and restore those backups, but you don’t get full parity.

The tool usability isn’t very fun either. Sticking some information to this blog post, for future reference:

% php5 maintenance/update.php --conf $PWD/LocalConfig.php

and

% MW_INSTALL_PATH=$PWD php5 maintenance/dumpBackup.php --full --output=file:/tmp/whatever.xml

…because you just love it when there’s two different ways to specify where the config files are.

And while PHP is a very good programming language, there are certain… quirks.

% php5 --version
...
zsh: segmentation fault  php5 --version

*stare for half a minute* *very slow facepalm*

My current situation is that I upgraded PHP from 5.2 to 5.3 and MediaWiki from 1.15 to, um, 1.15. MediaWiki blew up, failing to render page content. I upgraded MediaWiki to 1.16, but this only broke the system further. My only consolation at the time is that the data appears to be intact and I have backups from time before the upgrade. MediaWiki may not be to blame, but I sure as hell don’t have any idea what broke this time. MediaWiki is enterprise software that is far too complicated for customers to comprehend, and like all enterprise software customers, I’m at the vendor’s mercy what comes to them shipping a version that actually works. I’m not a paying customer, so I shouldn’t expect help; all I have is a vague reassurance that this particular version works for the particular client that the vendor has provided the software for (that is, Wikimedia Foundation). It’s not a nice piece of software when things go hopelessly wrong.

So, don’t be alarmed if I start looking for ways to migrate the thing to some system that is a bit friendlier to exporting tools, like MoinMoin. The only problem, right now, is getting the data out of MediaWiki. Granted, this will be less of a hell than with certain proprietary systems, and it will be a bit of a hell when the advertised data exporting tools are outdated in some days and just plain refuse to work in others. But still…