Working on large initiatives like digital preservation often feels like being in a car on a bumpy road under construction. There are lots of stops and starts. It’s “hurry up and wait.”
One of the things we’ve come across here on the Digital POWRR project that we weren’t expecting are some technical roadblocks. Specifically, that moment when you’re figuring out what the next step is to take, and you look at the instructions that some generous soul has written up for installing that piece of software, or configuring it, and you see words like this: “Sourceforge” “virtual machine” and “command line.” I’ve linked to the Wikipedia explanations of each, which is one of the ways I’ve come to understand each of these terms.
That’s the first roadblock. The instructions assume that you, too, are a developer or tester, and know what these things are, how to access them, and how to install and run them on your computer. If you’ve never used a command line interface within a virtual machine setup to install software from Sourceforge, you may find some of this intimidating.
If you’re in an open computing environment (i.e. you can download anything you want to your machine without anyone’s permission), you may be able to poke at some of this stuff and muddle through it, especially with the help of user communities. That said, I would love to see some of the instruction writeups for software get “translated” from developer-to-developer to developer-to-possible enduser.
Let’s put it this way. I did the tiniest amount of command line work back in the late 1990s in library school. I learned HTML. I took one scripting class, and we worked in Perl. I am not a programmer or a network administrator, and the chances of me becoming one in the next year are slim to none. I can follow basic directions to complete a task, and am unlikely to blow up my computer by hitting a wrong key. I can tell the difference between a good source of code and a bad one, and I’m not the kind of user who clicks random links and spreads malware or viruses. I’m *reasonably* savvy as a user. (Real world example: I could probably root my Nook to turn it into an android tablet with decent directions, but it would take me 3 times as long as someone who does this sort of thing for a living or a hobby).
This is partially because of the second roadblock. I work in a closed computing environment, and have for basically most of my professional career. Like many libraries, we have dedicated professional staff who maintain our desktop machines, and monitor all the different software packages that we use. They are great, but any project that involves new software in a computing environment like ours means that they, too, are involved in the project. The have to be, to maintain the integrity of our networked environment.
Even if I wanted to, I’m not generally allowed to download and install software on my desktop just to take it for a spin. I’ve never installed open source software, and I wouldn’t know how to set up a virtual machine if my life depended upon it.
I understand the need for a closed computing environment when you’re trying to deal with a really complex system. No one wants to deal with people installing random software willy-nilly that could crash everyone else’s computers. Heck, no one wants to be the end-user who DID that.
So how do we drive around the roadblocks? Lots of meetings. Good, clear communication. More meetings. Understanding that the systems folks in our closed environment are very busy, and making sure that our requests for software are clear, concise, and lay out the risks, if any, as best we can determine them.
This is one of the roadblocks we’re dealing with as we get ready to test software: the combination of not being terribly familiar with the downloading/configuration side, and working within the schedules of our fantastic IT folk to make it all work.
What are your roadblocks to digital preservation?