Reproducibilidad del software

Reproducibilidad del software

Retos y caminos hacia el futuro

Rénich Bon Ćirić <renich@evalinux.com>

¡Bienvenidos! Hoy hablaremos de un tema crucial: cómo asegurar que nuestro software siga funcionando y siendo útil en el futuro.

¿De qué hablamos?

¿Qué es la Reproducibilidad del Software?

Definición:

Capacidad de recrear exactamente el mismo entorno computacional y obtener exactamente los mismos resultados que en una ejecución original. [8]

Diferencia con:

Replicabilidad (resultados similares, métodos diferentes) y Robustez (funciona en differentes condiciones).

¿De qué hablamos?

¿Por qué es importante?

Definir claramente el concepto y enganchar a la audiencia con la importancia práctica y a largo plazo. Diferenciar de replicabilidad.

El Problema

La "Crisis de Reproducibilidad"

El Síntoma Principal:

El software de ayer no funciona hoy o da resultados distintos [8] [40].

  • Ej: Script científico con resultados cambiantes.
Causas Raíz Principales:
  1. "Environment Rot" (Putrefacción del Entorno)
  2. Decaimiento del Software y Dependencias
  3. Problemas de Acceso, Gestión, Formato y Pérdida de Datos

(Las exploraremos a continuación...)

Presentar el problema general y las tres categorías principales que se detallarán.

El Problema

Causas: "Environment Rot"

Putrefacción del Entorno: las condiciones originales desaparecen.

Sistemas Operativos Obsoletos/Desaparecidos:
  • General: Software para arquitecturas/SOs antiguos (ej. SPARC/SunOS, IRIX, VMS) [11].
  • Farmacéutica/Industrial: Equipos controlados por PCs con Windows XP/2000 [7].
  • Música: Software clásico como secuenciadores en Atari ST, Mac OS 9 [47] [50].
  • Petróleo/Gas: Software en estaciones Unix especializadas.
  • Gobierno: Sistemas antiguos accedidos vía emuladores específicos [34].
Dependencias Hardware Específico:

Ej: Control industrial, emulación arcade (MAME).

Librerías/Runtimes Incompatibles:

Ej: Migración Python 2 a Python 3.

Configuraciones Ocultas:

Ej: Variables de entorno en modelos climáticos.

Detallar cómo el entorno (SO, hardware, librerías específicas) se vuelve obsoleto o inaccesible. Usar ejemplos concretos por industria.

El Problema

Causas: Decaimiento del Software y Dependencias

Los componentes se vuelven inutilizables:

Lenguajes/Compiladores en Desuso:
  • Ej: COBOL en banca y seguros, dependencia y falta de expertos [4] [10] [13] [15] [22] [45].
  • Ej: Dialectos específicos de Fortran/Lisp en ciencia.
Librerías/Frameworks Abandonados:
  • Ej: Frameworks JavaScript antiguos con vulnerabilidades sin parchear.
Servicios Externos Desaparecidos:
  • Ej: Dependencia de APIs web (geolocalización, redes sociales) discontinuadas.

Enfocarse en cómo el propio software (lenguaje, librerías, servicios externos) deja de ser mantenido o accesible.

El Problema

Causas: Acceso, Gestión, Formato y Pérdida de Datos

Icono de documento digital con un candado
Digital document with padlock by Mikhail Nilov, via `Pexels <https://www.pexels.com/photo/digital-document-with-padlock-symbolizing-data-security-5380664/>`_, Pexels License

No podemos obtener/usar lo necesario o leer los datos

Licenciamiento Restrictivo/Perdido:
  • Ej: Software CAD/CAM huérfano.
Pérdida del Código Fuente:
  • Ej: Herramientas internas, prototipos sin control de versiones [2] [5] [6] [12].

El Problema

Causas: Acceso, Gestión, Formato y Pérdida de Datos

Inaccesibilidad de Datos por Obsolescencia de Software/Formato:
Falta de Documentación:
  • Ej: Ejecutable científico sin instrucciones.

