Chapter 1 · 1 of 6

Showing software-based art, for months, without staff

An exhibition does not run a work once for a demo. It runs it every day for the length of the show, recovering from every crash — ideally with nobody watching.

A growing part of contemporary art exists only as software: net-art, CD-ROM works, Flash and Shockwave pieces, early Java–QuickTime integrations, browser-based installations — works built on software platforms that have since disappeared. To exhibit such a work is to keep one known-good state running unattended for the months a show is open — through crashes, frozen operating systems, and visitors who leave it in strange states — and to recover automatically, every time, without a technician on call.

A browser-based work from JODI's Wrong Browser series projected at the exhibition Choose Your Filter! — output produced by code that only runs in a period browser, on a machine that must keep running for months. — Figure 1. A browser-based work from JODI’s *Wrong Browser* series projected at the exhibition *Choose Your Filter!* — output produced by code that only runs in a period browser, on a machine that must keep running for months.

A different problem from research

Keeping software-based art alive is really two tasks, and they pull in opposite directions:

Researching a work means opening it up: exposing its state, trying things, breaking them, rolling back — with nothing resetting your work behind your back. That is the job of the Research VM Controller.
Exhibiting a work is the mirror image: keep exactly one verified state running, hide all the machinery, and on any error return instantly to that state. That is the job described here.

The exhibition-vm-controller (evmctl) is the tool for the second task — built at ZKM for a real exhibition and proven across twelve computers over six months. It is deliberately autonomous: it starts straight into the artwork, full-screen, and silently heals itself.

One lifecycle, three tools

A born-digital work moves along a single path: analysis → workbench → exhibition. The analysis module examines an unknown work and says what it needs; the research workbench is where a conservator rebuilds and verifies it, state sacred and nothing resetting behind their back; and evmctl is the last stage — the locked, auto-recovering runner a museum switches on each morning. Today a verified, frozen result is carried across that seam by hand; the automatic hand-off from the workbench to the exhibition runner is planned (see the last chapter).

Lineage evmctl is ZKM Open Source (MIT) and the original system the vmctl family grew out of — its “north star”. The research workbench was factored out of it onto a shared core, vmctl-core; folding evmctl onto that same core — so a verified result promotes from workbench to exhibition rather than being ported — is the convergence still to be done. This site describes evmctl on its own terms.