GitHub debería cobrar 1 dólar más al mes a todos los usuarios para apoyar el código abierto

• Se critica la práctica de dar por hecho que las dependencias de código abierto son gratuitas, aunque se han vuelto fundamentales para la operación de las empresas
• La estructura actual, basada en donaciones o patrocinios, no es sostenible y hace falta una nueva forma de financiamiento
• La propuesta consiste en que GitHub cobre 1 dólar adicional al mes por usuario y lo acumule en un fondo para código abierto que se distribuya según el uso
• La distribución se haría con base en los proyectos mencionados en package.json o requirements.txt, y se pone como ejemplo una estructura similar al modelo de reparto de ingresos de Spotify
• Se enfatiza la necesidad de establecer un sistema de compensación sostenible en una realidad donde el código abierto sostiene infraestructura en todo el mundo

---

Cuestionamiento de la dependencia gratuita del código abierto

• Se señala que la idea de que el código abierto se ofrece gratis, “como una cerveza gratis”, es anormal
  • Detrás del código hay trabajo real, y asumir que se trata solo de un hobby o de contribuciones voluntarias es una premisa equivocada
• El ecosistema actual de código abierto depende de donaciones o patrocinios, y eso lo convierte en una estructura inestable
  • Los desarrolladores siguen en la situación de tener que pedir apoyo casi como si estuvieran mendigando para llamar la atención
  • Algunos proyectos enfrentan la realidad de que es difícil sostener su subsistencia y terminan buscando una “línea de vida”

Propuesta de un nuevo financiamiento a través de GitHub

• Se plantea que GitHub cobre 1 dólar adicional al mes por usuario a todas las organizaciones y lo acumule en un Fondo de Código Abierto (Open Source Fund)
  • El fondo se guardaría en una modalidad de escrow y se administraría con transparencia
• El dinero acumulado se distribuiría según el uso, es decir, de acuerdo con cuántas veces se mencione cada proyecto en package.json o requirements.txt
  • También podrían incluirse elementos como la instrucción FROM de un Dockerfile
• Se explica que este modelo es parecido al mecanismo de reparto de ingresos para artistas de Spotify
  • Aunque el modelo de Spotify no es perfecto, al menos sirve como referencia de un sistema estructural mínimo de distribución

Forma de implementación y estructura de participación

• El fondo operaría bajo un esquema de participación predeterminada con opción de salida (opt-out)
  • Las organizaciones podrían excluirse si no lo desean
• A las organizaciones participantes se les podrían ofrecer beneficios simbólicos, como una “insignia mágica” o permiso para configurar el CSS de fondo del perfil
• El autor menciona: “esta idea está incompleta y es torpe, pero no se puede decir que el estado actual sea ‘bueno’”

Preocupación por la sostenibilidad del código abierto

• En la estructura actual, el código y el esfuerzo que sostienen infraestructura crítica en todo el mundo se usan sin ninguna compensación
• Se subraya la necesidad de una nueva estructura de circulación de fondos para el mantenimiento del código abierto
• También se plantea la postura de que “no sé cómo incluir proyectos grandes como Linux, pero hay que empezar en algún punto”

Conclusión

• El autor espera que personas más inteligentes que él puedan desarrollar medidas concretas a partir de esta idea
• El mensaje central es que “la estructura actual de financiamiento del código abierto no es sostenible y necesita cambiar”

[GN⁺]

Opiniones de Hacker News

• Soy alguien que disfruta hacer contribuciones de código abierto sin paga
  mejor aún si otras personas disfrutan mi trabajo
  no creo que la actitud de esperar recompensa por todo el código sea algo universal
  si haces open source esperando una recompensa, el enfoque está mal
  aun así, si dependes del trabajo de otra persona, sí hace falta consideración comunitaria

  • Creo que quienes no ven esta perspectiva también descartan la UBI (ingreso básico universal) o la red de seguridad social como algo que “desincentiva”
    muchas personas creativas y consideradas se mueven no por dinero, sino por la pura alegría de crear
    si la subsistencia básica estuviera garantizada, habría muchísimo más arte, comunidad y open source en el mundo
  • Admito que tienes razón
    lo que quería decir es que este tipo de trabajo no debería verse como un regalo caído del cielo
    mientras más crece un proyecto, mayor es la responsabilidad, y es injusto que esa carga se concentre en una sola persona
    como en el incidente del backdoor de xz o el FAQ de PocketBase, hace falta apoyo sistémico
  • A mí también me gusta el open source, pero llega un punto en que mi código termina convirtiéndose en infraestructura crítica
    en esa situación, falta un modelo de transición para cuando algo que “hacías por diversión” se convierte en “una responsabilidad de nivel laboral”
    por eso tantos maintainers terminan quemados
  • Yo hago open source por el aprendizaje y por la alegría de crear
    mis proyectos de GitHub son como mi isla
    los PR son bienvenidos, pero a veces también se siente como si alguien estuviera pintando encima de mi cuadro
    no espero recompensa; simplemente pueden hacer fork libremente según mi licencia
    para creadores como nosotros, no interferir y darnos libertad es la mayor muestra de respeto
  • Yo también hago open source por la misma razón
    es mi regalo para el mundo
    claro, un poco de recompensa estaría bien, pero si eso trae obligaciones o condiciones, prefiero la forma libre que existe ahora

• El open source es, en esencia, un regalo voluntario
  a cambio apenas obtienes algo de reconocimiento o satisfacción

  • El problema es la carga de mantenimiento
    muchas empresas les están endosando a los maintainers la corrección de bugs y los problemas de seguridad
    esta estructura es insostenible y al final lleva al burnout y a librerías abandonadas
    si una empresa no tiene recursos o experiencia suficientes, debería compensarlo con patrocinio
  • Hay quien opina que ya cansa culpar a quienes usan algo conforme a los términos de la licencia
  • Me parece absurdo pedir dinero por algo que regalaste gratis
  • La solución natural a este problema son los subsidios públicos o privados
    hace falta una estructura que recompense justamente a quienes mantienen infraestructura crítica

• La solución al financiamiento del open source no es el cobro forzado
  una estructura así va contra el espíritu del open source
  maintainers y usuarios no tienen ninguna obligación mutua
  si no te gusta, puedes enviar un PR o hacer un fork
  el open source no es software comercial, sino un espacio de intercambio libre

  • Pero también es un problema decidir quién debería recibir dinero
    si el criterio fuera la popularidad, la mayor parte del dinero terminaría yéndose a JavaScript
  • En realidad, el significado original de open source no era “gratis”, sino la libertad de modificar y acceder
    es decir, está más cerca de “libertad de expresión” que de “cerveza gratis”

• La premisa detrás de esta propuesta, de que “la mayoría del FOSS es obra de voluntarios”, es falsa
  mucho del open source que uso fue hecho por grandes empresas
  por ejemplo, React lo hace Meta, TypeScript Microsoft y Chrome Google

  • Pero Chrome tampoco es FOSS por completo
    Google Chrome es un navegador comercial basado en Chromium
    Chromium fue un fork de WebKit (Apple), y WebKit a su vez fue un fork de KHTML de KDE
  • Además, Chrome también depende de código ajeno a Google como libxml2
    recientemente volvió a llamar la atención esta estructura de dependencias cuando renunció el maintainer de libxml2

• Si lo publicaste bajo una licencia open source, no hay razón para sorprenderse de que la gente lo use gratis
  si querías ingresos, debiste elegir otra licencia

  • Si no te gusta que una empresa lo comercialice de una forma incompatible con FOSS, debiste usar GPL
  • La licencia la decide el titular del copyright
    también hay muchas opciones de doble licencia o copyleft para exigir compensación por el uso comercial

• La propuesta de distribuir fondos del open source según el uso es ineficiente
  que algo tenga muchas descargas no significa que tenga gran valor o requiera mucho mantenimiento
  yo también tengo un paquete de npm con decenas de millones de descargas, pero ya está terminado y no hay mucho que tocarle
  es difícil que exista un algoritmo que satisfaga al mismo tiempo la prevención del gaming y la eficiencia

• Si se crea un sistema así, habrá una explosión de código spam generado por IA
  ya pasó algo parecido en el caso de fraude musical con IA en Spotify

  • De hecho, ese problema de spam también ocurrió en Tea.xyz
  • Además, se dice que Spotify mismo también está creando música con IA

• Llevo años viviendo de subsidios y donaciones
  ya existen muchas plataformas de financiamiento para open source, y el problema no es la plataforma sino la actitud del desarrollador
  si quieres recibir dinero, tienes que decirlo claramente
  la mayoría deja su enlace de donación enterrado en lo profundo del FAQ
  pero si lo pides directamente, sorprendentemente la gente sí da dinero
  si hasta los streamers de Twitch ganan dinero, no hay razón para que quienes hacemos software útil no podamos hacerlo
  si tus usuarios son empresas, contactarles directamente para proponer patrocinio funciona bien

  • Por ejemplo, Krita empezó a venderse en Steam y en Windows Store y el equipo pasó de 2 a 4 personas
    enlace relacionado

• Si se crea un sistema así, aumentará el spam de dependencias sin sentido
  ya hay desarrolladores que meten paquetes inútiles en PR solo para subir el número de descargas
  porque una cifra alta de descargas se usa como indicador de capacidad en el currículum

  • Si esa estructura se implementa, los maintainers tendrán que poner más atención a vigilar el spam de dependencias

• Si quieres hacer un producto, simplemente haz un producto y véndelo
  se volvió popular porque se distribuyó gratis, así que después pedir dinero es contradictorio
  si hubiera sido de pago, la gente lo habría hecho por su cuenta o habría usado otra cosa