Skip to content

Instantly share code, notes, and snippets.

@bureado

bureado/open-en-2018.md

Last active September 23, 2020 07:14
Show Gist options
  • Save bureado/163232a6d0a194709428f8ba2908fd77 to your computer and use it in GitHub Desktop.
Save bureado/163232a6d0a194709428f8ba2908fd77 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
open-en-2018.md

¿Qué pasó con el open source en el 2018?

El 2018 fue un año extraño para el open source... funding decentralizado, cambios de licencias e inversiones sin precedentes que nos hacen pensar sobre los retos de sostenibilidad del open source. Para tratar de hacer sentido de todas las noticias de las últimas semanas, publiqué un video donde hablo sobre estos retos.

Este documento acompaña al video e incluye no solo las fuentes de las historias en el video sino muchos otros enlaces de interés. El objetivo de esta recopilación es permitirle a los activistas hispanoparlantes del open source conectarse con la conversación. ¿Ideas? ¿Comentarios? Estoy en Twitter: @bureado.

In English: this is a write-up on open source sustainability that I developed in early 2019 for Spanish-speaking audiences. All the sources are in English (which is exactly the problem I was trying to solve) and if you're looking for a broader "what happened with open source in 2018" summary in English, check David Ryan's write-up.

Los destacados

En el video se destacan las siguientes notas. Si quieres ponerte al día con toda la trama y solo tienes tiempo de consultar algunas fuentes, esta es la lista esencial:

Algunas de estas noticias se convirtieron en tópicos en si mismos, pero todas están más o menos conectadas con el diálogo de los últimos meses sobre sostenibilidad del open source. Un buen ensayo que agrupa las distintas subconversaciones bajo el paraguas de sostenibilidad es el de Stephen Walli.

Sostenibilidad, soporte y suscripciones

Tidelift propuso un modelo de suscripción, bajo el cual las empresas que usan software open source pagan a Tidelift una tarifa y ellos toman una parte y distribuyen el resto a los desarrolladores originales.

Es un cambio de pensamiento del modelo de soporte pagado que fue popularizado por Red Hat, que se convirtió en una compañía multibillonaria gracias al mismo. Otras empresas como Hortonworks o Cloudera han trazado esta senda, pero a un costo muy alto tanto en capital como en tiempo y recursos.

Tidelift ayuda a los consumidores de open source a garantizar el compliance. Para el desarrollador del proyecto original, Tidelift ofrece la posibilidad de recibir algún ingreso sin tener que "vender" contratos de soporte. Tidelift ha recibido $15M en capital de riesgo, y dedicará $1M para este programa, desembolsando hasta $10K cada 2 años... lo cual no es realmente suficiente para mantener una persona. Aquí hay más detalles sobre la mecánica de este modelo, y aquí la información oficial de la suscripción. (Mientras escribía este ensayo, Tidelift recibió otros $25M en capital de riesgo)

Parte del riesgo para el proyecto es que, a diferencia de Red Hat o Cloudera o MongoDB, o de comunidades más grandes como las que están arropadas bajo las distintas Fundaciones, Tidelift no da soporte y el proyecto debe continuar haciéndolo, lo cual es muy costoso y complejo como describe Nadia Eghbal, y capturado en el sentimiento de muchos usuarios en GitHub o Twitter.

Las ineficiencias en la mecánica económica no solo tienen que ver con la posibilidad o no de ofrecer soporte a una comunidad cada vez más activa, más grande y más exigente. Hemos visto muchas situaciones relacionadas con la seguridad (por ejemplo, el ataque dirigido a event-stream en Node.js) que si bien no son nuevos (las incógnitas sobre qué ocurre con los proyectos cuando desarrolladores claves se ausentan o no tienen recursos o son comprometidos han existido desde que hay desarrollos colaborativos y de voluntarios) sí hemos visto por primera vez en los últimos años el impacto global, inesperado y catastrófico de algunas de esas fallas (un ejemplo interesante es el de RethinkDB)

Algunos proyectos en los que Tidelift invierte: Vue, Material-UI, Babel, Gulp, Fabric, Active Admin, Doctrine, and StandardJS. Del artículo de TFIR: Right now, we have the most subscription revenue share available for packages in the Javascript, Java, Ruby, Python, and PHP ecosystems because that is where we are seeing early customer demand. In fact, many packages in these ecosystems may already have payouts of up to $10,000 available for them on the platform.

