shared under a Creative Commons license DeweyC21; original source: http://www.artsjournal.com/dewey21c/road_block.jpg
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?
3 comments
“Requires a *nix environment” is by far the greatest roadblock I come across when playing around with tools. The part of me with techie friends understands that building open-source programs in Linux makes the most sense for most developers, so I can’t really get *too* upset about this. The part of me that is not himself a techie, however, is frustrated that he doesn’t even have the opportunity to test out said tools to see if they would be appropriate additions to our workflow. (Our computers are such that running virtual machines is not usually an option– the amount of memory I have to allocate for the BitCurator VM, for example, is more than my entire computer runs on.) I’m hoping as technology marches on I’ll get machines that can handle these more complex tools, but until then I am outside looking in on a lot of them.
Also want to second the call for tool builders to write developer-to-end user instructions, even at a very basic level. Not knowing how to compile source code basically puts a number of tools out of reach for me, a lack of scripting knowledge makes configuring other near-impossible, and if not for starting out my computer experience with DOS I probably wouldn’t be able to use the CLI-only tools, either. Granted, some of these tools are still technically in beta (or alpha!) but developers would get more feedback on their tools if they made it possible for more people of varying technical expertise to use them.
Author
*round of applause*
Yes. This.
I couldn’t resist commenting. Perfectly written!