Photographing software

On a Friday night not too long ago I plopped down on the couch, fired up Chrome, clicked on the address bar, and typed “ne” and hit enter. My browsing habits being what they are, this should have autocompleted to “” But, I must have bumped the cursor, or something, because I landed instead on “,” the installation of Omeka I’ve been using for the last couple years as a kind of catch-all sandbox for experiments with Neatline. Which, I was unhappy to discover at 10:00 on a Friday night, was completely offline – just a sad Omeka error message, where there should have been a list of projects into which I’ve poured many hundreds of hours over the course of the last few years (thousands, I’m sure, if you count the time I spent working on Neatline itself).

The next morning, I SSH’ed into the instance and started poking around. For some reason, the MySQL service had died, after happily chugging away for two years without problems. Why? I have no idea. There was plenty of disk space. The EBS volume looked healthy. Nothing obviously malicious – the data was all there in one piece. The logs were uninformative. It seemed like there might have been some kind of change in the configuration of a service called AppArmor, which Ubuntu uses to lock down the permissions of services like MySQL. But why the change? Had something (someone) triggered an update? I tried to reinstall MySQL, and quickly hit more problems – for reasons that escape me, back in 2013 I deployed the server on Ubuntu 13, a non-LTS release that was completely unsupported two years later, to the extent that “apt-get update” failed outright because Ubuntu pulled the plug on the package repository. So, no quick fix – I had to completely re-deploy the site on a new instance.

As I slogged through this on a Sunday morning, I found myself thinking again about about something I’ve been circling back to again and again recently – the unbelievably short lifespan of a piece of software. Or, put differently – the strong likelihood that many of the things I’m working on right now will vanish, for all effective purposes, within 5 or 10 years. Take servers, for example. When I first started dabbling with web projects, I remember having a vague assumption that a server was a solid, persistent object in the world – sort of like a statue or a building, something that basically just sits there. Of course, this couldn’t be more wrong – a server is a mountain of imperfect software, developed by thousands of people over the course of decades, wrapped up into a hairball of dependencies and interactions that nobody completely understands, running on hardware that costs money and eventually breaks. An infinity of things can go wrong. Java can leak memory and crash; logs can gobble up disk space; linux distributions can fall out of warranty; hard drives can physically fail; MySQL can mysteriously crash. As soon as you look away, a server is like a ship at sea, motoring away with no one at the controls – sooner or later it’s going to run into something and sink.

Or, at the other end of the stack, think about something like Javascript. How long will Javascript written in 2016 last? 10 years? 20? I can’t imagine much beyond that. (God forbid, in a sense.) Maybe I’m wrong about this – maybe Javascript will, in fact, turn into a kind of assembly language for the web that provides a common compilation target for new technologies, in the vein of something like asm.js. But it could also go the way of Flash – in 5 years, we could all be rolling our eyes and laughing at it. And even if Javascript survives as a language – what about the rest of the browser runtime? Will the DOM exist in 20 years? There’s already grumbling that it’s irreparably slow, and that it should be abandoned for something new. (In a sense, this has already happened, with native platforms like Android and iOS.) Or what about CSS? What if everyone moves to flex-box layouts and browsers eventually drop support for pre-flex layout tricks, pulling the plug on every “float” I’ve written in the last decade? And even beyond the individual technologies themselves (which, theoretically, could always be emulated, however unlikely) – what if the interaction mechanics just completely change, to an extent that current software becomes simply illegible? What about mice, or track pads, or “cursors,” in the general sense? Will they exist in 100 years? What if we go full Minority Report, or whatever, and operating a mouse becomes a lost art, like using a slide rule or driving stick shift?

It reminds me, if nothing else, of the elegance and sophistication of text, as a technology. Its only dependency is language itself, which certainly changes – think of Chaucer or Beowulf – but only extremely slowly, and by way of a kind of massive, distributed social consensus that can’t really be sped up or meddled with. Plain text has a guaranteed shelf life – I can pick up a poem written by Yeats in 1899 and “run” it almost perfectly on the linguistic hardware in my head. (Bracketing the huge swaths of literary theory that qualify this, of course – just in the sense of practical language understanding.)

This isn’t to say that there’s anything wrong with software. In fact, I think there’s something valuable, even lovely, about this fundamental perishability. Software becomes charged with an energy, an ability to engage and delight, a sense of being alive and of our time, that I think is much harder to find in more traditional, easy-to-preserve media. This reminds me of a wonderful lecture that I heard back in college by Amy Hungerford, in a post-war American novel class. (Video and transcript here.) In the second half of Lolita, Hungerford said, Nabokov sets up a contrast between two types of art. On the one hand, Lolita represents a “living” art – an aesthetic blip in space and time, something experienced directly and in the first-person, all the more powerful for its brevity. Humbert is entranced by the sight of Lolita playing tennis, for instance, which in his eyes becomes a kind of dance, a perfect expression of youth, athletic grace, artistic freeplay. Humbert, meanwhile – a writer – wants to capture this in words, to preserve it, to carve it into stone. But to make something durable it has to be stilled, like a butterfly pressed into a book. Writing is a “lapidary” art – it can last forever, but this permanence is also one of its defining limitations. In denying its subject the ability to die, it also denies it the possibility of really living as art in the most extreme sense, in the way Lolita can waltz around the tennis court.

Anyway, this is all to say – in the past, I think I’ve thought of software as a “lapidary” medium. Which, in a lot of ways, makes sense. Writing code takes forever. Once you’ve finished it, you maintain it for years. Code seems like it’s made of the same fundamental stuff as prose or poetry – a sequence of characters that can be printed out on a physical page, stuffed away in an archive, etc. But, maybe this is wrong. From the long-durĂ©e, intellectual-historical perspective that matters in the academy, maybe it makes more sense to think of software as a performance, a phenomenon in the world that can be observed, like light or sound – but not an object that can be wrapped up and preserved in-and-of itself. Software as an event – not a thing, but something that happened.

What I’m trying to figure out, I guess, is whether it even really makes sense to try to maintain software, over the very long run. It definitely makes sense now, in the sense that projects like Omeka and Neatline are still very much in their prime. All of the projects I was trying to drag back onto the internet still run perfectly (though, the earliest of them, from about four years ago, already look a bit dated, which is upsetting). But, at a long enough remove, this won’t be true. So, what happens then? Or, more concretely. Assuming that software will, in fact, vanish – what’s the most productive way to respond to this? If it can’t be stopped, can it perhaps be balanced out, compensated for in some sense?

This is where I think it’s useful to think about software as a performance. We know what to do with performances – they can’t be preserved, but they can be recorded. Could I “record” a piece of software? What would that look like? In a sense, we do this all the time. I’ve taken dozens of screenshots of Neatline over the years (photographs, essentially) and put together screencasts that show the interface in action (video recordings). But, for the most part, I don’t really put much thought into this – they tend to be previews, teasers, splash images on websites and blog posts, stand-ins for the “real thing” behind the images. They’re haphazard, un-deliberate, catch-as-can-catch. It’s like walking through a museum, and snapping a photo of a sculpture with a phone.

But, it’s possible to imagine a very different kind of recording. Imagine, for example, that you’re a conservator at the museum, and you learn one day that the sculpture is made of a material that turns out to have some kind of fatal structural flaw that will cause it to completely disintegrate into dust in a week’s time. Nothing can be done to save the statue itself. This in mind, I’d take a much different approach. I’d find the highest quality camera possible and take hundreds of shots from all different angles and lighting conditions. I’d shoot it next to people, rulers, color swatches, and other objects to capture an intuitive sense of its size and presence in the physical space of the museum. I’d circle around it with a video camera. I’d try to get my hands on one of those laser scanners and get a really high-density 3d mesh. Instead of just signifying or referring to the statue, the recordings would effectively have to become the statue.

So – what would this look like for software? I guess I’d start by taking a huge battery of screenshots, capturing all possible states of the application and on all different screen sizes – a high-resolution desktop monitor, a laptop, an iPad, a phone. Then, to capture a sense of the lived, in-motion experience of the code, I’d round up a diverse set of contributors and stakeholders – PIs, developers, students, colleagues, target users – and have each record a 20-30 minute screencast of the software, walking through the functionality in detail and talking out an account of what’s there, what’s not there, what works well, what doesn’t work well, how (whether) it fits into some kind of larger technical or intellectual project. Maybe most important – write this, bake it off into a kind of technological-ethnographic account of the software, something that records the body of tacit knowledge about information design, interaction mechanics, and knowledge representation that’s always created in the process of trying to make software that actually works. We’d essentially be “taping” the software, sort of like a Grateful Dead concert.

I was chatting about this recently with Henry Lowood, who works on film and game preservation at the Stanford library. It turns out that art curators have been thinking about this for a long time. Beginning in 2000 and continuing through the aughts, a group of media archivists including Jon Ippolito, Alain Depocas, John Bell, and Craig Dietrich developed something called the Variable Media Questionnaire, which is essentially a template for describing a piece of art in terms of the conceptual units that would make it possible for a future artist or curator to recreate the intentionality of a piece, the gist of it, long after the specific technologies used in the original presentation are gone. Works are described as a combination of “functional components” that map onto high-level elements of the experience – eg, “media display” instead of “Thunderbolt monitor.” It’s basically a way of documenting the “what” and “why” of a piece of art, as opposed to the “how.”

What if something like this existed for DH projects, or software more generally? A template, a set of guidelines, a mode of documentary writing and media archiving that tried to capture software in a comprehensive, structured, and consistent way? Of course, this wouldn’t entirely solve the problem. Bits can rot, image and video formats will fall out of use. Text and images can be printed, but not videos. But, if nothing else, we’d be flattening out a high-fidelity representation of the software into a set of archival “primitives” that (I think) have a fighting chance of surviving in the library over a meaningfully long amount of time. If I had to bet, I’d guess that, in 100 years, it will be at least possible to interact with a .md, .jpeg, .mpeg file created in 2016, if perhaps onerous. The information would at least be self-contained, viable in isolation. Unlike a web application – which, let’s be honest, is about as preservable as a gust of wind – a grid of pixels has no dependencies.

Now, maybe this is all just paranoid. Maybe the current speed of technological change is actually short-lived; maybe over time it will settle down and coalesce around a common set of standards that would make it possible to actually preserve software, in a meaningful sense of the concept. Something like a Docker image for a complete stack of technology – everything from the transistors up to the Javascript, something that would legitimately make it possible for someone to use Neatline in 3016, in the way that we can read printed text from 1016. But, I can also imagine a future in which this turns out not to be the case.