En general, este modelo está optimizado para librerías/dependencias, como en este ejemplo buscando openssl. Aquí un hilo en Twitter con algunos ejemplos de proyectos que suelen "olvidarse".

Incluso hay ciertas iniciativas para hacer que la metadata de donaciones sea más fácil de consumir programáticamente.

Otro modelo que se ha propuesto, que tendría que ser implementado como una cláusula adicional a las licencias, es el del pago de un porcentaje de la nómina a un fondo del cual se puedan desembolsar a distintos proyectos.

Productores y consumidores (el problema de los freeloaders)

Por supuesto, el concepto de lifters de Tidelift no es ni el primero ni el único modelo tratando de buscar una forma de distribuir los beneficios económicos del software open source. Muchos desarrolladores que lideran proyectos importantes promocionan sus sitios de Patreon y otras plataformas de micropagos/microfondos. En el ciclo anterior, e incluso en el actual, era más frecuente ver estilos de "mecenazgo" y patrocinios por los actores prevalentes en el sistema, como entes gubernamentales o grandes empresas de tecnología (aquí un ejemplo de Google).

Matt Asay argumenta que: "Because if there's corporate value attached to a project, savvy companies pay developers to contribute. This is the only way that developers could afford to work on a given project full time, which is the only way a project gets the attention it needs to flourish."

Incluso, ciertas comunidades que se organizaban alrededor de una necesidad puntual (como extender el soporte de una versión mucho más allá de su ciclo de vida en el caso de Freexian) lograron una cierta estabilidad financiera. Aunque interesante (mirar este hilo en Reddit) en realidad era bastante ad-hoc y a escalas pequeñas.

Pero hay que reconocer que el tema de contratar contribuidores a proyectos open source permanece muy en voga (aquí hay sugerencias) en empresas de todas las industrias. De hecho, una característica del ciclo actual es como el open source potencia las contrataciones y retención de talento.

Lawrence Hecht hace un excelente resumen tanto de las motivaciones que tienen las empresas para contribuir al open source como de la naturaleza de las contribuciones monetarias. Por ejemplo, Hecht cita un estudio de Digital Ocean donde dice que solo un cuarto de las empresas donan $1,000 o más a proyectos open source, y menos del 20% pertenecen a una fundación. Y si hablamos de ese grupo, las motivaciones para pertenecer a las fundaciones son muchas (y no necesariamente mutuamente exclusivas) y van desde lo ya hablado (atraer talento) hasta, lógicamente, promover sus propias soluciones.

Lo que está claro es que cuando se trata del desembolso monetario real, el dinero suele ir a conferencias, entrenamiento y otros programas y no a sustentar a los desarrolladores. En términos de tiempo, alrededor de un tercio de las compañías (en el estudio de Digital Ocean) permiten a los empleados usar su tiempo en proyectos open source, aunque en la mayoría de los casos se limita a 1-5 horas por semana. Lo interesante es que cada vez más, y en particular en empresas de tecnología (ISVs y proveedores del cloud en especial) las contribuciones y el trabajo comunitario están relacionados de una forma u otra con el trabajo, como lo dijeron 2/3 de los participantes en la encuesta de GitHub citada por Hecht.

Hay otras plataformas como IssueHunt que manejan un modelo similar al de Tidelift o BountySource que busca extender el modelo de bounties que ha funcionado bien en el espacio de seguridad de la información.

Incluso hay modelos en los cuales se utilizan ingresos por publicidad (como ReadTheDocs) y otros mecanismos más similares al mercadeo de referrals. Nadia Eghbal compila una lista de modelos, ninguno de los cuales es en realidad único o específico del open source. Dicho eso, existe una lista de plataformas mediante las cuales se puede hacer llegar capital a proyectos open source. El problema no es la plataforma. Como en el caso de donaciones a ONGs o de micropréstamos a poblaciones excluídas y necesitadas, el problema es la transparencia, el flujo de información y el acceso.

