netart-extinction — A Timeline of How Digital Art Goes Extinct


Digital art rarely dies on its own. It dies because something underneath it changes — a plugin reaches end-of-life, an API is switched off, a browser drops a feature — and the work that depended on it stops running. The artwork didn’t move; the ground under it did.

I kept hitting this while restoring works at ZKM. Eden.Garden renders through the Pulse 3D plugin — and Pulse 3D has been defunct for two decades. That is not a story about one artwork. It is a pattern, and I wanted to see the whole shape of it. So I built netart-extinction: a public timeline of the dependency changes that break digital art.

Events, not artworks

The site models two things and the relationship between them. Events are dependency changes — “Flash Player blocked”, “Firefox removes the <blink> tag”, “Google AJAX/Search APIs discontinued”, “GeoCities shut down”. Artworks are the works those events hit. Each event lists the pieces it affected, with a per-work severity and a status — dead, degraded, restored, working, unknown — and, where one exists, the fix or workaround.

Right now it holds 128 events, running from äda’web losing its funding in 1998 up to the present, mapped against a corpus of more than eleven thousand artworks pulled from the archives that actually track this: Rhizome’s ArtBase, Whitney Artport, Ars Electronica, LIMA, NTT ICC in Tokyo, the Archive of Digital Art, Turbulence by way of the Wayback Machine. A D3 timeline lets you scroll through it and watch the breakages cluster — the plugin extinctions of the early 2000s, Flash’s long death, the API sunsets of the 2010s.

Why group by cause

Documenting the problem this precisely changes what conservation looks like. If a work breaks because a browser removed a feature, then “preserve the work” really means “account for that feature” — and the same dependency usually took out a dozen other pieces at the same time. Seeing them grouped by cause instead of by artist is the useful view.

netart-extinction is the map of what goes wrong. The tools I build alongside it — the exhibition VM controller, the wayback cache proxy — are attempts to keep specific works running against exactly these forces. Eden.Garden is the counter-example in that library: a 2001 work whose core dependency sits on the timeline as extinct, brought back and kept exhibitable. Most of the eleven thousand did not get that.

Open and citable

It’s an Astro static site with a client-side D3 timeline, open source under MIT (code) and CC BY 4.0 (content), with a Zenodo DOI so it can be cited in the conservation literature. Contributions of events and affected works are welcome. Live at extinction.zkm.de.