El futuro del código abierto

 (blog.gitbutler.com)
19 puntos por xguru 2024-08-12 | 5 comentarios | Compartir por WhatsApp
  • Nuestra COO y cofundadora, Anne, fue demandada cuando era CEO de la empresa alemana de alimentos Delinero. Un proveedor etiquetó una mermelada de frambuesa como "Himbeermarmelade", pero en Alemania existía la Konfitürenverordnung (regulación de mermeladas), según la cual solo se podía etiquetar como "marmelade" si contenía al menos 20% de cítricos
  • Era una norma que contradecía el significado de uso común de la palabra, pero al haber sido hecha hace mucho tiempo por un pequeño grupo de interesados, había que cumplirla
  • Se puede ver al actual "código abierto" en una situación similar. La OSI sigue regulando estrictamente un término que, al igual que Konfitürenverordnung, ha evolucionado de forma distinta a su uso general
  • Pero, ¿cómo podemos avanzar en una dirección constructiva?

Cómo no hacer "código abierto"

  • Cuando GitButler decidió aplicar "Fair Sourcing" al código del cliente y publicarlo con una licencia no aprobada por la OSI, pensamos mucho en cómo anunciarlo
  • La mayoría de la gente equipara "código abierto" con "publicado en GitHub", y además, por las implicaciones algo riesgosas de licencias GPL/copyleft, la gente está muy acostumbrada a revisar qué licencia aplica
  • Tampoco queríamos usar una expresión ambigua como "Source Available'd", así que usamos la palabra "open" para evitar confusión, pero fuimos atacados
  • Nos dimos cuenta de que unas pocas voces muy ruidosas intentan proteger y definir este término
  • "Open source" no es la negación lógica de "closed source". Existe una brecha entre la comprensión popular de publicar en GitHub y aceptar contribuciones, y las 10 definiciones técnicas de "open source" que la OSI regula por su cuenta

Breve historia del código abierto

  • En la era temprana de la computación de los años 50 y 60, el software estaba atado al hardware, así que no había necesidad de distinguirlo por separado, y las empresas de hardware lo distribuían libremente
  • En los años 70 y 80, a medida que el hardware se volvió un commodity, el software adquirió valor propio, y grandes empresas como IBM y AT&T empezaron a restringir el acceso al código fuente que habían desarrollado con gran costo
  • Como respuesta, Richard Stallman y otros comenzaron a crear su propio sistema operativo y herramientas, protegidos de los intereses corporativos, y mediante licencias recíprocas como la GPL forzaban a que, si IBM o AT&T usaban su trabajo, también tuvieran que convertir el suyo en software libre

    "Si nosotros no podemos jugar con sus juguetes, ustedes tampoco pueden jugar con los nuestros."

    • Llamaron a este movimiento "software libre" y crearon muchas herramientas extraordinarias, como Emacs y el sistema de compiladores GNU. Incluso hoy, siguen siendo herramientas fundamentales de gran parte de la computación moderna
    • El enfoque fundamental del movimiento de software libre era garantizar la libertad de los usuarios para ejecutar, copiar, distribuir, estudiar, modificar y mejorar el software. Libertades que les habían sido arrebatadas por los intereses corporativos de su época
  • A inicios de los años 90, con el kernel Linux de Linus Torvalds, ya se tenía un sistema operativo completo, y el ecosistema de software libre creció con elementos como la pila LAMP, hasta el punto de que las empresas también empezaron a usarlo y depender de él
  • En 1997, Eric Raymond publicó el ensayo "La catedral y el bazar", donde argumentaba que el modelo de desarrollo del software libre era superior al cerrado, y este texto fue citado para justificar la apertura del código fuente de Navigator Suite por parte de Netscape
    • Cuando Netscape decidió publicar su código fuente, en una sesión estratégica en Palo Alto, Raymond y varios desarrolladores destacados de Linux y del software libre acordaron crear y usar un nuevo término: "open source"

    "Los participantes de la reunión creían que las razones prácticas y de negocio que motivaron a Netscape a publicar su código eran una forma valiosa de comunicarse con potenciales usuarios y desarrolladores de software, e influir en la comunidad para que participara en la creación y mejora del código fuente. Los participantes también creían que sería útil contar con una etiqueta única para identificar este enfoque y diferenciarlo de la etiqueta “software libre”, más enfocada en lo filosófico y político."

  • Lo importante es que no existe una diferencia legal o práctica sustancial entre "software libre" y "open source"
    • La mayoría de las licencias son compatibles y reconocidas por ambas definiciones
    • "Open source" fue solo un cambio de marca más amigable para negocios, para separar los objetivos políticos de Stallman y su movimiento de la practicidad de abrir software, con el fin de lograr que más empresas como Netscape adoptaran la apertura de su código profesional
  • O, como lo expresaron personas del lado del software libre:

    "Open source es una metodología de desarrollo y el software libre es un movimiento social."

