Cómo preparar código creativo para que vuelva a ejecutarse

Tener el código fuente no garantiza que una obra vuelva a funcionar. Puede faltar la versión exacta de una biblioteca, el compilador, una tipografía, datos de entrada, una clave, un dispositivo o un paso que solo recuerda quien la programó.

Preparar código creativo para el futuro significa conservar un sistema reproducible y explicar cómo comprobarlo. El objetivo no es congelarlo para siempre, sino reducir la dependencia de memoria tácita y hacer visibles las decisiones que requerirá una futura migración.

La guía Conservar una obra digital sitúa el código dentro del conjunto de archivos de la obra. Esta se concentra en el paquete técnico.

Empieza por un inventario

Antes de ordenar el repositorio, anota qué existe:

• repositorio y ramas relevantes;
• versión artística aprobada;
• código fuente;
• binarios o ejecutables;
• datos y recursos;
• dependencias directas e indirectas;
• herramientas de construcción;
• sistema operativo y hardware;
• configuraciones y variables de entorno;
• servicios externos;
• documentación y resultados de referencia;
• licencias y restricciones.

Vincula el inventario con la ficha maestra de obra. No mezcles secretos, datos personales o materiales cuya redistribución esté prohibida dentro de un paquete público.

Dos modelos institucionales sirven de referencia. La lista de verificación de adquisición del Guggenheim para obras basadas en ordenador pide todos los activos necesarios para ejecutar la obra, el código fuente o los archivos de proyecto, copias de las bibliotecas utilizadas, una lista escrita de requisitos y dependencias de hardware y software, instrucciones de instalación y arranque, credenciales, una relación de servicios web externos y documentación en vídeo o audio de la obra funcionando correctamente. Por su parte, el Software Preservation Network publica una guía de formato recomendado de metadatos de software (SMRF). Ninguno de los dos es un estándar obligatorio.

Código fuente, historial y versión aprobada

Un repositorio de control de versiones conserva cambios, pero no dice por sí solo qué commit constituye la obra. Marca una versión aprobada mediante etiqueta o referencia inmutable y registra:

• título de la obra e identificador;
• repositorio;
• commit o revisión;
• etiqueta de versión;
• fecha de aprobación;
• rama de desarrollo;
• persona responsable.

Conserva el historial cuando explique decisiones o permita reconstruir, pero crea también un paquete cerrado de la versión aprobada. Un repositorio remoto puede cambiar, cerrarse o perder archivos grandes que se almacenan por otra vía.

Software Heritage archiva repositorios de código público que puedan clonarse y permite referenciar versiones mediante identificadores persistentes (SWHID), que describe como estándar internacional ISO/IEC. Inferencia propia, no una declaración de Software Heritage: el archivo de Software Heritage parte del repositorio público. Los binarios, datos, dependencias privadas, credenciales e instrucciones que no estén en ese repositorio requieren un archivo distinto.

README, autores y licencia

Incluye en la raíz:

• README: finalidad, estructura, instalación y ejecución;
• AUTHORS: personas y funciones;
• LICENSE o relación de licencias;
• historial de cambios o enlace a él;
• cita recomendada, si procede;
• metadatos legibles por máquinas, como codemeta.json, cuando resulten útiles.

Software Heritage recomienda añadir un README, un archivo AUTHORS y la información de licencia antes de archivar un repositorio público, y presenta codemeta.json como metadato opcional legible por máquinas. La licencia del código y la de la obra o sus salidas pueden ser distintas: no des por supuesto que una cubre la otra.

Dependencias completas y versiones

No documentes solo los paquetes que importas directamente. Conserva:

• gestor y versión;
• manifiesto de dependencias;
• archivo de bloqueo, si existe;
• repositorios, registros o espejos utilizados;
• dependencias obtenidas manualmente;
• bibliotecas nativas y controladores;
• modelos, fuentes y códecs;
• sumas de verificación de paquetes críticos;
• licencias.

Evita expresiones como «usar la última versión». Fija la versión probada. Si una dependencia no puede redistribuirse, registra nombre, versión, procedencia y procedimiento legítimo de obtención.

Una lista de paquetes no garantiza que sigan disponibles. Cuando la licencia lo permita, conserva copias. Cuando no, documenta alternativas y restricciones.

Sistema operativo y hardware

Registra:

