Autor: Juan Galt
Compilación: AididiaoJP, Foresight News
El debate entre código abierto y código cerrado ha persistido en Bitcoin e incluso en toda la industria cripto durante más de una década. Los partidarios de Bitcoin han defendido durante mucho tiempo: la infraestructura financiera global debe construirse de forma pública, la transparencia y la capacidad de auditoría son principios no negociables cuando se trata de dinero real. Sin embargo, la capa de aplicación y las finanzas tradicionales a menudo no lo aceptan.
El reciente robo de la billetera de hardware Coldcard ha llevado el verdadero significado del término "código abierto" al centro de la controversia. Los usuarios perdieron más de 100 millones de dólares en Bitcoin (más de 1500 BTC). Este incidente revela una realidad incómoda: incluso muchos usuarios acérrimos de Bitcoin tienen una comprensión bastante limitada de la filosofía del desarrollo de software de código abierto y de sus escenarios de falla.
Principios y terminología
La terminología relacionada con el código abierto no es sencilla. El Software Libre y de Código Abierto (FOSS, por sus siglas en inglés) y el Software Libre/Abierto (FLOSS) se refieren a software que cumple con las definiciones formales de libertades del usuario.
La Free Software Foundation (FSF) define el "software libre" mediante cuatro libertades fundamentales:
- Libertad 0: Ejecutar el programa como se desee, para cualquier propósito.
- Libertad 1: Estudiar cómo funciona el programa y modificarlo para adaptarlo a las propias necesidades (requiere tener acceso al código fuente).
- Libertad 2: Redistribuir copias para ayudar a otros.
- Libertad 3: Distribuir versiones modificadas propias a otros (también requiere el código fuente como prerrequisito).
La FSF enfatiza que "libre" (free) se refiere a libertad, no a gratuidad. El mantra de los defensores del código abierto es: "'Libre' como en 'libertad de expresión', no como en 'cerveza gratis'."
La definición de código abierto de la Open Source Initiative (OSI) enumera diez criterios prácticos adicionales, que incluyen: redistribución libre sin regalías, el código fuente debe proporcionarse en una forma adecuada para la modificación, permitir la creación y distribución de trabajos derivados, y no discriminar a personas, grupos o usos (incluido el uso comercial). Solo las licencias que cumplan completamente con estos diez criterios pueden denominarse formalmente "código abierto".
El "código fuente visible" (source available) o "código accesible" es otra cosa. El código puede leerse públicamente, pero la licencia puede restringir los derechos de venta comercial. El firmware de Coldcard es un ejemplo: utiliza la licencia MIT, pero con una cláusula de licencia adicional. Esta cláusula prohíbe explícitamente la "venta" del software, definida como proporcionar el software a terceros a cambio de una tarifa u otra contraprestación, cuando el valor del producto o servicio proviene total o sustancialmente del software en sí. En otras palabras, el firmware de Coldcard no puede usarse con fines comerciales.
La cláusula de licencia es muy clara: "¿Es esto código abierto? No." Señala que, al agregar esta cláusula, el software cumple con muchos elementos de la definición de código abierto, pero no con todos, por lo que no debería llamarse código abierto.
Estas distinciones son importantes. Hacer público el código fuente solo crea la posibilidad de ser inspeccionado; otorgar todas las libertades de la definición de software libre o código abierto es lo que constituye FOSS. Pero llevar la insignia de "código abierto" no es un fin en sí mismo. Los críticos argumentan que la libertad comercial dentro del código abierto es lo que desbloquea los incentivos para que terceros prueben y revisen el código; de lo contrario, estos incentivos podrían no existir.
Las cuatro libertades son el núcleo filosófico del código abierto. Pero en la práctica, se basa en una suposición económica: que habrá suficientes personas motivadas que realmente revisarán el código. Cuando esta suposición falla, el sistema reproduce la clásica "tragedia de los comunes": un recurso compartido se degrada por el interés propio a corto plazo de los individuos, ya sea por sobreexplotación o abandono. Todos tienen incentivos para tomar un poco más (o contribuir un poco menos), resultando en el deterioro del recurso colectivo. A veces los incentivos están alineados, a veces no.
Un desarrollador de Bitcoin lo expresa de manera más directa: "El uso de dobles de prueba (mocks y stubs) de código abierto en pruebas es irresponsable y miope. Se considera que el código abierto es seguro porque cualquiera puede verificarlo. Si ni siquiera estás dispuesto a realizar las pruebas mínimas de las funcionalidades de las que realmente dependes, entonces estás siendo un parásito."
Por lo tanto, el código abierto en sí mismo no crea automáticamente seguridad, solo crea la posibilidad de verificación. Que la verificación ocurra realmente depende de los incentivos, las habilidades y la atención. Históricamente, el FOSS de calidad se fortalece gradualmente a medida que se descubren, divulgan y corrigen vulnerabilidades, convirtiéndose en una base sólida para que otros construyan. El kernel de Linux es un ejemplo clásico: impulsa la gran mayoría de servidores, infraestructuras en la nube, dispositivos Android y sistemas integrados a nivel mundial, siendo uno de los softwares más ampliamente desplegados de la historia.
Bitcoin Core: Un modelo de la realidad del código abierto
Bitcoin Core, como la implementación de referencia de Bitcoin, es otro caso clásico de código abierto puro a gran escala en funcionamiento en el mundo real. Utiliza la licencia MIT, y su proceso de desarrollo está diseñado para ser público desde el principio.
Cualquiera puede enviar una solicitud de extracción (pull request). La revisión de código es el principal mecanismo de filtro y también la ruta de entrada recomendada para los nuevos. Los revisores utilizan terminología formal: Concept ACK (de acuerdo con el objetivo), Approach ACK (de acuerdo con el objetivo y método), ACK con hash de commit específico (probado y aprobado para fusión), o NACK (en desacuerdo, requiere razones técnicas).
Los mantenedores sopesan el consenso de los contribuyentes y los méritos técnicos antes de fusionar. Los cambios críticos que requieren consenso tienen un umbral más alto, generalmente necesitan una Propuesta de Mejora de Bitcoin (BIP) y una discusión extensa durante años en las listas de correo bitcoin-dev y en IRC.
Aquí no existe una clase privilegiada de "desarrolladores de Bitcoin Core". La confianza se gana demostrando capacidad a largo plazo. Los mantenedores existen solo por necesidad práctica: auditar el código a fusionar, gestionar lanzamientos, revisión básica; pero el resultado es código de código abierto puro que cualquiera puede inspeccionar, compilar, bifurcar o ejecutar. A quienes su código es fusionado en Bitcoin Core, normalmente se les llama contribuidores de Bitcoin Core.
El desarrollador de código abierto de Bitcoin a largo plazo, Calle, resumió recientemente: "Aquellos que piensan que Core es algún tipo de institución que opera opacamente en las sombras, o son demasiado perezosos, o demasiado tontos como para echar un vistazo ellos mismos. Todo lo que hacen es público, cualquiera puede participar y el resultado final es código de código abierto puro."
La financiación de este trabajo proviene principalmente de estructuras sin fines de lucro y de patrocinio, como Brink, OpenSats, Spiral, etc., no de las hojas de ruta de productos de empresas tradicionales. Las discusiones técnicas tienen lugar en las listas de correo públicas bitcoin-dev y en el canal IRC #bitcoin-core-dev de Libera Chat, y las propuestas son examinadas rigurosamente antes y después de enviar una pull request. Los issues y pull requests en GitHub a menudo tienen historiales de comentarios de hasta una década. El resultado es una cultura de desarrollo que prioriza la corrección y la capacidad de auditoría sobre la velocidad o la rapidez en la iteración de funciones comerciales.
La economía del código abierto
La mayoría de los usuarios de software de código abierto o código visible nunca leen el código ellos mismos. Confían en la suposición de que "otra persona lo está revisando". En el caso de Coldcard, un defecto crítico en la entropía permaneció latente en el firmware público durante aproximadamente cinco años, antes de ser explotado y, por tanto, descubierto.
Este bug fue introducido durante una importante reescritura en 2021. Esa reescritura también eliminó el código GPL residual proveniente de Trezor. Trezor fue la primera billetera de hardware y actualmente es la segunda más grande en la industria del auto-custodio. La biblioteca central del problema se llama libngu, que reemplazó a trezor-crypto, pero recibió muy poca revisión externa; después de más de cinco años en producción, solo tenía 7 estrellas y menos de 20 bifurcaciones (forks). En comparación, trezor-crypto tiene 512 estrellas y 212 bifurcaciones, y el más moderno trezor-firmware tiene 793 bifurcaciones y 1800 estrellas. El código fuente visible en sí mismo no generó la revisión realmente significativa. Los críticos argumentan que la razón es la falta de incentivos comerciales, ya que otras empresas rentables con fondos y capacidad tenían restringido su uso. Nota: "Star" (estrella) y "Fork" (bifurcación) son dos métricas centrales en GitHub para medir la popularidad y actividad de un proyecto; "Star" significa marcar como favorito/dar me gusta; "Fork" significa copiar el repositorio.
Las apuestas en el ecosistema de Bitcoin son mucho más altas que en la mayoría de los ámbitos del software. Un defecto crítico puede convertirse directamente en liquidez en el mercado abierto. La primera mitad de los fondos robados de Coldcard aún se mantiene en unas pocas direcciones; el hacker podría ser atrapado algún día, pero los imitadores posteriores son más cautelosos, y algunos ya han logrado robar más Bitcoin y blanquearlo (según datos de Galaxy Research, las pérdidas totales alcanzan al menos 1700 BTC). La naturaleza resistente a la censura y las transacciones inmutables de Bitcoin proporcionan tanto un fuerte incentivo para los atacantes como una selección darwiniana: solo aquellos proyectos que atraigan continuamente revisiones de alta calidad, y donde usuarios y empresas tomen seriamente medidas de protección, tendrán posibilidades de supervivencia a largo plazo.
La elección de la licencia modela estos incentivos. Las licencias de código abierto puro maximizan el grupo potencial de revisores y bifurcaciones. Por otro lado, las licencias restrictivas de "código visible", si bien pueden reducir el "free-riding" comercial, también reducen el grupo de personas que tienen tanto el derecho legal como el incentivo económico para dedicar atención profunda. En consecuencia, la carga de la revisión del código recae nuevamente en la propia empresa, acercándola en cierto modo más al código cerrado que al abierto.
Cómo la IA está cambiando el desarrollo abierto y cerrado
La inteligencia artificial está cambiando el equilibrio entre código abierto y cerrado.
Tras el incidente de Coldcard, un proyecto voluntario liderado por desarrolladores como Calle y Rob Hamilton de AnchorWatch, con el apoyo de OpenSats llamado Bitcoin Red Team, escaneó cientos de repositorios de código abierto de Bitcoin utilizando modelos de IA de vanguardia. En un período intensivo, el equipo presentó miles de hallazgos, decenas de los cuales fueron calificados como críticos o de alta gravedad, cubriendo cientos de proyectos. La divulgación responsable se realizó primero a los mantenedores y luego al público. Esto demostró que la revisión asistida por IA sistemática puede descubrir vulnerabilidades a una escala y velocidad previamente inalcanzables para equipos humanos.
Vale la pena destacar que Bitcoin Red Team encontró que los modelos de código abierto chinos eran mucho más confiables que los modelos cerrados estadounidenses. Incluso los modelos estadounidenses con acceso a la red y privilegios de primer nivel se negaron a responder las consultas de Bitcoin Red Team, lo que dejó a los desarrolladores estadounidenses bastante decepcionados.
Mientras tanto, el torrente de código generado por IA está ejerciendo una nueva presión de "denegación de servicio" sobre los mantenedores de FOSS. Revisar la salida de la IA a menudo lleva más tiempo que generarla. Algunos proyectos de código abierto fuera de Bitcoin ya han comenzado a limitar los rastreadores de issues (issue trackers) o a establecer reglas estrictas contra contribuciones de IA, solo para mantener el funcionamiento básico.
En el lado del código cerrado, la ventaja tradicional de la "seguridad por oscuridad" se está erosionando. Los modelos modernos de IA pueden leer, desofuscar, sondear endpoints y razonar sobre el código a velocidades extremadamente altas. La diferencia práctica entre código abierto y cerrado hoy en día reside principalmente en el código backend que nunca se sube en línea. El código cerrado finalmente solo puede depender de la calidad de las auditorías profesionales, la velocidad de implementación de parches y de estructuras de incentivos que mantengan a las personas autorizadas revisando seriamente de manera continua.
Bitcoin y la industria cripto en general están ejerciendo una presión inusual sobre el software libre y de código abierto. El valor monetario real, la economía adversarial y ahora el análisis a escala con IA están forzando a evolucionar los modelos de software. Volver a sistemas analógicos predigitales prácticamente no es una opción para la infraestructura que sostiene la sociedad moderna. Solo los proyectos que estén suficientemente auditados tendrán posibilidades de sobrevivir bajo la presión combinada de los hackers asistidos por IA y las finanzas digitales prioritarias.