Código abierto en la era de GitHub

  • La definición y el marketing de la frase "open source" datan de 1998, hace ya más de 25 años. Entonces, ¿qué pasó con el código abierto y el desarrollo de software durante estos últimos 25 años de computación?
  • Especialmente en los últimos 10 años, GitHub y el estilo de desarrollo de software tipo GitHub han tenido un impacto enorme en el código abierto
  • En 1998 se intentaba convencer a las empresas de adoptar software abierto, pero hoy casi todo el software de código abierto es escrito o patrocinado por empresas
  • Uno de los mayores cambios ha sido la "estandarización del flujo de trabajo de desarrollo", impulsada en particular por GitHub
  • Antes había una gran diferencia entre los proyectos de software abierto y los proyectos empresariales, pero ahora casi no hay diferencia
    • Todos usan Git
    • Casi todos usan pull requests (o merge requests, o alguna otra variante que copie esa función)
    • La mayoría de los equipos usan alguna forma de GitHub Flow (desarrollo basado en trunk, GitLab Flow, etc.)
  • Ahora, la única diferencia real es si el repositorio es público o no. Hace 25 años había mucha fricción en el proceso, pero hoy casi no se necesita cambiar nada para abrir un proyecto

¿Cuál es el siguiente paso del código abierto?

  • Ahora que casi todas las empresas usan y producen software de código abierto, ¿significa eso que el movimiento de código abierto (software libre) tuvo éxito?
  • Hoy existen dos grandes problemas en el mundo del código abierto: la "sostenibilidad de los desarrolladores" y si el "open source comercial" es viable

El problema de la sostenibilidad de los desarrolladores

  • A medida que dependemos cada vez más del código abierto, están apareciendo problemas de sostenibilidad y mantenimiento. Un caso reciente y muy conocido fue el del backdoor en XZ Utils
  • Casi todos los maintainers están lidiando con agotamiento y acoso. Es casi imposible ganar dinero escribiendo y manteniendo software de código abierto
  • La mayoría de los desarrolladores y maintainers de código abierto ahora reciben patrocinio de grandes empresas
    • Si observamos Linux, Git, Ruby, React, etc., la mayoría de los principales contribuidores de proyectos críticos de código abierto están empleados profesionalmente por patrocinadores corporativos como GitHub, Microsoft y Red Hat
  • Es difícil que un desarrollador pueda ganarse bien la vida manteniendo un proyecto como XZ Utils
    • En vez de que una sola empresa le pague a un desarrollador, lo ideal sería que miles de empresas pagaran pequeñas cantidades a maintainers profesionales
  • El problema principal es que hoy no existe una buena forma de hacer eso
    • Existen iniciativas prometedoras como GitHub Sponsors, Thanks.dev, Liberapay y Tidelift, pero aún no han resuelto el problema de ofrecer incentivos adecuados para que las empresas donen
  • Sentry ha estado impulsando una nueva iniciativa llamada OSS Pledge, y GitButler planea participar cuando se lance en octubre
  • Pero todavía no está claro si enfoques como este podrán resolver el gran y creciente problema de la sostenibilidad de los desarrolladores dentro del ecosistema de código abierto

