El software open source es el nuevo método científico

Por qué el software open source es ya ciencia

Una auditoría publicada en marzo de 2026 en Royal Society Open Science intentó reproducir los resultados de 100 artículos de ciencias sociales basadas en encuestas: solo alrededor del 18% de los hallazgos fueron exactamente reproducibles, y únicamente el 35% de los autores compartieron su código de análisis cuando se les pidió. La cifra resume un problema de fondo: si la mitad de los resultados publicados dependen de un script que nadie fuera del laboratorio puede ejecutar, ¿qué está fallando en el método científico?

Para el ingeniero y bloguero Jeppe Pedersen, la respuesta es directa: en la era computacional, el software open source ES el método científico. No es una metáfora ni una exageración académica: es la forma en que hoy se codifican, comparten y verifican los modelos predictivos que la humanidad usa para entender el universo. Si tu startup entrena modelos, procesa datos clínicos o toma decisiones basadas en simulaciones, este debate no es teórico: define la confianza que clientes, reguladores e inversores podrán tener en tu producto.

Qué es ciencia, en términos prácticos

Pedersen parte de la definición clásica de Wikipedia: la ciencia es una disciplina sistemática que construye conocimiento en forma de hipótesis testeables y predicciones sobre el universo. Hasta ahí, un paper en arXiv cumple el requisito sobre el papel.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

El problema aparece cuando otro investigador intenta tomar esa idea, embeberla en su propio modelo mental, adaptarla y construir sobre ella, que es justo lo que Pedersen considera el verdadero acto científico. El filósofo Kenneth Craik lo llamó "modelos internos a pequeña escala": entidades que usamos para explicar y predecir el mundo. Un paper que no permite esta transferencia no contribuye ciencia, contribuye ruido.

Aquí entra el software. Los modelos matemáticos del paper de física clásico se publicaban como ecuaciones que cualquier podía revisar. Hoy, los modelos predictivos son código que se ejecuta, y si ese código no está disponible ni es ejecutable, la predicción no se puede verificar. La reproducibilidad, en este sentido estricto, no es replicar gráficos: es poder tomar la idea, adaptarla y construir sobre ella. Cuando eso no es posible, los hallazgos no se expanden y se vuelven inútiles.

La crisis de reproducibilidad ya está costando millones

El ejemplo más citado es NanoBubbles, un proyecto europeo de US$9,5 millones financiado por el European Research Council para investigar la autocorrección en ciencia. En febrero de 2026, el equipo publicó una convocatoria abierta invitando a otros nanoscientists a intentar replicar un paper de 2012 que afirmaba que puntos cuánticos fluorescentes podían detectar iones de cobre dentro de células vivas, un hallazgo con potencial relevancia médica. Tras meses de intentos, no lograron replicar los resultados: la fluorescencia de las partículas simplemente no respondía como describía el protocolo original. El caso es uno de los primeros grandes esfuerzos de las ciencias físicas por abordar lo que en psicología y ciencias sociales lleva más de una década en discusión.

Los números de la auditoría de LMU citada arriba lo confirman: para dos tercios de los estudios de ciencias sociales analizados, no fue posible reconstruir cómo los autores llegaron a sus resultados. Un 23% de las reproducciones falló por materiales incompletos o mal documentados, y un 26% adicional mostró desviaciones numéricas. El mensaje es incómodo: gran parte de la literatura publicada hoy depende de una confianza casi ciega en software que nadie fuera del laboratorio puede ejecutar.

Cómo el código abierto encarna el método científico

Pedersen identifica dos propiedades que el software científico necesita para ser ciencia de verdad:

Reproducible: ejecutable y modificable. Cualquier investigador debe poder correr el código, ajustarlo y verificar el resultado.
Confiable: los resultados deben ser sistemáticamente correctos, no flaky ni dependientes de un entorno específico.

El open source entrega ambas por construcción. Puedes cambiar el código y adaptarlo a tus necesidades (como ocurre cotidianamente con los modelos de Hugging Face), y puedes iterar sobre él para mejorarlo. El ecosistema ya genera billones en valor y, según el argumento de Pedersen, hay espacio para mucho más.

Un ejemplo concreto de lo que se puede construir: el colectivo Openverse, un equipo de 41 investigadores de VR publicó en 2026 en PNAS unos protocolos abiertos para investigación conductual en realidad virtual, con listas de verificación interactivas que cualquier laboratorio puede adoptar. El paper señala un problema conocido: los estudios de VR suelen estar atados a hardware y software propietarios, obligando a reconstruir experimentos desde cero. Los protocolos proponen motores comunes, estándares abiertos y licencias claras para que las simulaciones viajen entre laboratorios y sobrevivan al cambio tecnológico.

Pedersen también menciona el caso de la neuromórfica, una disciplina pequeña donde un paper reciente en Nature señala que el software open source es clave para escalar. La guía Open Neuromorphic funciona como un directorio de librerías cercanas al campo, y muestra un patrón replicable: cuando el software está fragmentado y propietario, el conocimiento se estanca; cuando es compartido y mantenible por una comunidad, el campo acelera.

¿Qué significa esto para tu startup?

Si tu empresa toca ciencia, datos, IA o simulaciones, el argumento de Pedersen se traduce en decisiones concretas que afectan tu velocidad de iteración, la confianza de tus clientes y, eventualmente, tu capacidad de levantar capital.

Acción 1: Publica tu código desde el día uno, aunque sea feo. No esperes a tener un paper o un MVP pulido para abrir tu repositorio. Un paper sin código es menos científico y más difícil de construir encima, dice Pedersen; lo mismo vale para un producto. Herramientas como GitHub, Zenodo o NixOS (que Pedersen recomienda por encima de Docker o Conda para entornos reproducibles a largo plazo) permiten fijar dependencias y entornos para que tu código funcione igual hoy y en cinco años, incluso si cambias de proveedor cloud o de sistema operativo.

Acción 2: Construye sobre herramientas existentes en lugar de reinventar la rueda. El objetivo del open source científico es que el conocimiento común avance, no que cada equipo resuelva los mismos problemas básicos una y otra vez. Antes de escribir tu propio framework de evaluación, busca en Hugging Face, en Papers with Code, en las guías de Open Neuromorphic o en la documentación oficial del método que estés usando. Reutilizar no es falta de originalidad: es la forma en que la ciencia ha avanzado siempre.

El mensaje de fondo es simple y exigente: si dependes de software para tomar decisiones, ese software debe ser ejecutable, modificable y verificable por terceros. No por una cuestión ideológica, sino porque sin reproducibilidad no hay ciencia, y sin ciencia no hay confianza. Para un founder, eso se traduce en una pregunta incómoda pero rentable: ¿podría un cliente, un regulador o un inversor externo ejecutar tu código y obtener tu mismo resultado?