Aquí el foco es la incapacidad de acceder al software o, crucialmente, a los datos creados por él debido a licencias, pérdida de código o formatos obsoletos. El ejemplo de Flash es muy potente.

Impacto del Problema

Ciencia:

Imposibilidad de verificar/reproducir resultados; crisis de replicación [8] [33] [37] [40].

Industria:

Costos enormes de mantenimiento legacy [4] [42]; riesgos regulatorios/auditoría [4] [7].

Cultura e Historia:

Pérdida irreparable de software y datos; "agujeros negros" de información [1] [18] [20] [28] [29] [30] [36] [44].

Seguridad:

Sistemas críticos vulnerables en SOs obsoletos [4] [22] [34].

Resumir las consecuencias negativas en diferentes ámbitos. Enfatizar la pérdida cultural y los riesgos de seguridad.

Soluciones

Captura del entorno

Contenedores de carga coloridos apilados
Blue, red and yellow cargo containers by Tom Fisk, via `Pexels <https://www.pexels.com/photo/blue-red-and-yellow-cargo-containers-1267338/>`_, Pexels License
Virtualización (VMs):

Emula hardware y SO completos [11] [38].

  • Pros: Captura total.
  • Contras: Pesadas y gestión imágenes.
Contenerización (Docker, Singularity/Apptainer):

Empaqueta app y dependencias directas [38].

  • Pros: Ligeros, estándar.
  • Contras: No captura kernel SO.
Sistemas de Gestión de Entornos (Nix, Guix, Conda):

Definición declarativa y reproducible [14] [16] [23] [38] [39].

  • Pros: Reproducibilidad robusta.
  • Contras: Curva aprendizaje.

Presentar las técnicas para encapsular o definir el entorno de ejecución: VMs (pesado pero completo), Contenedores (ligero, estándar moderno), Gestores de Entorno (declarativo, reproducible).

Soluciones

Gestión del Código y Dependencias

Control de Versiones Riguroso (Git):

Guardar todo (código, scripts, config).

Archivo de Dependencias Explícito (Pinning):

Listar versiones exactas (requirements.txt, package-lock.json).

Archivado de Binarios y Artefactos:

Guardar ejecutables/librerías (Artifactory, Nexus).

Preservación de Código Fuente:

Software Heritage (archivo global de código fuente) [2] [5] [6] [12].

Enfocarse en cómo gestionar el propio código y sus dependencias directas: control de versiones, fijar versiones de librerías, archivar binarios y el rol de Software Heritage.

Soluciones

Gestión de Datos, Formatos y Servicios

Archivado de Datos y Metadatos: Guardar datos exactos + descripción. Usar DOIs.

Gestión Proactiva de Formatos:
  • Priorizar Formatos Abiertos/Estándar (PDF/A, ODF, CSV) [17] [24] [26] [29] [35].
  • Migración Planificada: Convertir datos mientras sea posible [7] [11] [21] [35].
  • Archivado del Software Lector/Editor junto con los datos [21].

Mocking/Simulación de servicios externos.

Abordar el problema de los datos y formatos: archivarlos bien, preferir formatos abiertos, migrar proactivamente y, si es necesario, guardar el software lector junto a los datos.

Soluciones

Documentación y Metodologías

Documentación Exhaustiva:

Instrucciones detalladas (Build, config, ejecución, dependencias). ¡Incluir contexto!

Notebooks Computacionales (Jupyter, R Markdown):

Integran código, datos, resultados y texto. Capturar el entorno subyacente.

Flujos de Trabajo Automatizados (CI/CD):

Pipelines (GitHub Actions, GitLab CI) que validan reproducibilidad en cada cambio.

Interior de un archivo moderno con estanterías móviles
Swedish National Archives Arninge Stockholm 2014 02 by Holger.Ellgaard, via `Wikimedia Commons <https://commons.wikimedia.org/wiki/File:Swedish_National_Archives_Arninge_Stockholm_2014_02.jpg>`_, CC BY-SA 3.0