El problema del código abierto comercial

  • Durante mucho tiempo, los desarrolladores crecieron amando el código abierto y las comunidades abiertas, y cuando inician una empresa o proyecto, por defecto quieren hacerlo abierto
    • Pero, al igual que con los maintainers individuales, el código abierto también tiene un problema de sostenibilidad empresarial
  • Como muestran los casos de Elasticsearch y Redis, cuando inviertes tiempo y dinero en desarrollar software profesionalmente, existe el riesgo de que grandes empresas como Amazon usen tu trabajo para competir directamente contigo
  • Muchos creadores profesionales quieren invertir en software y luego evitar que se use en su contra
    • Eso implica ser creativos con las licencias o cerrar el código fuente
  • Creo que el movimiento Fair Source es una solución excelente y necesaria para este problema creciente, y que cierra el vacío del ecosistema de código abierto que ha generado cada vez más problemas y confusión en los últimos años
    • Me parece una solución muy necesaria como nuevo término para referirse a proyectos profesionales que en su mayoría son permisivos, tienen el código fuente disponible y permiten la participación de la comunidad de GitHub, con el objetivo de incentivar que más proyectos que antes habrían sido privados se publiquen de forma abierta

El futuro de la colaboración

  • El futuro del código abierto no es simplemente "Open Source" ni solo las 10 reglas tipo Konfitürenverordnung de la OSI
  • Es una combinación de Open Source, posible y valioso para todos; Fair Source, necesario para una inversión segura; y financiamiento colectivo a gran escala para bibliotecas y proyectos abiertos fundamentales
  • Debemos hacer sostenible el mantenimiento de bibliotecas importantes de código abierto y aceptar y normalizar una clase sostenible de licencias comerciales con código fuente disponible
  • Debemos abrir como código abierto todo lo posible con licencias OSI que permitan lo máximo posible y, sobre todo, convertir el código cerrado en cosa del pasado
  • Lo que puedes hacer ahora es:
    • convertir tu software cerrado en Fair Source, y
    • si dependes del código abierto, unirte a OSS Pledge

Lecturas relacionadas

5 comentarios

 
bus710 2024-08-13

La realidad es que, viviendo en un mundo capitalista, no se puede dedicar uno exclusivamente al open source. Por otro lado, también pienso que, si se trata de una biblioteca o utilidad realmente importante, sería bueno que recibiera más patrocinio de las empresas.

Las utilidades de escritorio/terminal en el espacio de usuario tienen especialmente difícil recibir este tipo de apoyo. Si es el kernel, las grandes empresas lo apoyan mucho; si es móvil, la App Store está bien comercializada; y en web o firmware, entre otros, se desarrolla con cierto análisis de mercado, así que hay menos de qué preocuparse. Pero el software y las bibliotecas que la gente común usa casi sin darse cuenta suelen tener barreras difíciles de definir, así que parece realmente muy difícil ganar dinero con ello. El open source es bastante activo, pero aun así no es fácil dar el siguiente salto.
 
bus710 2024-08-13

Como amo el software de código abierto y lo uso con gusto, también espero que las personas que trabajan duro entre bastidores y desarrollan con dedicación para el bien de muchos puedan beneficiarse mediante una configuración adecuada de licencias.
 
chabulhwi 2024-08-13

En el texto de Drew Devault titulado 'So you want to compete with or replace open source (Así que quieres competir con o reemplazar el código abierto)' aparece la siguiente frase.

From https://drewdevault.com/2024/07/…:

Nevertheless, the revolutionary economics of FOSS are based on collaboration, and are incompatible with competition.

En el software libre y de código abierto, cuando colaboran contribuyentes de distintas organizaciones se genera un beneficio compartido, pero en el software fair source hay pocas o ninguna razón para que otros contribuyentes colaboren gratis en beneficio de una persona u organización que disfruta de una posición monopólica.

De todos modos, yo también creo que el fair source es mejor que el código cerrado, y tampoco quiero que quienes mantienen software de código abierto quieran recibir una compensación por su esfuerzo y no puedan obtenerla.

Lo que sí dudo es que el fair source pueda disfrutar, igual que el código abierto, del beneficio de recibir contribuciones de desarrollo gratis. Y cuando alguien distribuye su software como código abierto, debe tener presente que quizá no reciba compensación económica de ningún usuario y que ese software puede terminar siendo un 'almuerzo gratis' para las grandes empresas de la nube.