SEDA Amsterdam — When Conservators Talk to Software Engineers


A few weeks ago I spent four days in Amsterdam. The reason was the Software Engineering and Digital Art Conservation (SEDA) workshop at Vrije Universiteit, organised by Mauricio Verano Merino (VU Amsterdam) and Benoit Baudry (Université de Montréal), with sponsors from National Taiwan University, University of Arizona, and Indiana University. I gave a talk in the morning conservation track. The day after, LI-MA opened its doors for the Transformation Digital Art 2026 symposium and I stayed for that too.

It was the first time I’d presented this kind of work to a room with as many software-engineering researchers as conservators. That’s the experiment SEDA is — putting the two communities in the same building for a day to see what happens.

Two halves of one problem, talking past each other

Software artworks break in two languages. The conservator language is what is the work: provenance, intent, identity over time. The software-engineering language is how does the artifact run: dependencies, supply chains, reproducibility, build determinism. Both are talking about the same set of files on disk, and almost nobody is fluent in both.

The schedule reflected the bet: conservation in the morning (Inge Hinterwaldner from KIT, Yannick Westphal, me, and Victor de Boer on heritage metadata), software-engineering methods in the afternoon (Stefano Zacchiroli on Software Heritage, Benoit Baudry, Mauricio), then ninety minutes of joint brainstorming and writing.

I came in expecting to spend most of my talk explaining the practitioner constraints — exhibitions open at 10am, hardware is what the museum already owns, restorers refuse a 4-hour-per-day mechanical artwork — to people who reason about software in the abstract. That happened. What I didn’t expect was how much the SE side already understood it; the surprise was how little the conservation side reaches for the SE community’s existing tools. Software Heritage is right there. Reproducible builds are right there. Most museums have not heard of either.

What stuck

A few things from the day I keep thinking about:

  • The afternoon brainstorming was the actual point. A workshop where the morning establishes vocabulary and the afternoon argues about specifics is doing it right. Half the value was in side-conversations during the writing block.
  • The SE side has discovered conservation isn’t a special case. “How do you keep this software working?” is a question every software-heritage person already asks; the museum case is just an extreme of it. That reframing was helpful.
  • There’s a missing artefact. Nobody has a handbook for “you are a media-art conservator who needs to do this in software-engineering terms.” It’s the kind of document that makes the whole field move at once. SEDA is, structurally, an attempt to write the table of contents.

A day at LI-MA

LI-MA in Amsterdam is the institute that’s been doing this for years. They’ve built up the practitioner side of digital-art conservation across decades of installations, and TDA — Transformation Digital Art — is their annual public version of the same conversation SEDA had behind closed doors.

The 2026 theme was Networks: Structures of Collaboration, Care, and Trust. Day one circled trust-based systems and decentralised infrastructure; day two looked at AI ethics and the algorithmic side. Walking from a workshop where the question was can we treat artwork software as a research artefact into a symposium where the question was who are the networks of people that keep these works alive in the first place was the right ordering. The artefacts don’t preserve themselves; institutions do, and people inside institutions do, and those people need each other.

I came home with a list of half-a-dozen specific things to try, two contacts I want to keep talking to, and a stronger sense that the ZKM tooling we’ve been building (the exhibition-vm-controller, the wayback-cache-proxy, the LiDAR system) belongs in this conversation more than I’d realised.

More on that as I figure out the specifics.