Si nos enfocamos en el "gran problema", de que solo algunas compañías reciben millones en capital de riesgo y son valoradas en billones, y que ese dinero no está distribuído de forma justa y eficiente entre, por ejemplo, los 30M+ de personas en GitHub, no podemos concluir que solo con Patreon, etc., vamos a resolver el problema. De hecho, en el excelente blog de Open Collective se habla de lo importante que es cambiar la relación del donante con el proyecto, pues no puede ser un acto de caridad, y se requiere cambiar muchas otras cosas de la infraestructura financiera, desde los mecanismos de pago hasta problemas de taxación más allá de las fronteras de una región en particular.

En su artículo Salvar al open source para salvar el mundo, John Mark Walker hace referencia al estudio de Nadia Eghbal para Ford Foundation (2016) en el cual se trae de nuevo la idea de considerar al open source como infraestructura. Y Mark insinúa que esto implicaría que el gobierno jugaría un papel más preponderante desde el punto de vista regulatorio, entendiendo que si bien el open source jugaba un papel antagónico a los monopolios en el pasado, hoy en día es usado por los monopolios para aumentar su poder.

En este artículo, Storj argumenta que aunque la industria del cloud está valorada en $180B y dos tercios de las aplicaciones en la nube usan open source, las compañías que trabajan con open source están valoradas en poco más de $5B. Sin embargo, este número es muy debatible - otros índices como oss.cash hablan de $140B - solo la adquisición de Red Hat por parte de IBM significó $34 billones. Mientras que en Redmonk se argumenta que tiene que ver con un factor de conveniencia (el cloud es más conveniente que el open source) es más probable que se trate sobre lo dicho por Joseph Jacks: en realidad el open source ha generado trillones de dólares en valor que está siendo capturado por muchas partes. Pero en todo caso, sobre este problema Storj propone un nuevo modelo, que llaman "asociaciones decentralizadas", en las que los usuarios de open source puedan generar ingresos para el proyecto que están utilizando al subir archivos y utilizar almacenamiento decentralizado. (Hay una presentación sobre este modelo del 2018, aunque muchos detalles no están claros)

Otro modelo podría venir inspirado de otras partes de la gig economy. Compañías como Uber y más recientemente Airbnb han propuesto la idea de que los miembros de su cadena de valor (como los anfitriones en Airbnb) puedan recibir una participación de la compañía.

Como un ejemplo, Citus Data se ha comprometido a donar 1% de su valor a las organizaciones sin fines de lucro que están detrás de PostgreSQL (en el espíritu pero más allá de la iniciativa Pledge One Percent) y Eventbot dona 3% de sus ingresos, temas que se cubren en varios artículos y cuyas implicaciones en ecosistemas de desarrolladores ya han sido comentadas por parte de Nadia.

Incluso en estos casos, sin cambiar otros elementos del sistema financiero internacional estaríamos ante una situación que lamentablemente excluiría a muchas personas e ignora la colaboración global del open source.

En resumen, algunos de los problemas que tenemos en este espacio incluyen:

  • No sabemos muy bien cuáles proyectos necesitan ayuda
  • Nos sobran plataformas, pero todas son ineficientes
  • Muchas cosas (que no dependen del open source) tienen que cambiar para lograr un flujo más eficiente de recursos

Este artículo es un excelente resumen de la discusión que ha habido en este espacio durante todo el año, en el contexto de eventos como MozFest y Sustain OSS.

El rol del proveedor de nube

Licencias: ¿qué pasó exactamente?

Aquí hay algunos enlaces sobre los cambios en las licencias de algunos proyectos open source en el 2018:

Algunas de las noticias que más resonaron en 2018 estuvieron relacionadas con lo que ciertas compañías como Redis (Commons Clause) y MongoDB (SSPL) hicieron relacionado con el licenciamiento para cambiar la dinámica de la relación con ciertos proveedores de cloud computing que añadían valor sobre sus productos. La opinión de muchos observadores es que esto tiene que ver con modernizar el licenciamiento en el mundo del cloud. (Es importante resaltar que esto es diferente de la tendencia de alejarse del copyleft que ha venido ocurriendo por varios años ya, pero que aun mantenía a todos los actores dentro del paraguas de open source, aunque también se debate sobre la viabilidad comercial de las licencias copyleft)

