Recientemente Redis cambió su licenciay han seguido montañas de desinformación, sin mencionar una bifurcación impulsada por la empresa de nube multimillonaria AWS. Entre esa información errónea se encuentra la seria pero declaración incorrecta que el cambio de Redis «significa que los desarrolladores ya no pueden usar el código de Redis».
Esto simplemente no es cierto. Para el 99,9999999999999% de los desarrolladores, sus derechos bajo la licencia siguen siendo exactamente los mismos que tendrían bajo la licencia más permisiva. fuente abierta licencias. que es hace Lo que significa es que las empresas de nube de billones de dólares como AWS ya no pueden tomar el código de Redis sin contribuir a cambio.
AWS, después de años de obtener grandes ganancias de Elasticache (su servicio Redis), entró en pánico y comenzó una bifurcación (valkey), reclutando a otros para no tener que asumir todo el coste. La empresa aprendió esa costosa lección con su bifurcación Elasticsearch, Búsqueda abierta. Para que no piense que se trata de que la comunidad gane a las corporaciones, tenga en cuenta que esta “comunidad” se parece más a una camarilla de empresas tecnológicas de billones de dólares que garantizan un suministro constante de software barato o gratuito al que no aportan prácticamente nada. Los miembros del club billonario tienen fundadores que valen más que las valoraciones de mercado de Redis y todo de los llamados malos del código abierto conjunto.
Es hora de que dejemos de fingir que las grandes nubes (y una en particular) no son directamente responsables de este desastre. La historia de Redis puede tratar de lucrar, pero es el club del billón de dólares el que tiene la gran bolsa de efectivo.
¿Qué pasa con los desarrolladores?
Primero seamos claros: los desarrolladores son en gran medida inmunes al cambio de licencia de Redis. Los únicos desarrolladores que están “perjudicados” por los cambios realizados por Redis son aquellos que trabajan para las empresas de la nube (e incluso ellos, con una excepción, no han contribuido en absoluto). Uno El comentarista de Hacker News hace esto muy claro:
Para uso propio en mi empresa o proyecto como particular:
- ¿Puedo tener acceso completo a la fuente, clonarla y modificarla? SÍ
- ¿Puedo hacer una solicitud de extracción para mejorarlo? SÍ
- ¿Puedo descargarlo, usarlo y tenerlo gratis en mi empresa incluso si mi proyecto es comercial y estoy ganando dinero usando Redis? SÍ
- ¿Puedo crear un producto que utilice Redis como tecnología de forma gratuita en mi startup? SÍ …
- Puedo
git clone
/make
/make install
¿Es como antes? SÍ …- ¿Puedo revender Redis como un servicio tomando el código fuente y ejecutándolo en mi nube sin una licencia paga? NO (boo hoo hoo)
¿Atrapá eso? Lo único (literalmente, lo único) que un desarrollador no puede hacer con el código de Redis es crear un servicio de nube administrado, a menos que quiera contribuir con la infraestructura utilizada para ejecutarlo. ¿Es eso de código abierto? No, no según el Definición de código abierto. ¿Pero es el Día del Armagedón para los desarrolladores, tal como se presenta? No.
Más allá de poder modificar y distribuir el código de Redis, considere la realidad de que la mayoría de los desarrolladores no desean hacerlo: lo que quieren es un código excelente que siga siendo compatible y mejorado con el tiempo. Aquí es donde la inversión de Redis Inc. es tan importante. La innovación en Redis no proviene de AWS (con una excepción que mencionaré más adelante), Microsoft o Google. Todo lo que se habla sobre el desarrollo comunitario de proyectos de código abierto es en su mayor parte un mito. Las empresas que saltaron detrás de la bifurcación de Redis no han hecho casi nada para llevar Redis a su estado actual.
Considerar Salvatore Sanfilippo quien fundó Redis. Uno pensaría que alguien así, que ha tenido un impacto tan tremendo en Redis, recibiría el apoyo de los forkers, ¿verdad? No tanto, como señala nuestro comentarista de Hacker News:
Antirez [Salvatore] tiene 21.000 seguidores y 9 patrocinadores que donan en GitHub. ¡NUEVE! Ni 10, ni 50, ni 1.000 patrocinadores… Son 9: un carpintero que perdió un dedo en el trabajo todavía puede contarlos.
Por cierto, ninguno de esos patrocinadores es un proveedor de nube. Claro, es muy posible que ya no les importe Sanfilippo, dado que ya no está involucrado con Redis, pero tampoco lo apoyaron mientras estaba construyendo Redis.
Lo que más necesitan los desarrolladores es un código excelente al que puedan acceder abiertamente, utilizarlo y del que puedan depender para su buen mantenimiento. Redis no les ha quitado esto. Todo lo que Redis hizo fue tratar de mantener el acceso de los desarrolladores a su código y evitar que las nubes desvíen los medios para invertir en ese código.
Cambiando de licencia, pero ¿por qué?
Vaughn-Nichols señala un patrón: “Una empresa creará su programa utilizando código abierto, ganará millones con él y luego (y sólo entonces) cambiará de licencia, dejando a sus contribuyentes, clientes y socios en la estacada mientras intentan hacerse con el control. miles de millones”. Está “harto de esto”, pero también lo están las empresas a las que critica. Nadie hace ese tipo de cambio a menos que esté bajo presión.
Vaughn-Nichols sugiere que el problema es que estas empresas «confundieron el ‘código abierto’ con un modelo de negocio». En eso también se equivoca. El problema es que las nubes confundieron el código abierto con un bien común del que podían tomar y no contribuir.
Ésta es una de las razones por las que he estado agitando por la OSI para estar a la altura de su misión e introducir un copyleft sólido para el software en la nube. Si se da a los desarrolladores (corporativos o no) los medios para proteger la libertad de su código, veremos menos software disponible. Es así de simple.
Mientras tanto, la bifurcación de Valkey nos dice que las nubes tienen miedo de perder el tren de salsa de Redis al que han contribuido poco. Nuevamente, me refiero principalmente a una nube en particular (AWS).
La ironía es que Redis es una de las pocas áreas en las que AWS realmente contribuye. yo regularmente citó el impresionante trabajo de Madelyn Olson, mantenedora de Redis, como ejemplo para AWS en el día a día. Parte de eso se debe a que Olsen es increíble. La otra razón es que ella era prácticamente el único ejemplo que tenía AWS. como ella notó Recientemente, «trabajé en Redis en mi tiempo libre». Eso no quiere decir que nunca trabajó en Redis. para AWS, pero también expone la realidad de la ingeniería de código abierto en AWS. Una de las principales razones por las que los ingenieros de AWS contribuyen poco en comparación con sus pares en otras nubes es que el liderazgo en ingeniería ve poco valor en hacerlo. Esto ha comenzado a cambiar en algunos equipos (como los equipos RDS/Aurora que se dieron cuenta de que les convenía hacer más por Postgres), pero son la excepción, no la regla.
¿No me crees? A pesar del nuevo amor de AWS por la Fundación Linux a través de la bifurcación Valkey/Redis, sería difícil encontrar contribuciones acordes con la cantidad de dinero que gana AWS. Basta con echar un vistazo a Estadísticas de desarrollo de CNCF.
Realmente, elige un proyecto. Qué tal si Kubernetes? AWS es el mayor proveedor de Kubernetes y gana miles de millones. Sin embargo, su contribuciones son liliputienses en comparación con Google o Red Hat. Las contribuciones de AWS a Kubernetes se ubican detrás de DaoCloud Network Technology Co. Ltd. y justo por delante de The Scale Factory Limited. Lo más probable es que no haya oído hablar de ninguna de estas empresas, pero contribuyen aproximadamente tanto como AWS.
Lo mismo ocurre con Prometeo, OpenTelemetríaetc. AWS se basa en estos proyectos para proporcionar un servicio en la nube, pero no hace el Top 5 en contribuciones a OpenTelemetry o incluso el Top 20 en contribuciones a Prometheus. En cualquier proyecto de código abierto que pueda nombrar (con la excepción de los pocos que ha lanzado AWS), AWS gana colectivamente decenas de miles de millones de dólares sin contribuir ni siquiera con decenas de miles de líneas de código.
¿Es esto de alguna manera una violación del código abierto? No, en absoluto. Pero es la razón por la que la gente ha criticado a Redis.
¿Qué tal una obsesión por el cliente?
Para que no piense que mi antiguo empleador estoy parcializado, quizás le interese saber que este era mi estribillo constante cuando dirigía el equipo de marketing y estrategia de código abierto en AWS. Lo último que hice antes de dejar AWS fue escribir un artículo de seis páginas sobre por qué y cómo AWS podría respaldar mejor a sus socios de código abierto. Mi argumento fue que AWS debería invertir más profundamente en el código y el éxito comercial de sus socios de código abierto, haciendo así más rentable para estas empresas mantener su software de código abierto.
En ese entonces creía, y sigo creyendo, que esto protegería la cadena de suministro de código abierto de AWS y al mismo tiempo serviría mejor a los clientes. Ningún cliente realmente quiere Valkey (la bifurcación de Redis), OpenTofu (la bifurcación de Terraform) u OpenSearch (la bifurcación de Elasticsearch). Quieren la versión original, “completa”.
Realmente no es difícil descubrir cómo garantizar que los clientes sigan obteniendo Redis, Elasticsearch, Terraform, etc. completos. Las nubes pueden aprender a asociarse mejor. Para ser justos, algunos ya lo hacen. Usemos Elasticsearch como ejemplo. Google Cloud lleva mucho tiempo apoyando a las empresas de código abierto y se asocia con elástico para ofrecer una excelente experiencia de Elasticsearch. Microsoft también ha contribuido activamente mediante código y dinero al código abierto, incluido un Amplia asociación con Elastic. ¿AWS? Bueno, escribió algunas publicaciones de blog que se presentaban a sí mismo como la víctima, luego bifurcó Elasticsearch, en un movimiento profundamente desobsesionado con el cliente.
Para ser justos con AWS, su cumplimiento de sus Principios de liderazgo apoya y complica su relación con el código abierto, como he escrito. El enfoque «obsesionado con el cliente» sería asociarse. Pero para “entregar resultados”, la empresa siente la necesidad de controlar. Eso hace que la asociación sea más difícil.
Es un dilema, pero ¿por qué el dilema interno de AWS debería convertirse en un problema para las empresas de código abierto que ya están haciendo la mayor parte o la totalidad del arduo trabajo del desarrollo de software? AWS ha realizado algunas mejoras, que he celebradopero nadie debería verlos como un héroe de código abierto en la bifurcación de Redis.
Por ahora, sólo podemos imaginar un mundo en el que las nubes contribuyan a las comunidades existentes en lugar de bifurcarlas cuando sus límites de mercado de billones de dólares se vean amenazados por la perspectiva de colaboración. Es fácil si lo intentas.
Copyright © 2024 IDG Communications, Inc.