• sistema operativo, edición, arquitectura y versión;
• núcleo o compilación cuando sea relevante;
• procesador y arquitectura;
• memoria y almacenamiento mínimos;
• tarjeta gráfica y controlador;
• resolución, frecuencia y número de pantallas;
• interfaz de audio y canales;
• sensores, cámaras, controladores y firmware;
• conexiones de red y periféricos.

Distingue requisito material de propiedad significativa. Una GPU concreta puede ser sustituible si mantiene el comportamiento; un ordenador modificado puede formar parte escultórica de la obra.

El proyecto de Tate sobre conservación de arte basado en software, en curso desde octubre de 2017, se propone lograr documentación estructurada y consistente, imágenes de disco de todos los sistemas informáticos, máquinas emuladas a partir de esas imágenes cuando existan herramientas de emulación adecuadas, y metadatos descriptivos ampliados en su sistema de gestión de colecciones. El objetivo no es conservar únicamente el programa, sino también los sistemas y metadatos necesarios para presentarlo.

Compilación

Escribe instrucciones desde cero:

1. obtener el código;
2. verificar la versión;
3. instalar herramientas;
4. obtener dependencias;
5. configurar variables;
6. incorporar datos y recursos;
7. compilar o construir;
8. ejecutar pruebas;
9. producir el artefacto de exhibición.

Registra comandos completos, directorios de trabajo y salidas esperadas. Si hace falta una interfaz gráfica, descríbela con capturas y valores, pero conserva también los archivos de configuración.

Guarda el compilador, entorno de desarrollo o instalador cuando la licencia lo permita. Si el proyecto depende de una cuenta o activación, documenta esa fragilidad.

Instalación, arranque y apagado

Una obra puede compilar correctamente y fallar al exhibirse. Añade:

• instalación del ejecutable;
• despliegue de archivos;
• permisos;
• inicio automático;
• modo de pantalla completa;
• selección de pantalla y sonido;
• calibración;
• comportamiento ante reinicio;
• cierre seguro;
• registros de funcionamiento y recuperación.

Separa procedimiento de desarrollo y procedimiento de sala. La persona que vigila una exposición no debería necesitar acceso innecesario al código ni a credenciales de administración.

Configuración y credenciales

Proporciona un archivo de ejemplo, como .env.example, con nombres de variables y valores ficticios. Guarda los secretos en un gestor separado y registra:

• quién los controla;
• cómo se renuevan;
• qué permisos necesitan;
• cómo se transfieren;
• qué ocurre si caducan;
• si existe modo sin conexión.

Nunca archives claves activas en un repositorio público. Si una clave forma parte de un servicio histórico que ya no existe, conserva el contexto sin exponer credenciales reutilizables.

Datos, recursos y tipografías

Lista cada conjunto de datos, archivo audiovisual, modelo, fuente y recurso. Para cada uno:

• nombre y versión;
• procedencia;
• licencia;
• tamaño y formato;
• transformación aplicada;
• suma de verificación;
• relación con la obra;
• posibilidad de redistribución.

Conservar código sin datos puede conservar una estructura vacía. Conservar datos sin instrucciones puede hacer imposible interpretarlos.

Contenedores, máquinas virtuales e imágenes de disco

Estas capas ofrecen distintos grados de encapsulado, según descripción técnica general:

• contenedor: empaqueta aplicación y dependencias, pero comparte elementos con el sistema anfitrión, incluido habitualmente el núcleo;
• máquina virtual: conserva un sistema invitado más completo, pero depende del formato, el hipervisor y el hardware emulado;
• imagen de disco: copia un almacenamiento, incluidos archivos ocultos y configuración, pero necesita herramientas para interpretarse y arrancar;
• emulador: reproduce una plataforma, con posibles diferencias de rendimiento y dispositivos.

No presentes ninguna como solución permanente. Conserva además código, manifiestos, archivos de construcción, versiones, licencias e instrucciones. Una imagen sin documentación puede arrancar hoy y ser opaca mañana.

Rhizome gestiona entornos heredados desde 2014 y, tras un plan de preservación, entrega una versión encapsulada de la obra con instrucciones para acceder a ella de forma independiente. Ofrece, por ejemplo, sistemas de escritorio emulados, como una versión de Mac OS o Windows 98 de 1999, y servidores encapsulados con versiones obsoletas de ColdFusion o PHP. Tate crea imágenes de disco y máquinas emuladas cuando es posible. Son prácticas institucionales, no recetas universales.