Destacar la importancia crucial de la documentación y cómo las metodologías modernas (Notebooks, CI/CD) ayudan a la reproducibilidad.

Mejores Prácticas y Recomendaciones

Para Desarrolladores o Investigadores:
  • Usar Git desde el inicio.
  • Documentar TODO.
  • Pinnear versiones de dependencias.
  • Usar Contenedores o Gestores de Entorno.
  • Archivar código y datos (Zenodo, Figshare, Software Heritage).
Para Organizaciones:
  • Fomentar cultura de reproducibilidad.
  • Invertir en infraestructura (CI/CD, repositorios).
  • Establecer políticas de archivado / gestión legacy.
  • Promover licencias abiertas.

Resumen práctico de acciones concretas para individuos y organizaciones.

Retos y Futuro

Retos Actuales:
  • Coste / Complejidad.
  • Resistencia cultural ("funciona en mi máquina").
  • Obsolescencia hardware [11] [26].
  • Sostenibilidad archivos digitales [18].
  • No determinismo (GPUs, IA).
Mirando Hacia Adelante:
  • Adopción Nix/Guix [14] [16] [23] [38] [39].
  • Estándares de entorno.
  • Investigación emulación / preservación [11] [21].
  • "Reproducibility by Design".

Ser realistas sobre los desafíos, pero también mostrar las tendencias y direcciones futuras prometedoras.

Conclusiones

Puente moderno de hormigón curvándose sobre el agua
Gray Concrete Bridge by Tomáš Malík, via `Pexels <https://www.pexels.com/photo/gray-concrete-bridge-and-water-underneath-1138368/>`_, Pexels License

Resumir los puntos clave y dejar un mensaje final inspirador sobre la importancia a largo plazo.

Gracias por tu atención

¿Preguntas?

Renich Bon Ćirić

e-mail:

renich@evalinux.com

telegram:

https://t.me/renichbon

sitio:

https://evalinux.com/

Abrir el turno de preguntas y proporcionar datos de contacto.

Referencias (1/9)

#1:

Adobe (2020). Adobe Flash Player End of Life. https://www.adobe.com/products/flashplayer/end-of-life.html (Fuente oficial sobre EOL)

#2:

Software Heritage. Mission. https://www.softwareheritage.org/mission/ (Descripción oficial)

#3:

Di Cosmo, Roberto; Zacchiroli, Stefano (2017). Software Heritage: Why and How to Preserve Software Source Code. iPRES 2017. https://hal.science/hal-01590958/document (Paper fundacional)

#4:

Reuters Events (2020). The $3 Trillion Question That Banks Must Answer. (Artículo que menciona la dependencia y costes, aunque el original exacto es difícil de encontrar libre, el tema es recurrente). Ver también análisis como [13].

#5:

Construyendo el archivo universal de código fuente. Building the universal archive of source code. https://dl.acm.org/doi/10.1145/3183558 (Comunicado)

#6:

UNESCO / Software Heritage (2019). Software Source Code as Heritage for Sustainable Development. https://unesdoc.unesco.org/ark:/48223/pf0000366715 (Colaboración y reconocimiento patrimonial)

Referencias (2/9)

#7:

FDA (US Food & Drug Administration). Guidance for Industry: Data Integrity and Compliance With Drug CGMP. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/data-integrity-and-compliance-drug-cgmp-questions-and-answers (Relevancia de integridad de datos, aplicable a sistemas legacy)

#8:

Peng, Roger D. (2011). Reproducible Research in Computational Science. Science 334 (6060): 1226–1227. DOI:10.1126/science.1213847 (Paper influyente)

#9:

IBM. What is COBOL? https://www.ibm.com/think/topics/cobol (Descripción general y relevancia actual)

#10:

COBOL on Wikipedia. COBOL https://en.wikipedia.org/wiki/COBOL (Casos de uso, incluyendo banca)

