vmctl alpha Keeping born-digital art alive

Contribute

This only works with company

The tools get sharper with every real work they see. There are three ways in — and the most valuable one requires no code at all.

Contribute a work

For institutions, artists, and collectors holding a born-digital work.

If you hold a software-based artwork — yours, your collection’s, or one you are responsible for — that no longer runs or that nobody dares to run, that work is the highest-leverage contribution you can make. Bundle it as a single zip with a short top-level description: title, artist, year, the runtime you believe it uses, the intended host system, display and peripherals, and how it was meant to behave. That description becomes a trusted, human-authored prior for the analysis.

What happens to a submitted work:

  • The analysis module reads it end to end and produces a report: what it is, where it begins, what machine it needs, every network host it reaches for. You get that report back — it is useful even if nothing else happens.
  • Where feasible, the work moves onto the workbench: an era-correct virtual machine, a revival attempt, and a written recipe for how to bring it back.
  • We never destroy or modify the original; all work happens on copies. Nothing is published about your work without your agreement — anonymized by default, credited only if you want it.

Honesty about where we are: this is alpha software run by a small team at a museum, not a service with a guaranteed turnaround. Some works will resist revival; a report saying why is still a conservation result. Please confirm you hold the rights to share the material.

Contribute knowledge

For conservators, restorers, and historians of the period.

A legacy runtime — Director, Flash, Java, QuickTime, VRML, a native binary format — is expert knowledge, and much of it lives only in people. What helps:

  • Case studies: a revival you did, what broke, what worked — the roadblocks are the valuable part.
  • Period-software lore: which plugin versions actually shipped, which installers survive, which quirks matter.
  • Testing: run the tools against real works and write a real bug report — what you did, what you expected, what happened. That is worth more than a dozen “it doesn’t work”s.

Contribute code

For developers.

Everything is MIT-licensed and public at github.com/zkmkarlsruhe: the analysis module, the research workbench, the exhibition controller, and the shared core. Useful entry points:

  • Issues labelled good-first-issue in each repository.
  • Runtime modules: identification signatures, decompiler wiring, and environment recipes for a format you know — expressed as data, no engine changes needed.
  • Documentation: the docs site is young; corrections and guides are welcome.
Get in touch One address for everything: hello@vmctl.org — a work to analyse, an institution that wants to partner or host, or a runtime you know better than we do.