How to prepare creative code so that it can run again

Possessing the source code does not guarantee that an artwork will function again. The exact version of a library, the compiler, a typeface, input data, a key, a device, or a step known only to the original programmer may be missing.

Preparing creative code for the future entails maintaining a reproducible system and explaining how to verify it. The objective is not to freeze it indefinitely, but to reduce reliance on tacit knowledge and to render visible the decisions that a future migration will necessitate.

The guide Preserving a digital artwork situates the code within the collection of files constituting the artwork. This guide focuses on the technical package.

Begin with an inventory

Before organising the repository, note what exists:

• repository and relevant branches;
• approved artistic version;
• source code;
• binaries or executables;
• data and resources;
• direct and indirect dependencies;
• build tools;
• operating system and hardware;
• configurations and environment variables;
• external services;
• documentation and reference outputs;
• licences and restrictions.

Link the inventory to the master artwork record. Do not intermingle secrets, personal data, or materials whose redistribution is prohibited within a public package.

Two institutional models serve as reference. The Guggenheim acquisition checklist for computer-based artworks requests all assets necessary to execute the artwork, the source code or project files, copies of the libraries utilised, a written list of hardware and software requirements and dependencies, installation and startup instructions, credentials, a list of external web services, and video or audio documentation of the artwork functioning correctly. For its part, the Software Preservation Network publishes a guide to the Software Metadata Recommended Format (SMRF). Neither is a mandatory standard.

Source code, history, and approved version

A version control repository preserves changes, yet it does not in itself indicate which commit constitutes the artwork. Mark an approved version via a tag or immutable reference and record:

• artwork title and identifier;
• repository;
• commit or revision;
• version tag;
• approval date;
• development branch;
• responsible person.

Retain the history when it explains decisions or facilitates reconstruction, but also create a closed package of the approved version. A remote repository may change, close, or lose large files stored elsewhere.

Software Heritage archives public code repositories that can be cloned and allows for version referencing via persistent identifiers (SWHID), which it describes as an ISO/IEC international standard. Own inference, not a statement by Software Heritage: the Software Heritage archive starts from the public repository. Binaries, data, private dependencies, credentials and instructions that are not in that repository require a separate archive.

README, authors, and licence

Include in the root directory:

• README: purpose, structure, installation, and execution;
• AUTHORS: individuals and roles;
• LICENSE or list of licences;
• change history or a link to it;
• recommended citation, if applicable;
• machine-readable metadata, such as codemeta.json, where useful.

Software Heritage recommends adding a README, an AUTHORS file, and licence information before archiving a public repository, and presents codemeta.json as optional machine-readable metadata. The licence for the code and that of the artwork or its outputs may differ: do not assume one covers the other.

Complete dependencies and versions

Do not document only the packages you import directly. Retain:

• manager and version;
• dependency manifest;
• lockfile, if it exists;
• repositories, registries, or mirrors utilised;
• manually obtained dependencies;
• native libraries and drivers;
• models, fonts, and codecs;
• checksums of critical packages;
• licences.

Avoid expressions such as "use the latest version". Pin the tested version. If a dependency cannot be redistributed, record the name, version, provenance, and legitimate procedure for acquisition.

A list of packages does not guarantee their continued availability. When the licence permits, retain copies. When it does not, document alternatives and restrictions.

Operating system and hardware

Record:

• operating system, edition, architecture, and version;
• kernel or build where relevant;
• processor and architecture;
• minimum memory and storage;
• graphics card and driver;
• resolution, refresh rate, and number of displays;
• audio interface and channels;
• sensors, cameras, controllers, and firmware;
• network connections and peripherals.

Distinguish between a material requirement and a significant property. A specific GPU may be replaceable if it maintains the behaviour; a modified computer may form a sculptural part of the artwork.

The Tate project on software-based art preservation, ongoing since October 2017, aims to achieve structured and consistent documentation, disk images of all computer systems, emulated machines from those images where suitable emulation tools exist, and expanded descriptive metadata in its collection management system. The objective is not merely to preserve the programme, but also the systems and metadata required to present it.

Build

Write instructions from scratch:

1. obtain the code;
2. verify the version;
3. install tools;
4. obtain dependencies;
5. configure variables;
6. incorporate data and resources;
7. compile or build;
8. run tests;
9. produce the exhibition artefact.

Record complete commands, working directories, and expected outputs. If a graphical interface is required, describe it with screenshots and values, but also retain the configuration files.

Save the compiler, development environment, or installer when the licence permits. If the project depends on an account or activation, document that fragility.

Installation, startup, and shutdown

An artwork may compile correctly yet fail when exhibited. Add:

• executable installation;
• file deployment;
• permissions;
• automatic startup;
• full-screen mode;
• screen and sound selection;
• calibration;
• behaviour upon restart;
• safe shutdown;
• runtime logs and recovery procedures.

Separate the development procedure from the gallery procedure. The person monitoring an exhibition should not require unnecessary access to the code or administrative credentials.

Configuration and credentials

