curl es una pequeña herramienta de línea de comandos que transfiere datos a través de Internet. Cuando nuestro teléfono descarga una actualización, cuando nuestro navegador carga una página o cuando nuestro automóvil se comunica con un servidor, algo tiene que encargarse de esa solicitud de red. En la mayoría de los dispositivos, ese algo es curl . Es invisible, funciona en todas partes y casi nadie sabe que existe.

Esta es la historia de la única persona que lo mantiene en funcionamiento y de lo que le está sucediendo en este momento.

Daniel Stenberg trabajó en 1996 en el mantenimiento de una pequeña herramienta para descargar archivos mediante HTTP. La herramienta original se llamaba httpget y había sido creada por Rafael Sagula. Stenberg amplió considerablemente sus capacidades y la rebautizó como curl en 1998. Desde entonces, nunca ha dejado de mantenerla.

Actualmente, curl viene integrado en Windows, macOS, Linux, Android e iOS. Funciona en todas las consolas PlayStation, Xbox y Nintendo. Netflix transmite contenido a través de curl . Spotify también. Es muy probable que nuestro televisor inteligente dependa de esta herramienta. Un solo desarrollador sueco mantiene todo eso en funcionamiento.

En 2025, Suecia nombró a Stenberg Desarrollador del Año. Durante ese mismo período, comenzó a publicar artículos sobre el agotamiento profesional. También comenzó a documentar una nueva amenaza: informes falsos de errores generados mediante inteligencia artificial que inundaban su sistema de seguimiento de incidencias y le hacían perder horas de trabajo cada semana.

El reconocimiento y las publicaciones sobre el agotamiento llegaron al mismo tiempo. Eso deberíamos decirnos todo lo que necesitamos saber sobre el estado del apoyo que reciben los mantenedores de proyectos de código abierto.

Si esta historia nos resulta frustrante, apoyemos con un aplauso para que más ingenieros puedan verla. Este no es un problema exclusivo de curl .

47 marcas de automóviles, ningún colaborador

Las cifras de adopción son impresionantes. Según la propia documentación de Stenberg, 47 marcas de automóviles incorporan curl en sus vehículos. No se trata de 47 modelos de automóviles, sino de 47 fabricantes diferentes.

Crédito: Autor, adopción corporativa de curl frente a la realidad de sus colaboradores. Crédito: Autor, adopción corporativa de curl frente a la realidad de sus colaboradores.

La manzana incorpora rizo . Microsoft incorpora curl . Google incorpora curl . Amazon incorpora rizo . Ninguna de estas empresas contrata a Daniel Stenberg. Él trabaja en wolfSSL , una pequeña compañía que patrocina el tiempo que dedica al mantenimiento de curl . Sin embargo, es una pequeña empresa que está soportando el peso de una infraestructura utilizada por corporaciones valoradas en billones de dólares.

La realidad de los colaboradores es igual de contundente. Alrededor de diez personas contribuyen regularmente al proyecto. A lo largo de su historia, curl ha recibido modificaciones de cientos de desarrolladores, pero Stenberg revisa prácticamente cada cambio, gestiona los informes de seguridad, coordina los lanzamientos, responde a los informes de errores, redacta la documentación y mantiene la dirección general del proyecto.

He pasado más de veinte años construyendo sistemas que dependen de bibliotecas exactamente como curl . Todas las plataformas que diseñó, desde telecomunicaciones hasta salud digital, tenían curl en algún punto de su árbol de dependencias. Todos consumimos este trabajo. Casi nadie paga por él.

«Un ataque DDoS contra los mantenedores»

Desde finales de 2024, y con una escalada durante 2025, Stenberg comenzó un documental un nuevo fenómeno. Los informes de errores generados mediante inteligencia artificial empezaron a inundar el sistema de seguimiento de incidencias del proyecto curl .

No eran contribuciones útiles. Se trataba de vulnerabilidades de seguridad inventadas, redactadas por personas que utilizaban ChatGPT, Claude u otras herramientas similares para generar informes de vulnerabilidades que parecían convincentes, pero que eran completamente ficticias. Stenberg lo describió exactamente como lo que era: «un ataque DDoS contra los mantenedores» .

El patrón se repetía constantemente. Alguien le pidió a una inteligencia artificial que «encontrara vulnerabilidades de seguridad en curl». La IA inventaba un supuesto desbordamiento de búfer, un problema de corrupción de memoria o cualquier otra vulnerabilidad aparentemente creíble. Después, la persona enviaba el resultado como un informe de error y, en algunas ocasiones, incluso solicitaba que se le asignara un identificador CVE. Stenberg tenía que dedicar tiempo a investigarlo, comprobar que era falso y cerrar el informe.

Crédito: Autor, flujo de ataques mediante informes de errores basura generados por IA. Crédito: Autor, flujo de ataques mediante informes de errores basura generados por IA.

Cada informe falso consume tiempo real. No es posible descartarlos sin comprobarlos. Una vulnerabilidad de seguridad legítima en curl podría afectar miles de millones de dispositivos. Por eso, Stenberg tiene que tomarse cada informe con la suficiente seriedad como para confirmar que ha sido inventado.

The Register informó que el proyecto curl comenzó a exigir a los colaboradores que confirmaran que sus informes no habían sido generados mediante inteligencia artificial y comenzaron a prohibir la participación de quienes reincidían.

¿Cuál es la motivación detrás de estos envíos? Las recompensas por descubrir errores. Algunas personas quieren obtener reconocimiento por encontrar vulnerabilidades sin realizar una investigación de seguridad real. La inteligencia artificial facilita la creación de documentos que parecen profesionales. La persona que está al otro lado es quien termina pagando el coste.

