Fixing Images in the Wiki, Which is No Longer a Wiki (Unnecessary Bloat)
A quick site update (quick relative to how much we really had to say and to show)
THE wiki was being worked on in recent weeks, especially over the holidays, as we had promised and scheduled. But we're far from done and we now ponder how to organise all the old material, set aside the search facility for the site.
I originally planned to do this coverage in the form of a video because I have a lot to say (it's a subject that is close to my heart, having worked on this site for over 17 years), but due to a lack of time we must settle for just this short article. Hardware issues have taken up plenty of our time lately. No data was lost (backups of a backup did the trick). But it wasn't a quick task.
Earlier this year we restored pretty much every image from the old wiki, re-adding those to the static pages derived from the original (very old) wiki. We wondered how easy would it be to make them work in all pages in one fell swoop, knowing there are all sorts of syntactic edge cases (that no single regex can properly deal with; we loved the part where boilingsteam was 'steaming' at WordPress last week; we dislike WordPress for encouraging pseudo-HTML syntax like [video] or the pseudo newlines which caused us to need many regex lines and it is still imperfect, albeit mostly visually).
The bottom line is, a content management system (CMS) may seem alluring for shortcuts in composition and management of pages. But that comes a cost called "complexity", including dependencies and frequent releases, security problems, and so on. Think of a CMS as mnemonic for high exit cost/barrier - a bit like vendor lock-in. I saw this firsthand at work as some jobs and projects involved moving from one CMS to another - basically migrations.
"If you can find the EU or EC documentation which includes exit cost as part of a product's TCO that would be important (perhaps essential) to spotlight," an associate noted.
I wish to emphasise that exit barriers aren't just a proprietary software problem. Even Drupal and WordPress, however popular they are, aren't easy to exit or even enter. Sites like TechDirt have spent plenty of time and money migrating to WordPress, perhaps not taking into account the cost of leaving (if so they choose later). Worse yet, they chose WordPress.com, the centralised service that is outside their control!
Exit barriers when it comes to proprietary software tend to be a lot higher because migration is sometimes a monopoly and it's hard to decipher how things work, at least in the software sense rather than reverse-engineering sense (traditionally hardware interfaces). But that's a subject for another day.
We're finally free (as in freedom, independence) from Drupal, WordPress and MediaWiki. We'll never come back to them. It's a "lazy" decision to deploy them (not difficult with today's sophisticated installers that abstract away things like databases) rather than considering one's own method/s. As time goes by a CMS becomes more and more bloated. As time goes by sites grow bigger and bigger (larger datacases). Both factors increase the cost of exit. █