Si sigues temas de código abierto en X/Twitter, se te puede perdonar que creas que el mayor problema actual en el código abierto es que las empresas vuelven a otorgar licencias de su código fuente abierto bajo diferentes licencias. Thierry Carrez, vicepresidente de la OSI, por ejemplo, recientemente emitió una terrible advertencia: «el proveedor único es el nuevo propietario». Suena terrible, ¿verdad? Quiero decir, una vez que olvides que la gran mayoría del software que tú y yo usamos todos los días en nuestros teléfonos, computadoras portátiles, servidores, etc., es propietario. (Sí, con una gran cantidad de código abierto enterrado en su interior y efectivamente “con nuevas licencias”).
He aquí sólo un pequeño dato que hace que estas preocupaciones parezcan tontas: de las más de 10.000 empresas que participan en proyectos de la Fundación Linux (y de código abierto en general), ha habido exactamente 14 eventos de renovación de licencia de un solo proveedor. Sí, 14. Y de esos 14, a pesar de toda la tinta digital que derramamos hablando de la necesidad crítica de bifurcarnos para mantener la libertad, sólo tres se han bifurcado. Nuevamente, son 14 proyectos/repositorios de los 162 millones que Informes de GitHub.
En otras palabras, nos estamos centrando en muy pocos casos extremos en los que hay problemas fundamentales importantes en el código abierto que deben solucionarse.
Una cuestión de confianza
Los malos actores están atacando la naturaleza misma de cómo funciona el código abierto. Lo maravilloso del código abierto es que cualquiera puede participar, pero eso también puede ser una debilidad. Como vimos recientemente con el Explotación de utilidades XZy nuevamente más recientemente con un ataque similarmalos actores sofisticados (quizás respaldados por estados-nación) están utilizando el proceso estándar de contribución de código abierto para infiltrarse en proyectos relativamente oscuros pero ampliamente utilizados.
Estas tácticas de ingeniería social son difíciles de detectar, dada la superficie de ataque casi infinita que ofrece el código abierto y la naturaleza sofisticada de los ataques más recientes (que surgen en tiempo de ejecución). Por supuesto, la naturaleza abierta significa que detectar los problemas y solucionarlos puede ser más fácil que en el software propietario. Pero con los desarrolladores incluyendo código fuente abierto en cerca del 100% de todo el softwareincluido el propietario, detectar todos los problemas se convierte en un juego serio de Whac-A-Mole.
La Fundación Linux y otros ya están trabajando en formas de introducir nuevas formas de profundizar la confianza en el proceso de código abierto. Sus ideas deberían funcionar para intentos recientes de explotar paquetes de código abierto, donde los recién llegados al proyecto propusieron contribuciones en circunstancias sospechosas. Pero, ¿habría detenido el exploit XZ Utils, que ocurrió a lo largo de años? Eso parece menos probable.
Los intentos de mejorar los procesos de código abierto también se ven complicados por la naturaleza de la mayoría del software de código abierto: no está escrito por un solo proveedor ni siquiera por una comunidad de proveedores. Está escrito por una desarrolladora en solitario en su tiempo libre. Dadas esas realidades, ¿qué se puede hacer? Según Jack Cable y Aeva Black, ambos de la Agencia de Seguridad de Infraestructura y Ciberseguridad de los Estados Unidos (CISA), todo se reduce a que los proveedores hagan lo que algunos de nosotros hemos estado defendiendo durante años. mientras discuten“Cada fabricante de tecnología que se beneficia del software de código abierto debe hacer su parte siendo consumidor responsable y contribuyente sostenible a los paquetes de código abierto de los que depende”.
Yo agregaría que tal vez deberíamos comenzar desde arriba, con los proveedores que aprovechan al máximo el código abierto pero que a veces dan lo mínimo. Sí, Las empresas de la nube que valen billones de dólares ganan decenas de miles de millones con el código abierto pero difícilmente puede reunir decenas de miles de líneas de código para cualquier proyecto determinado. ¿Quiere que la seguridad del código abierto mejore de la noche a la mañana? Haga que los proveedores sean responsables de retribuir, como sugiere CISA.
Hacer accesible la IA de código abierto
Otro tema enorme: la inteligencia artificial. O, mejor dicho, la dificultad de aplicar el código abierto a la IA. No entraré en detalles aquí porque ya lo he hecho detalladamente (ver aquí o aquí), pero también está el problema de la accesibilidad en la IA. Por una estimación, a OpenAI le costó 78 millones de dólares entrenar GPT-4, y Google gastó 191 millones de dólares para entrenar su modelo Gemini Ultra. Por supuesto, estos no son los únicos grandes modelos de lenguaje; hay muchos, incluidos los modelos de IA de “código abierto” (entre comillas porque, incluso según lo reconoce la OSI, aún no está claro qué significa el código abierto en IA). Todavía está en debate si el código es realmente abierto si sólo las empresas más ricas pueden permitírselo.
Este no es un problema nuevo, por supuesto. Exactamente el mismo problema afecta a la nube. Hace casi 20 años pregunté a los ejecutivos de código abierto de Google y Yahoo! por qué no contribuyeron con más código. Se ofendieron con razón. Ambas empresas estaban entre los líderes en contribuciones de código abierto, pero una de ellas también dijo, en efecto, «Incluso si abrimos nuestra infraestructura, no podrías usarla porque no tienes los recursos para hacer algo con ella».
En la nube hemos descubierto formas de solucionar esto (Kubernetes, por ejemplo) y, con suerte, veremos algo similar con la IA. Sin embargo, hasta que lo hagamos, el código abierto en IA podría ser como poner código en un museo; puedes mirar, pero no hay una forma práctica de tocar el código o usarlo.
Volvamos a mi premisa central. Podemos optar por dedicar nuestro tiempo a retorcernos las manos sobre un número infinitesimal de proyectos de código abierto que vuelven a obtener licencias para poder invertir mejor en seguridad e innovación continua (Divulgación: trabajo para uno de ellos), y podemos hacer declaraciones agitadas sobre “IA de código abierto” sin definirla ni hacerla útil para los desarrolladores de base (y/o sus empleadores). O podemos hacer el trabajo más difícil e importante de descubrir cómo hacer que el código abierto funcione de manera más segura para todos en el planeta y garantizar que la IA no sea solo para las empresas más ricas. Este trabajo más duro generará verdaderos dividendos para la sociedad. El primero te dará, como mucho, felicitaciones en X/Twitter.
Copyright © 2024 IDG Communications, Inc.