[Read Archiving DH Part 1 here.]
Trying to make sense of Digital Humanities projects and how to archive and preserve them is a lot like a jumble of puzzle pieces, and no picture to follow. The remaining posts in this series will look at these pieces and offer some ideas on how to put them together. This post will cover some (but definitely not all) of the problems inherent in Digital Humanities projects. These are problems that we have seen in the “wild.” These are just a few of the issues that programmers, IT people, Library people, and project leads face when they are planning their projects. Keeping these issues in mind from the start of a project will be helpful later on when question of archiving and preserving come along.
Changing Technology
The only three sure things in life are death, taxes, and change. Technology loves change. Technology IS change. In so many aspects, this is such a wonderful thing. Except when you try to take a snapshot of that technology for preservation purposes. Then the ever changing technology becomes the enemy.
Several aspects of technology make it really difficult to maintain and archive your typical web-based DH project (really, any DH project). First, is the unending upgrades and versions through which technology advances. As soon as you begin a project using a specific technology stack (stack = all of the software, hardware, etc used to create a DH project), it is out of date the next month, or week, or day. For example, as the Systems Administrator at CHNM, I (Ammon) was in charge of updating our web servers. I wanted our developers to use the latest version of PHP for this new project they were working on. You may have heard of it? Omeka? The old server had PHP version 5.something.very.old. The big problem here was the breaking change that PHP introduced in version 5.3.something.not.as.old. This had something to do with what was called “magic quotes.”
The details of what “magic quotes” do is unimportant. What was very important, was that all of the projects (mostly websites) that were created before my time there (from 1994-2005) were written with “magic quotes” turned on. But this was determined to be a huge security risk, and as the notice above points out, that feature and ability was deprecated, and finally totally removed from PHP. To make matters worse, new software, like WordPress, were starting to require this newer version of PHP. So if I were to upgrade PHP so we could make new sites, then I would break all of the old sites. The solution in this case, was to purchase new servers to put the new sites on, and leave the old, dangerously insecure PHP on the old servers to host the old sites. So, not really a solution in the long term, but I did successfully punt the issue to the next guy (sorry Roberto).