#11:

Digital Preservation Coalition (DPC). Technology Watch Report: Emulation for Digital Preservation. https://doi.org/10.7207/twr12-02 (Aborda obsolescencia y emulación)

#12:

GitHub Archive Program. https://archiveprogram.github.com/ (Iniciativa relacionada con la preservación de código)

Referencias (3/9)

#13:

CAST Software (Reporte/Análisis, ejemplo). Mainframe Modernization: Costs, Risks, and Strategies. (Buscar reportes de esta u otras firmas sobre costes de modernización de mainframe COBOL).

#14:

Dolstra, Eelco; Löh, Andres; Pierron, Nicolas (2010). NixOS: A Purely Functional Linux Distribution. ICFP 2010. https://edolstra.github.io/pubs/nixos-jfp-final.pdf (Sobre NixOS, base de Nix)

#15:

The COBOL Report (Ejemplo de recurso sectorial). https://www.infogoal.com/cbd/ (Sitio dedicado a noticias y análisis sobre COBOL)

#16:

Courtès, Ludovic; Wurmus, Ricardo (2015). Reproducible and User-Controlled Software Environments in HPC with Guix. Euro-Par 2015 Workshops. https://hal.inria.fr/hal-01161771/document (Guix y reproducibilidad)

#17:

PDF/A Association. Competence Center. https://www.pdfa.org/ (Estándar para archivado a largo plazo de documentos)

#18:

Digital Preservation Coalition (DPC). Digital Preservation Handbook: File Formats & Standards. https://www.dpconline.org/handbook/technical-solutions-and-tools/file-formats-and-standards (Guía sobre formatos)

Referencias (4/9)

#20:

Rosenthal, David S. H. (Blog). DSHR's Blog. https://blog.dshr.org/ (Blog influyente sobre preservación digital y sus retos)

#21:

Library of Congress. Recommended Formats Statement. https://www.loc.gov/preservation/resources/rfs/ (Recomendaciones de formatos para preservación)

#22:

McKinsey (2020). Beyond hiring: How companies are reskilling to address talent gaps. (Discute la brecha de habilidades, relevante para COBOL) https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/beyond-hiring-how-companies-are-reskilling-to-address-talent-gaps

#23:

GNU Guix. Features: Reproducible Builds. https://guix.gnu.org/es// (Documentación oficial sobre reproducibilidad en Guix)

#24:

Open Document Format (ODF) Alliance. http://opendocumentformat.org/ (Información sobre el estándar ODF)

Referencias (5/9)

#25:

Hess, Alex (2019). Digital Obsolescence And The Challenge Of Preserving DAW Sessions. Ask.Audio. https://ask.audio/articles/digital-obsolescence-and-the-challenge-of-preserving-daw-sessions (Artículo sobre el problema en música)

#27:

Mozilla Blog (2017). Firefox Roadmap for Flash End-of-Life. https://blog.mozilla.org/futurereleases/2017/07/25/firefox-roadmap-flash-end-life/ (Ejemplo de respuesta de navegador)

#28:

Internet Archive. Flash Animations. https://archive.org/details/softwarelibrary_flash (Esfuerzo por preservar contenido Flash)

#29:

Consejo Internacional de Archivos (ICA). Principios y requisitos funcionales para registros en ambientes electrónicos (MoReq2010). (Buscar el estándar MoReq relevante para gestión documental electrónica)

#30:

UNESCO. Charter on the Preservation of the Digital Heritage (2003). https://unesdoc.unesco.org/ark:/48223/pf0000133171

Referencias (6/9)

#31:

Conifer (formerly Webrecorder). https://conifer.rhizome.org/ (Herramienta para archivar contenido web interactivo, incluyendo Flash vía emulación)

#32:

Ruffle.rs. https://ruffle.rs/ (Emulador de Flash Player escrito en Rust)

#33:

Baker, Monya (2016). 1,500 scientists lift the lid on reproducibility. Nature 533, 452–454. DOI:10.1038/533452a (Encuesta sobre la crisis)

#34:

Cybersecurity & Infrastructure Security Agency (CISA - US Gov). Alerts & Tips. (Buscar alertas sobre vulnerabilidades en sistemas obsoletos usados en gobierno/infraestructura) https://www.cisa.gov/news-events/cybersecurity-advisories

#35:

Archivo General de la Nación (Colombia). Guía para la elaboración e implementación del Plan de Preservación Digital. https://www.archivogeneral.gov.co/caja_de_herramientas/GUIA_PLAN_PRESERVACION_DIGITAL_2021.pdf

#36:

Pérez, Karolina; Garduño, Guillermo (2009). Preservación del patrimonio documental digital en el mundo y en México. Investigación Bibliotecológica, vol. 23, núm. 49. https://www.scielo.org.mx/scielo.php?script=sci_arttext&pid=S0187-358X2009000200005

Referencias (7/9)

#37:

Stodden, Victoria; Miguez, Sheila; Seibold, John (Eds.) (2019). Reproducibility and Replicability in Science. National Academies Press. DOI:10.17226/25303 (Reporte comprensivo)

#38:

Boettiger, Carl (2015). An introduction to Docker for reproducible research. ACM SIGOPS Operating Systems Review 49(1): 71-79. DOI:10.1145/2723872.2723882 (Docker en investigación)

#39:

NixOS Foundation. Nix: The Purely Functional Package Manager. https://nixos.org/nix/ (Sitio oficial de Nix)

#40:

Chirigati, Fernando; Rampin, Rémi; Shaffer, Dennis; Freire, Juliana (2016). ReproZip: Computational Reproducibility With Ease. SIGMOD '16. DOI:10.1145/2882903.2903741 (Herramienta para empaquetar entornos)

#41:

Wikipedia. Replication crisis. https://en.wikipedia.org/wiki/Replication_crisis (Resumen del concepto)

#42:

Jones, Capers (2010). Software Engineering Best Practices. McGraw-Hill. (Libro clásico que aborda costes de mantenimiento, aunque no específicamente COBOL).

Referencias (8/9)

#43:

Sneed, Harry M. (Varias publicaciones). (Buscar trabajos de Sneed sobre mantenimiento y reingeniería de software COBOL).

#44:

Preserving Virtual Worlds (Proyecto). https://pvw.illinois.edu/ (Ejemplo de proyecto de preservación de entornos complejos)

#45:

IBM. Modernize mainframe applications. https://www.ibm.com/thought-leadership/institute-business-value/report/mainframe-modernization (Perspectiva de un proveedor sobre modernización COBOL)

#46:

Accenture (Reporte/Análisis, ejemplo). Mainframe Modernization Services. (Buscar análisis de consultoras sobre estrategias de modernización COBOL).

#47:

Austin, Colin (Blog - 2019). Music software and hardware: obsolescence and longevity. https://colinaustin.com/2019/10/14/62-music-software-and-hardware-obsolescence-and-longevity/ (Perspectiva personal sobre el tema en música)

#48:

Hepworth-Sawyer, Russ; Hodgson, Jay; Paterson, Justin; Toulson, Rob (Eds.) (2019). Innovation in Music: Performance, Production, Technology, and Business. Routledge. (Libro que puede tocar temas de obsolescencia tecnológica en música).

Referencias (9/9)

#49:

Butler, Mark J. (2014). Playing with Something That Runs: Technology, Improvisation, and Composition in DJ and Laptop Performance. Oxford University Press. (Analiza el rol de la tecnología, incluyendo DAWs, en la performance).

#50:

Théberge, Paul (1997). Any Sound You Can Imagine: Making Music/Consuming Technology. Wesleyan University Press. (Libro clásico sobre tecnología musical y su impacto, relevante para entender software antiguo).

EVALinux https://evalinux.com/