Las cosas por las que nadie quiere pagar

Artículo original ↗ Discusión en Hacker News ↗

La infraestructura de código abierto, como el kernel de Linux, los compiladores y los entornos de escritorio, sustenta gran parte de la informática moderna, pero el trabajo poco glamoroso clave —pruebas, documentación, mantenimiento y pulido de la UX— sigue crónicamente infradotado e infrarrecursos. Los comentaristas describen una “tragedia de los comunes” en la que las corporaciones y los usuarios dependen de estos proyectos pero rara vez pagan por ellos, debaten si las soluciones deberían venir de impuestos, subvenciones públicas, fundaciones, cambios en las licencias o filantropía de multimillonarios, y señalan que los factores culturales en proyectos como el kernel también dificultan mejores herramientas y pruebas. Muchos coinciden en que el código abierto es un bien social neto, pero sostienen que, sin nuevos modelos de financiación y gobernanza, el software crítico seguirá dependiendo de un frágil esfuerzo voluntario.

UX y fragmentación del escritorio Linux

  • Varios usuarios consideran que el escritorio Linux en 2024 sigue siendo inconsistente y poco fiable, citando:
    • Muchos métodos de instalación mutuamente incompatibles (gestores de paquetes de distribuciones, snaps, flatpaks, tarballs, Docker, curl | sh, compilaciones desde el código fuente).
    • Problemas de hardware/energía (suspensión que falla, periféricos que no funcionan tan fluidamente como en Windows/macOS).
    • UX inconsistente entre toolkits (apps KDE vs GTK, distintos diálogos de archivos, barras de desplazamiento diminutas, ajustes dispersos).
    • Frustraciones con arrastrar y soltar y la gestión de archivos en algunos entornos.
  • Otros relatan experiencias positivas (p. ej., Debian + KDE) y dicen que Linux supera a Windows al evitar ciertas molestias, pero reconocen bordes ásperos y la lenta propagación de correcciones de errores en distribuciones “estables”.
  • Debate sobre si Valve “arreglará” el escritorio: algunos sostienen que upstreama ampliamente y financia KDE; otros creen que su enfoque se limita a las necesidades de Steam Deck.

Pruebas del kernel, herramientas y documentación

  • Las anécdotas sugieren que los parches del kernel pueden aceptarse con solo pruebas manuales; algunos ven esto como algo cultural y derivado de la coordinación.
  • Se critica que la cultura del kernel infravalore las pruebas, la CI y la documentación; otros señalan que ya existen múltiples iniciativas de CI respaldadas por empresas (kselftest, KernelCI).
  • LLVM se cita como un paralelismo: muy usado y desarrollado en gran medida por ingenieros de empresas, pero las herramientas auxiliares, la limpieza del código y las pruebas suelen quedar relegadas.

Modelos de financiación y incentivos del código abierto

  • Gran preocupación por “las cosas por las que nadie quiere pagar”: pruebas, documentación, mantenimiento e infraestructura poco glamorosa.
  • Propuestas:
    • Un pequeño gravamen obligatorio o cuota de licencia para las grandes empresas que usan OSS para financiar un “fondo soberano de OSS”.
    • Deducciones fiscales por contribuciones a OSS como alternativa más realista políticamente.
    • Filantropía de multimillonarios dirigida a OSS.
    • Agencias de subvenciones respaldadas por el gobierno para software crítico; comparadas con la financiación de NSF/NIH/las artes.
  • Los escépticos argumentan:
    • Los nuevos impuestos o condiciones tipo licencia violarían las definiciones de código abierto o serían políticamente inviables.
    • Los fondos centralizados corren el riesgo de corrupción, mala asignación o burocracia.
    • Las donaciones dirigidas pueden compensarse con reasignaciones de fondos.
    • Algunos gobiernos ya financian OSS, pero a pequeña escala.

Licencias y terminología de “código abierto”

  • Tensión entre licencias permisivas (MIT/BSD), que permiten la apropiación sin reciprocidad, y copyleft (GPL/AGPL), que obligan a compartir.
  • Aclaración de que las licencias que discriminan contra el uso comercial no son “open source” según las definiciones establecidas; esos modelos son “source-available” (p. ej., BSL).
  • Algunos se quejan del uso incorrecto del término “open source”; otros sostienen que el lenguaje es más amplio que la definición de cualquier organización.

Clase, riqueza y valor del FOSS

  • Una visión: FOSS es una enorme transferencia voluntaria de riqueza de los trabajadores a los inversores; las empresas obtienen beneficios mientras dependen de infraestructura no remunerada.
  • Visión contraria: FOSS es una “destrucción de valor” positiva en términos netos de rentas propietarias y un bien común de estilo socialista, no una simple transferencia.
  • Muchos atribuyen a FOSS haberles permitido carreras, habilidades y negocios; ven ventajas personales y sociales pese al oportunismo corporativo.

IA para documentación

  • Sugerencia: usar LLMs para generar automáticamente anotaciones y documentación a bajo coste.
  • Objeción: la documentación técnica debe ser factualmente correcta; las alucinaciones de los LLM más los riesgos legales/de licencia hacen esto cuestionable sin revisión experta costosa.

Gobierno, corrupción y gobernanza

  • Actitudes mixtas hacia la financiación liderada por el gobierno:
    • Los defensores ven paralelismos con la investigación financiada públicamente; señalan ejemplos como el Sovereign Tech Fund de Alemania.
    • Los críticos esperan asignación politizada, captura de rentas por “especialistas en subvenciones” e incentivos desalineados.
  • Subdebate más amplio sobre la corrupción sistémica percibida, el sentimiento antigubernamental, el libertarismo y la dificultad de organizar movimientos eficaces contra la corrupción.

Corporaciones, fundaciones y compensación

  • Se reconoce que las grandes empresas (Apple, Google, Microsoft, Meta, etc.) ya invierten mucho en código abierto, pero no proporcionalmente a su uso de la infraestructura central.
  • Debate sobre la compensación de ejecutivos frente a técnicos en fundaciones:
    • Algunos consideran excesivos los altos salarios ejecutivos en ciertas fundaciones en relación con figuras técnicas clave en otros lugares.
    • Otros señalan diferencias entre funciones (liderazgo de ingresos vs custodia técnica).
  • Preguntas sobre cómo pueden las personas donar directamente al desarrollo del kernel; existen donaciones a Linux Foundation, pero no son fácilmente dirigibles a un proyecto concreto.