El código abierto es una sola persona

 (opensourcesecurity.io)
3 puntos por GN⁺ 2025-08-29 | 1 comentarios | Compartir por WhatsApp
  • Informes recientes han cuestionado el uso de software de código abierto creado por un desarrollador ruso
  • En realidad, la gran mayoría de los proyectos de código abierto están operados por una sola persona mantenedora
  • No solo en NPM, sino en diversos ecosistemas, hay muchísimos casos de paquetes populares gestionados por una sola persona mantenedora
  • El problema de esta estructura es la sobrecarga excesiva y el riesgo de cadena de suministro que recaen en una sola persona mantenedora
  • La esencia del problema no es la nacionalidad, sino la falta real de recursos y apoyo

Introducción: código abierto y la controversia reciente

  • The Register publicó un artículo que cuestiona la dependencia del Departamento de Defensa de EE. UU. respecto al uso de una utilidad de código abierto creada por un desarrollador ruso
  • El desarrollador de código abierto en cuestión está recibiendo críticas injustas
  • El contenido del artículo malinterpreta la realidad del código abierto y señala las limitaciones de este enfoque

La realidad del código abierto: la estructura de 'una sola persona'

  • Según los datos, casi todos los proyectos de código abierto son gestionados por una sola persona
  • El proyecto ecosyste.ms registra datos de aproximadamente 11.8 millones de proyectos de código abierto
    • De ellos, cerca de 7 millones tienen una sola persona mantenedora
    • En los otros cerca de 4 millones de proyectos no se conoce la cantidad de personas mantenedoras, pero se estima que una gran parte también corresponde a una sola persona
    • Solo una fracción muy pequeña de los proyectos tiene cientos de personas mantenedoras

Ni siquiera los proyectos populares son la excepción

  • Mucha gente piensa que "los proyectos importantes de código abierto o los proyectos populares estarán mantenidos por varias personas", pero en realidad los principales ecosistemas como NPM no son distintos
  • En el ecosistema de NPM existen más de 4 millones de proyectos con una sola persona mantenedora
  • Incluso entre los paquetes de NPM con más de 1 millón de descargas mensuales, aproximadamente la mitad son operados por una sola persona mantenedora
    • Si se eleva la cifra de descargas a mil millones, hay algunas diferencias, pero aun así siguen existiendo paquetes mantenidos por una sola persona
  • Las personas reales que operan esos 4 millones de proyectos de una sola persona en NPM son alrededor de 900 mil (es decir, una misma persona se hace responsable de varios proyectos)

La esencia del problema: no es el país, es la falta de recursos

  • La escala económica del código abierto es una base valuada en billones de dólares (según un estudio de Harvard, 8.8 billones de dólares)
  • La mayoría de los proyectos con una sola persona mantenedora carecen de recursos y presentan riesgos en la cadena de suministro
  • El mayor riesgo no es un país, sino esa 'única persona mantenedora' que trabaja en exceso y no recibe una compensación adecuada
  • Que los medios u otros actores pongan en la mira a personas mantenedoras individuales no es una solución