Servicios externos y red

Lista API, dominios, plataformas, bases de datos, fuentes en línea y autenticación. Para cada servicio indica:

• función;
• punto de acceso y versión;
• términos y costes;
• formato de respuesta;
• límites;
• datos enviados;
• comportamiento ante caída;
• sustituto o grabación local, si existe.

No prometas reejecución reproducible si una parte esencial se obtiene en vivo y puede cambiar. Conserva muestras o respuestas de prueba cuando sea lícito y no contengan datos personales.

Resultados de referencia

Mantén evidencia de una ejecución correcta:

• capturas;
• vídeo y audio;
• sumas de verificación de artefactos;
• registros esperados;
• tiempos aproximados;
• entradas y salidas de prueba;
• semillas y parámetros;
• fallos conocidos.

En obra generativa, compara comportamiento y rango, no solo una imagen. La guía Qué documentar en una obra generativa desarrolla semillas, parámetros y propiedades significativas.

Prueba de reinstalación

La prueba decisiva es reconstruir sin utilizar el ordenador de desarrollo ni la memoria del autor.

1. crea un entorno limpio;
2. parte del paquete conservado;
3. sigue únicamente las instrucciones;
4. registra cada intervención no documentada;
5. compara resultados de referencia;
6. corrige documentación y paquete;
7. repite hasta que el proceso sea suficiente;
8. fecha y firma el resultado.

No declares «reproducible» una obra probada solo en la máquina donde nació. Si no puede reinstalarse, indica con precisión qué entorno debe preservarse.

Qué conservar fuera del repositorio

Mantén en un archivo controlado:

• binarios grandes;
• imágenes de disco y máquinas virtuales;
• instaladores redistribuibles;
• recursos licenciados;
• datos reservados;
• credenciales custodiadas;
• certificados y contratos;
• grabaciones de referencia;
• sumas de verificación y manifiestos;
• informes de prueba.

El repositorio puede incluir referencias y sumas de verificación sin exponer aquello que no debe ser público.

Archivo público, registro y acceso

Archivar código en un servicio público no registra automáticamente la obra ni prueba por sí solo autoría o fecha. La guía Cómo registrar una obra en el Registro de la Propiedad Intelectual explica la inscripción y otras pruebas.

Si publicas el repositorio, revisa licencias, datos, secretos y reservas frente a minería. Consulta cómo reservar tus derechos frente a la minería de datos.

Lista de comprobación

• La versión artística aprobada está identificada por commit o etiqueta.
• Existe un paquete cerrado además del repositorio activo.
• README, autoría y licencias están completos.
• Dependencias directas e indirectas tienen versión.
• Sistema operativo, hardware y controladores están documentados.
• Compilación, instalación, arranque y apagado están separados.
• Datos, fuentes, modelos y recursos figuran en el inventario.
• Los secretos se custodian fuera del repositorio.
• Servicios externos y comportamiento ante caída están descritos.
• Contenedor, máquina virtual o imagen de disco tienen manifiesto e instrucciones.
• Existen resultados de referencia.
• Otra persona ha completado una reinstalación desde cero.
• Se conservan sumas de verificación y el informe de la prueba.

Para seguir

• Conservar una obra digital.
• Qué documentar en una obra generativa.
• Ficha maestra de obra.
• Cómo registrar una obra en el Registro de la Propiedad Intelectual.
• Cómo reservar tus derechos frente a la minería de datos.

Fuentes

• Software Heritage, How to archive and reference your code. Preparación de repositorios públicos, archivo e identificadores persistentes; fecha de página: no localizada.
• Tate, Software-based Art Preservation. Proyecto institucional iniciado en octubre de 2017 y en curso.
• Software Preservation Network. Comunidad dedicada a la preservación de software y guía de metadatos SMRF; fecha de página: no localizada.
• Rhizome, Preservation Services. Servicios de preservación de entornos heredados, activos desde 2014; fecha de página: no localizada.
• Guggenheim, Acquisition Checklist: Computer-based Artwork with Artist-provided Computer. Lista de ejemplo del departamento de conservación; fecha de página: no localizada.

Estado: Verificada. Revisión: 11 de octubre de 2026. Esta guía no sustituye una evaluación de conservación de software ni un contrato adaptado a una obra concreta. Si encuentras un cambio, un enlace roto o un error, escríbeme.