As a person who makes and uses software, on this Memorial Day I want to commemorate the software that brings you these words, for I shall soon retire it from service. (I'll keep writing, naturally, using different software.)
This site has run on Textpattern for eight years. It was, at the time, the web publishing software most to Nathan's taste, and by extension mine. Textpattern made it easy for me to publish, so I wrote about my travels home and abroad and travails in college. Combined with rss2email and ezmlm, it made it easy for my family and friends to read along, so they did. Every time I wrote, someone I cared for would write back. Quite simply, Textpattern kept me in contact with my favorite far-flung people. And with Nathan's help, it lifted my voice off the page and into your ears. When I finally settled the score on becoming a composer, Textpattern is why you were able to hear my music and know how I felt.
For all this I'm thankful, but also uneasy. I've been uneasy for eight years because Textpattern takes my precious words and memories and stores them in a database. Databases are essential tools for solving certain kinds of problems, but also complex tools that demand effort and skill to maintain, and therefore a problem-solving tradeoff that merits careful consideration. “Database administrator” is a job, smart people who specialize in it make a good living, and I am not one of them. Remember how the server hosting this site crashed during 2008 fall finals and the site stayed offline for three years? I was lazy, and I was busy, and then I was lazy again, but mainly I was loath to deal with restoring a database. That experience was caused by, and reaffirmed, my unease. I'm extremely uncomfortable putting my most valuable data in a place even slightly beyond my ken.
Nothing forces web content management systems to rely on databases. When I started my online journal in 1999, I wrote a wee bit of PHP to assemble web pages from text files in a
YYYY/MM/DD hierarchy. (HTML was generated on the fly, but there's no reason it couldn't have been precomputed.) Since my content consisted of ordinary documents in an ordinary filesystem, all the usual Unix tools were available to write, process, back up, etc. Granted, my needs were extraordinarily simple. But when I switched to Textpattern in 2005, despite getting a bunch of features I wanted, I felt I was giving up something extraordinarily important. I did it anyway because the CMS I wanted didn't exist yet and I wasn't in a position to build it.
It's existed for a while now. I've used ikiwiki to build sites for The Philolexian Society of Columbia University and The NetBSD Project under constraints I don't believe any other web publishing system came close to meeting. In both cases ikiwiki already very nearly did; in both cases I was able to easily extend it to finish the job. I came away with a deep appreciation for its architecture and flexibility. It's the Unix of web CMSes (orthogonal and composable, with the concomitant learning curve) and a web CMS for Unix (files in the filesystem, real revision control). The server doesn't need a relational database installed. It doesn't even need ikiwiki installed! Any HTTP daemon can serve up static HTML files.
I'm very comfortable with ikiwiki. It has become my default solution to any web publishing problem that doesn't require a traditional dynamic CMS. The more sites I move to ikiwiki, the better I feel. So it's inevitable that I want this site, above all others, to move. As usual, I first need to extend ikiwiki a bit. Once my podcast enhancements are merged, migrating
schmonz.com from Textpattern to ikiwiki can be straightforward and seamless. You probably won't notice when it happens — except that since I'll be a lot happier about how my site works, you might notice me writing more.