Provide an example file, such as .env.example, containing variable names and dummy values. Store secrets in a separate manager and record:

• who controls them;
• how they are renewed;
• what permissions they require;
• how they are transferred;
• what occurs if they expire;
• if an offline mode exists.

Never archive active keys in a public repository. If a key forms part of a historical service that no longer exists, preserve the context without exposing reusable credentials.

Data, resources and typefaces

List every dataset, audiovisual file, model, font and resource. For each one:

• name and version;
• provenance;
• licence;
• size and format;
• applied transformation;
• checksum;
• relationship to the artwork;
• possibility of redistribution.

Preserving code without data may result in an empty structure. Preserving data without instructions may render it impossible to interpret.

Containers, virtual machines and disk images

These layers offer varying degrees of encapsulation, according to general technical description:

• container: packages the application and dependencies, yet shares elements with the host system, typically including the kernel;
• virtual machine: retains a more complete guest system, yet depends on the format, hypervisor and emulated hardware;
• disk image: copies storage, including hidden files and configuration, yet requires tools to interpret and boot;
• emulator: reproduces a platform, with potential differences in performance and devices.

Do not present any as a permanent solution. Furthermore, preserve code, manifests, build files, versions, licences and instructions. An image without documentation may boot today and be opaque tomorrow.

Rhizome has managed legacy environments since 2014 and, following a preservation plan, delivers an encapsulated version of the artwork with instructions for independent access. It offers, for example, emulated desktop systems, such as a 1999 version of Mac OS or Windows 98, and encapsulated servers with obsolete versions of ColdFusion or PHP. Tate creates disk images and emulated machines where possible. These are institutional practices, not universal recipes.

External services and network

List APIs, domains, platforms, databases, online sources and authentication. For each service, indicate:

• function;
• endpoint and version;
• terms and costs;
• response format;
• limits;
• data sent;
• behaviour upon failure;
• substitute or local recording, if it exists.

Do not promise reproducible re-execution if an essential part is obtained live and is subject to change. Preserve samples or test responses when lawful and provided they contain no personal data.

Reference outputs

Maintain evidence of correct execution:

• screenshots;
• video and audio;
• artefact checksums;
• expected runtime logs;
• approximate timings;
• test inputs and outputs;
• seeds and parameters;
• known faults.

In generative artwork, compare behaviour and range, not merely an image. The guide What to document in a generative artwork elaborates on seeds, parameters and significant properties.

Reinstallation test

The definitive test is to reconstruct without using the development computer or the author's memory.

1. create a clean environment;
2. start from the preserved package;
3. follow the instructions exclusively;
4. record every undocumented intervention;
5. compare reference outputs;
6. correct documentation and package;
7. repeat until the process is sufficient;
8. date and sign the result.

Do not declare an artwork 'reproducible' if tested only on the machine where it originated. If it cannot be reinstalled, indicate precisely which environment must be preserved.

What to preserve outside the repository

Maintain in a controlled archive:

• large binaries;
• disk images and virtual machines;
• redistributable installers;
• licensed resources;
• restricted data;
• custodied credentials;
• certificates and contracts;
• reference recordings;
• checksums and manifests;
• test reports.

The repository may include references and checksums without exposing that which should not be public.

Public archive, registration and access

Archiving code in a public service does not automatically register the artwork, nor does it alone prove authorship or date. The guide Registering a work with the Intellectual Property Registry explains registration and other proofs.

If you publish the repository, review licences, data, secrets and reservations against text and data mining. Consult how to reserve your rights against data mining.

Checklist

• The approved artistic version is identified by commit or tag.
• A closed package exists in addition to the active repository.
• README, authorship and licences are complete.
• Direct and indirect dependencies have versions.
• Operating system, hardware and drivers are documented.
• Build, installation, startup and shutdown are separated.
• Data, fonts, models and resources appear in the inventory.
• Secrets are custodied outside the repository.
• External services and behaviour upon failure are described.
• Container, virtual machine or disk image have a manifest and instructions.
• Reference outputs exist.
• Another person has completed a reinstallation from scratch.
• Checksums and the test report are preserved.

Further reading

• Preserving a digital artwork.
• What to document in a generative artwork.
• Master artwork record.
• Registering a work with the Intellectual Property Registry.
• How to reserve your rights against data mining.

Sources

• Software Heritage, How to archive and reference your code. Preparation of public repositories, archiving and persistent identifiers; page date: not located.
• Tate, Software-based Art Preservation. Institutional project initiated in October 2017 and ongoing.
• Software Preservation Network. Community dedicated to software preservation and SMRF metadata guide; page date: not located.
• Rhizome, Preservation Services. Legacy environment preservation services, active since 2014; page date: not located.
• Guggenheim, Acquisition Checklist: Computer-based Artwork with Artist-provided Computer. Sample checklist from the conservation department; page date: not located.

Status: Verified. Review: 11 October 2026. This guide does not replace a software conservation assessment or a contract adapted to a specific artwork. If you find a change, a broken link, or an error, write to me.