Desarrollador del Año y documentando su agotamiento

Suecia nombró a Stenberg Desarrollador del Año en 2025. Se lo merecía. curl es uno de los proyectos de código abierto más exitosos de la historia. Se estima que la biblioteca cURL, conocida como libcurl , proporciona capacidades de transferencia mediante HTTP a diez mil millones de instalaciones en todo el mundo.

Sin embargo, al leer el blog de Stenberg durante ese mismo período, aparece una historia diferente. Ha escrito abiertamente sobre la insostenibilidad de mantener el proyecto prácticamente en solitario, sobre el agotamiento que implica gestionar un proyecto en constante crecimiento con un equipo casi del mismo tamaño que hace una década y sobre cómo la adopción empresarial nunca se traduce en apoyo empresarial.

Crédito: Autor, cronología del proyecto curl que muestra la diferencia entre el reconocimiento y la sostenibilidad. Crédito: Autor, cronología del proyecto curl que muestra la diferencia entre el reconocimiento y la sostenibilidad.

Esta diferencia entre reconocimiento y sostenibilidad no es exclusiva de curl . Es el principal fracaso del modelo de consumo corporativo del código abierto. Las empresas obtienen millas de millones de dólares en valor. El mantenedor recibe un premio y una bandeja de entrada saturada que lo lleva al agotamiento.

¿Hemos observado este mismo patrón en los proyectos de los que dependemos? Me encantaría leer sus experiencias en los comentarios.

El verdadero problema del factor autobús.

LWN.net documentó el problema estructural más profundo. curl tiene un "factor autobús" de uno. Es decir, si Daniel Stenberg deja de mantener curl mañana, ya sea por agotamiento, problemas de salud, jubilación o simplemente porque decide que ya ha contribuido lo suficiente, no existe un plan de sucesión capaz de reemplazar sus 28 años de conocimiento institucional.

El protocolo HTTP es complejo. curl es compatible con decenas de protocolos, cientos de opciones y miles de casos especiales acumulados durante casi tres décadas. Encontrar a alguien que comprenda todo eso no es un problema de contratación. Es un problema de conocimiento, y adquirirlo requiere años.

Esto no es algo meramente teórico. La vulnerabilidad Heartbleed de OpenSSL, descubierta en 2014, puso en evidencia el mismo patrón: una pieza fundamental de la infraestructura de Internet mantenida por un equipo muy pequeño y con una financiación mínima.

La industria entró en pánico, creó la Core Infrastructure Initiative (actualmente integrada en la Open Source Security Foundation ), y después volvió gradualmente a consumir software sin contribuir a su mantenimiento.

Crédito: Autor, comparación del riesgo de la cadena de suministro de curl con otras dependencias críticas similares. Crédito: Autor, comparación del riesgo de la cadena de suministro de curl con otras dependencias críticas similares.

Tres cosas que deben cambiar

Stenberg no está pidiendo compasión. Está pidiendo un cambio estructural. De acuerdo con sus escritos, deben ocurrir tres cosas.

  • En primer lugar, las empresas deben financiar la infraestructura de la que dependen. No mediante donaciones aisladas, sino a través de empleos estables o contratos de mantenimiento. Si 47 marcas de automóviles utilizan curl, al menos algunas de ellas deben contratar a mantenedores de curl . El modelo de la Fundación Linux con el núcleo de Linux demuestra que esto funciona. Los mantenedores del kernel son contratados por empresas que distribuyen Linux. curl merece el mismo tratamiento.
  • En segundo lugar, el problema del contenido basura generado por inteligencia artificial necesita soluciones a nivel de plataforma. GitHub y las demás plataformas que alojan sistemas de seguimiento de incidencias deben implementar mecanismos automatizados para detectar informes de vulnerabilidades generados mediante IA. La responsabilidad de filtrar el ruido producido por las máquinas no debería recaer sobre mantenedores que trabajan prácticamente solos. La exigencia de Stenberg de quienes presentan informes confirman que fueron redactados por personas es una medida temporal, no una solución definitiva.
  • En tercer lugar, la concienciación sobre el factor autobús debe convertirse en un requisito de seguridad de la cadena de suministro. Si nuestra empresa realiza una auditoría de su cadena de suministro de software y definitivamente debería hacerlo, debe incluir la sostenibilidad de los mantenedores como una métrica de riesgo. Una dependencia crítica mantenida por una sola persona representa una vulnerabilidad en la cadena de suministro, incluso cuando el código en sí mismo sea seguro.

Empecemos a tratar a los mantenedores de código abierto como infraestructura

curl no es un proyecto secundario. Es infraestructura. Transfiere datos a través de Internet hacia más dispositivos que cualquier otra biblioteca. Lo ha hecho de manera confiable durante 28 años porque una persona se preocupó lo suficiente como para continuar realizando el trabajo.

Daniel Stenberg construyó algo extraordinario. La respuesta de la industria ha sido consumir su trabajo, entregarle un premio y permitir que los robots de inteligencia artificial inunden su sistema de seguimiento de incidencias.

Si nuestra empresa utiliza curl y tengan por seguro que lo hace, comprobemos si está contribuyendo al proyecto. Si no lo está haciendo, debería empezar ahora mismo.

Financiamos el proyecto. Asignamos a un ingeniero para que contribuya directamente al desarrollo original. Tratémoslo como la infraestructura que realmente es.

¿De qué proyectos críticos de código abierto dependen de nuestro equipo sin contribuir a ellos? Siento una curiosidad genuina por conocer sus respuestas.

Gracias por leer Código en Casa.
Si esto te a ayudado y te sumo algo Dale un 👏 , compártelo con tu red o dejame un comentario para saber tu opinión.