Conclusión y puntos de acción

  • La causa del problema actual está en la estructura de una sola persona mantenedora, y enfocarse en el país no tiene sentido
  • Demonizar o detectar a personas mantenedoras individuales no es la solución
  • Este problema es complejo y no existe una solución inmediata
  • En lugar de señalar y culpar a personas mantenedoras individuales, hace falta pensar en el problema estructural y en formas de apoyo

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-08-29
Opinión de Hacker News

  • Da la impresión de que hay mucho malentendido sobre este tema en la comunidad de software; en realidad, el riesgo de la cadena de suministro me parece más un problema de gobernanza que de software o ingeniería
    Incluso sin mala intención de nadie, un proyecto puede generar riesgo de cadena de suministro, y cada persona que lo evalúa tiene una perspectiva y criterios de seguridad distintos
    El DoD (Departamento de Defensa de EE. UU.) evalúa el riesgo desde una óptica completamente distinta a la de un desarrollador común, y muchos proyectos de una sola persona se consideran riesgosos simplemente porque solo hay una persona a cargo
    Si el “bus factor” es 1, eso por sí mismo ya es un riesgo de cadena de suministro
    La mayoría de la gente no piensa en escenarios de guerra al elegir paquetes, pero el ejército sí puede hacerlo
    Si estalla una guerra, incluso proyectos de código abierto que normalmente se gestionan de manera autónoma pueden ver su situación cambiar de golpe
    De hecho, en muchos países durante una guerra la ley puede exigir la cooperación de empresas privadas o proyectos personales, así que hay lugares (como el DoD) que incluso contabilizan ese tipo de cosas como riesgo de seguridad

    • Gente, quiero que lo digamos todos juntos: ¡hay que vendorizar los paquetes! ¡Vendorícenlos!
    • Aun así, me amarga ver que siga el hype tipo “un desarrollador solitario puede crear pronto una empresa de software multimillonaria”
    • Si fuera el DoD, creo que ni siquiera usarían ese paquete a menos que estuvieran listos para leer todo su código línea por línea, congelar las actualizaciones y aplicar parches por cuenta propia si fuera necesario
      No operarían en una situación de guerra pensando algo como “ojalá hubiera aunque fuera otra persona en la que no confiamos nada”

  • Había datos que decían que en NPM hay 4 millones de proyectos de una sola persona y que unas 900 mil personas mantienen esos proyectos; me pregunté si ese era realmente el punto importante

    • No se decía de forma explícita, pero parece que la idea va por ahí
      Es decir, que la mayor parte de lo que genera el valor económico del código abierto (Harvard lo estima en 8.8 billones de dólares) son “proyectos de una sola persona”, y casi ninguno de esos mantenedores recibe recursos adecuados
      En toda esta conversación sobre riesgo de cadena de suministro, lo realmente peligroso es el mantenedor solitario, mal pagado y sobrecargado de trabajo
      De dónde venga esa persona en realidad no me parece tan importante

  • Me da curiosidad si habrá estadísticas sobre qué pasa cuando un mantenedor solitario sufre un accidente de repente o abandona el proyecto
    Con tantos datos, parece algo que valdría la pena investigar
    Me gustaría saber si llega un nuevo desarrollador a continuar el proyecto, si lo reemplaza otro proyecto similar o si simplemente desaparece por completo

    • Depende del caso
      En la práctica, es más común que “lo atropelle un autobús” que el hecho de que el mantenedor pierda interés o ya no tenga tiempo y lo deje
      Los escenarios que suelen darse son
      1. alguien hace un fork y al final ese fork reemplaza al original
      2. un proyecto nuevo que cumple la misma función gana popularidad y reemplaza al anterior
      3. el mantenedor original le pasa la administración del proyecto a otra persona
      4. nadie lo mantiene, pero se sigue usando; cuando surge un problema, cada quien hace su propio fork para resolverlo, aunque esos forks no se vuelven la tendencia principal
        La fortaleza del código abierto es que, aunque su creador desaparezca, se vuelva raro o cambie la licencia, alguien puede hacer un fork y mantenerlo vivo
        En cambio, con el software comercial, si el creador —sea empresa o individuo— desaparece o cambia las cosas, ahí se acabó
        A lo mucho te toca buscar un producto sustituto
    • Si existiera una serie de episodios sobre cómo estas bibliotecas/herramientas/apps/sitios populares de código abierto pasan de un mantenedor a otro, la vería sin falta
      Esa también es la razón por la que no dirijo Netflix
    • En mi experiencia, he visto pasar de verdad los tres casos
      Al final depende de la cantidad de usuarios, la complejidad de la base de código y de si existen alternativas
    • El ejemplo más parecido que se me viene a la mente es Hans Reiser/Reiserfs
      Es una historia mucho más extraña que simplemente “lo atropelló un autobús”, y al final ese proyecto desapareció
    • La gente pasa por alto que, si el código es abierto, en el peor de los casos siempre se puede hacer un fork, aunque tome tiempo

  • Incluso en proyectos mantenidos por dos o más personas, en la práctica la mayoría de los commits suelen recaer al final en una sola persona

  • Si al menos hubieran revisado la actividad, habrían visto de inmediato que la mitad de todos los proyectos tiene 0 mantenedores

    • A veces, una vez que el software se siente “perfecto”, ya no necesita mantenimiento
      Significa que puedes dejarlo ahí sin necesidad de limpieza, ajuste o calibración
      De hecho, a veces el problema son las actualizaciones, no el proyecto en sí

  • Me preocupa más el hecho de que el DoD use node
    Siento que plataformas como npm tienen una superficie de ataque demasiado grande

    • Eso hace preguntarse por qué
      El DoD es una de las organizaciones más grandes del mundo, así que también tiene tareas como enviar newsletters o páginas web para reservar visitas a bases de los Boy Scouts
      Para ese tipo de cosas, usar node no me parece problema
      Esos sistemas operan aparte de los sistemas críticos como el lanzamiento de misiles, y no pasa gran cosa si solo vandalizan una página para registrarse a un evento
    • Como el DoD es tan enorme, supongo que debe usar prácticamente todas las plataformas importantes

  • Creo que muchos proyectos de una sola persona en GitHub en realidad no pasan de ser experimentos personales o bromas tipo "hello world"
    No sé cómo sea en npm, pero en PyPI sobran ejemplos parecidos
    Le di clic a “browse projects” y me salió esto: https://pypi.org/project/helloworld-eduardo/
    De verdad, por muy borracho que estuvieras, a nadie se le ocurriría usar algo así en producción

  • El DoD es muy bueno para, si puede sacar algo gratis, convencer a todo el mundo de que “esto nos beneficia a todos” y al final terminar pagándole a un contratista externo

    • Si piensas en la historia del caballo de Troya, queda claro que lo gratis no siempre es bueno

  • Dijeron que existe un “paquete con más de mil millones de descargas administrado por una sola persona”, y me quedé con la duda de qué significa exactamente eso

  • He oído muchas cosas buenas sobre el trabajo de alguien llamado Linus, y creo que lo he usado bastante
    Como viene de un país que comparte frontera con Rusia, me hace preguntarme si eso también habría que tomarlo en cuenta
    Llevo décadas desarrollando código abierto, casi siempre solo o a veces armando equipos de voluntarios
    Quienes han trabajado con equipos de voluntarios saben que no es nada fácil
    Claro que no es totalmente imposible, pero tampoco funciona bien con tanta frecuencia como solemos imaginar
    Cuando funciona, por lo general es porque hay un “BDFL (dictador benevolente de por vida)” o porque todos avanzan alineados hacia un mismo objetivo
    En mi caso, casi siempre fue más bien lo segundo

    • (Off-topic) También dicen que los padres de Linus eran políticamente activos, y que el propio Linus participó de niño en una organización juvenil comunista parecida a los scouts
      Su padre incluso pasó varios años en Moscú
    • Linux es un proyecto con una gran cantidad de mantenedores y apoyo, así que no tiene nada que ver con un proyecto de una sola persona desarrollado solo por Linus