Bad decisions in retrospect

We’ve made one in particular, that is causing me to (seriously) regret our choice. We use wiki software for our documentation and internal site(s). We had chosen dekiwiki as our platform, based upon our perceived need for ease of use, access control, and other issues. First Wiki went up fine. This was an internal wiki for knowledge capture. Second wiki came up fine, for documentation. I like living documentation we can annotate. I don’t like painful documentation processes. Something I can cut and paste into. So we can write support vignettes, and be done with them. The problem. And there is always a problem. Updating/upgrading dekiwiki is nothing short of a nightmare. Many dependencies, many requirements. No simple “put a magical config file here and it just works.” Nothing of the sort. And re-installing on a different machine, with a connection into the databse? Fuhgeddaboutit. Seriously. Forget it. It won’t work. So here I am, with all our content in a database, with an installation that doesn’t seem to be working. I’m pretty close to installing a new vm with the old OS, and installing the old dekiwiki software, just to get it running. Then contemplating our move off of it. Basically I’ve got a simple cost-benefit analysis. If I can easily update/upgrade the wiki, patch it, etc. I’m in good shape. If I can easily run it with a magical config file, I am in good shape. If on the other hand, it depends upon dated/dead end technology (Mono in this case), this is a risk I need to reflect upon. In some cases its easy to be cavalier about some risks when you don’t think about them as significant risks. But the reality is that they are risks. Mono is effectively a dead end (wasn’t when we started). Deki sits atop mysql as well (which, while obviously not a dead end, is certainly experiencing significant level’s of churn). Next wiki will be in either PHP (Pre-existing, well regarded code … not that I like PHP, I don’t, but its usually not stupid about configuration), or Perl (self written with Mojolicious as the underlying technology). There’s lots of things I don’t need in the wiki, some I do. And a huge number of CPAN modules that can save me the time of writing it.