La recepción general de estos anuncios ha sido negativa. La crítica suele dividirse en dos grupos: los que no creen en el problema de fondo (un desequilibrio en la relación productor/consumidor representado por un gran proveedor de servicios en la nube) y los que independientemente de su opinión sobre dicho problema, consideran que esta "ingeniería de licencias" no es open source. Pero en general, existe preocupación sobre si estos nuevos modelos planteados harán más daño que bien, pues probablemente requieran que más personas contribuyendo tengan que consultar a los abogados de su empleador para determinar las implicaciones de contribuir código al mismo, mientras que podrían utilizar una licencia establecida cuyas implicaciones y expectativas son más claras.

En la mayoría de los hilos de Twitter citados aquí encontrará a muchos de los mismos comentaristas (Matt Asay, Adam Jacob, John Mark Walker, Stephen Walli, Ross Gardler, Matthew Garrett, Joseph Jacks, Stephen O'Grady, Lawrence Hecht, etc.) pero este hilo de Adam Jacob es un excelente análisis de los problemas más allá de estos dos bandos. En este análisis se habla sobre como esto podría acabar con la comunidad, generando un nuevo desequilibrio entre el contribuyente "principal" (usualmente una entidad con fines de lucro) y el resto de la comunidad.

(Es importante resaltar que otros comentaristas han escrito sobre la posibilidad de que licencias como estas no puedan sustentarse en las cortes.)

Y entre otras consecuencias más directas que han incluido la remoción de productos como MongoDB de distribuciones como Fedora o Debian, o el enfrentamiento directo entre MongoDB y AWS con el lanzamiento por parte de AWS de un producto compatible con la API de MongoDB.

No podríamos dejar de mencionar que una reacción... extraña a todo esto fue la que dió Oracle comparando a las compañías detrás de estos cambios con, básicamente, cualquier otro proveedor de software propietario.

https://www.geekwire.com/2018/open-source-companies-considering-closed-approach/

El rol del capital de riesgo

Existe un debate histórico que intenta establecer una analogía entre los modelos enfrentados de desarrollo y distribución de software (software propietario y open source) y modelos económicos enfrentados como el capitalismo y el socialismo.

En general, no solo el open source y el capitalismo resultan muy compatibles, sino que las tendencias actuales nos muestran que los proyectos más importantes continúan en la esfera de influencia de las más grandes corporaciones del mundo. Proyectos como Visual Studio Code, React, TensorFlow, Angular, Kubernetes o TypeScript están todos relacionados con empresas como Google, Microsoft y Facebook.

A pesar de que el open source no es nada nuevo, en la última década y en particular en los últimos cinco años hemos visto como está jugando un papel preponderante en la mecánica económica de muchas empresas de tecnología. Ahora, es muy normal que en los reportes a los inversionistas o en la cobertura de medios especializados en economía y finanzas se hable de el papel estratégico del open source, ya sea a nivel de proyectos específicos o de forma más general cuando refleja cambios en los modelos de negocio.

En una serie de dos artículos (parte 1 y parte 2) y utilizando el ejemplo de Facebook y React, David Axelrod argumenta dos caras de una moneda: la importancia que tiene para las empresas "monetizar" sus inversiones open source, y la necesidad de sostener el ecosistema que rodea a esas inversiones. Aunque con un cálculo quizás ingenuo, él estima que Facebook recibe $19B en beneficios (principalmente en calidad del código, agilidad, reclutamiento, etc.) por cada $1B en costos de desarrollo.

Sin embargo, un fenomeno relativamente nuevo y representativo del ciclo actual del open source es la presencia de inversores con capital de riesgo (venture capitalists) quienes están detrás de muchas de las empresas que crean o mantienen de forma significativa muchos de los proyectos open source que conocemos hoy en día. En términos de obtener retorno por su inversión, esos inversores tienen algunos "frenemies": empresas de open source que cotizan en bolsas públicas (como Red Hat o Cloudera) y compañías de tecnología como las mencionadas antes. Son "frenemies" pues utilizan los productos open source de las compañías en las que ellos invierten, no necesariamente contribuyendo a los números de ventas, y a la vez pueden ser los compradores de estas compañías.

Es importante entender este factor para entender la génesis de algunos de los anuncios que más han dado de que hablar en 2018 relacionados con el licenciamiento. En el artículo La cruzada contra el abuso del open source, uno de estos inversionistas explica como ejecutivos y abogados de distintas de estas startups se reunieron para crear Commons Clause y SSPL, con el apoyo de organizaciones como FOSSA quienes están en el negocio de compliance. En este artículo se argumenta que "el comportamiento de los proveedores de infraestructura del cloud representa una amenaza a la existencia del open source". En general, en este artículo se presentan muchas perspectivas positivas sobre estas nuevas licencias, principalmente desde una perspectiva legal, y recibió fuertes críticas de múltiples actores (por ejemplo, este hilo de Josh Simmons)

Bryan Cantrill habla sobre como estas nuevas licencias no van a resolver los problemas de negocio subyacentes pues muchas de las compañías (virtualmente todas startups fruto del capital de riesgo) simplemente no saben cómo hacer dinero (o, desde otro punto de vista, solo saben hacer dinero como proveedor de servicios, mercado en el cual los grandes cloud providers son mucho más eficientes) lo cual abre la puerta a otra discusión sobre modelos de negocios (lo cual da para otro ensayo, aunque aquí hay una buena discusión de John Mark y este excelente resumen de Mike Volpi)

¿Qué papel juegan las fundaciones?

Pero de forma muy interesante, en el mismo artículo se levanta otro tema importante, relacionado con el rol que tienen las fundaciones y las organizaciones que de una manera u otra representan la gobernabilidad de muchos proyectos de open source.

https://www.linux.com/blog/2019/1/2019-and-strength-open-source https://sfconservancy.org/blog/2018/oct/16/mongodb-copyleft-drafting/ https://nadiaeghbal.com/foundations

John Mark Walker propone revisitar a los gremios y fundaciones como organizaciones que puedan encargarse de distribuir fondos recolectados bajo una regulación gubernamental. El problema es que este no es el modelo actual, y el modelo actual ha generado mucha desconfianza entre los desarrolladores y miembros de la comunidad (en este artículo sobre vendor-neutral marketing se plantea el rol de The Document Foundation como una entidad comercialmente activa en su ecosistema actual, que está compuesto en gran parte por integradores y no por ISVs con capital de riesgo)

Ideas finales

  • Las licencias no son la solución
    • Va a ser difícil comprar open source así
    • Va a ser mucho más difícil contribuir al open source así (incentivos o fricción)
  • El open source no va a morir, pero está sufriendo y va a sufrir más
  • Se desajusta la competencia (entre proyectos, y con los grandes proveedores) De hecho Adam Jacob lo llama el Movimiento de Licencias No-Competitivas lo cual suena genial hasta que se entiende que estas licencias cambian fundamentalmente la relación entre las entidades comerciales de un proyecto y su comunidad: la licencia se presenta como algo para la comunidad cuando en realidad es una relación de poder. Y porque en vez de generar "codicia" en todos los participantes, limita la codicia a solo uno.
  • El cloud... es diferente

Commercial open source companies are attempting to solve the problem of cloud providers re-implementing their software, which is clearly an issue. But they have another, potentially larger problem: the commercial markets associated with stand alone, on premise software generally are in decline and have been for years. In some cases – Elastic or MongoDB, as two examples – the vendors have strong SaaS offerings of their own. But in several cases, these licenses are being employed by businesses that do not to offer their open source as a service. Which means, effectively, that commercial providers are not providing customers what they want while attempting to protect a market that is shrinking over time. Making matters worse for companies that decline to pursue service-based models is that they are denying themselves access to the invaluable customer telemetry data AWS and others accumulate every second their workloads run.* Ben Thompson también habló sobre esto, muy al estilo Stratechery: https://stratechery.com/2019/aws-mongodb-and-the-economic-realities-of-open-source/

No se trata solo de que los proveedores de cloud quieran aumentar sus márgenes usando software por el que no pagan, sino de que los clientes y usuarios del cloud tienen ciertas expectativas de su proveedor. En la nube se hacen sus propios suiches, sus propios CPUs... y Roman también habla de open source en el mundo de la nube (su resumen es mucho más extenso)

Al final de su artículo, Krishnan se refiere brevemente a exactamente el tipo de cosas que los clientes de los proveedores del cloud están empezando a necesitar/pedir.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment