paint-brush
Cebo y cambio de código abiertopor@shai.almog
1,078 lecturas
1,078 lecturas

Cebo y cambio de código abierto

por Shai Almog7m2022/09/01
Read on Terminal Reader
Read this story w/o Javascript

Demasiado Largo; Para Leer

Cuando la defensa del OSS va demasiado lejos y la codicia corporativa se hace cargo, el software libre se utiliza como una herramienta para destruir la competencia y perjudicar a la comunidad de desarrolladores.
featured image - Cebo y cambio de código abierto
Shai Almog HackerNoon profile picture

Estaba leyendo este artículo y quería publicar un comentario, pero sentí que esto justifica un artículo de respuesta. Primero, si no me conoces, he escrito un montón de código fuente abierto. Toda la plataforma y algo más. Creo que la opinión general que se expresa en ese artículo y muchas de las tonterías que veo en línea son demasiado simplistas y peligrosas.

Necesitamos que nos paguen

¿Quién pagará tu salario?


Las personas tienen varias respuestas para los modelos comerciales de código abierto. Por ejemplo, "consultoría" o el vago "apoyo". Siempre me pregunto si esas personas alguna vez intentaron vender consultoría. O tal vez "apoyo".


La gente no compra estas cosas. Especialmente en una economía en recesión. La forma en que los vendedores suelen vender estas cosas es la insinuación de que podría violar una licencia y sería mucho más fácil si pagara y obtuviera la licencia comercial. Incluso daré el "soporte" de forma gratuita. Sí, puede obtener algunos patrocinadores si pasa todo su tiempo en el teléfono. Es un proceso de ventas interminable. Persiguiendo pistas y haciendo llamadas. Manejar este tipo de negocio requiere muchos gastos generales.


Algunos desarrolladores utilizan licencias de código abierto problemáticas que luego pueden aprovechar para las ventas. Pero luego son vilipendiados como "no lo suficientemente abiertos". Ahí no se gana.


Sun Microsystems pagó mi salario durante parte de mi trabajo de OSS. Se hundieron y cayeron de una valoración de más de 200 mil millones de dólares, y finalmente se vendieron a alrededor de 7 mil millones. De acuerdo, no es porque fueran de código abierto. Eso es solo una anécdota, y no ayudó. Las personas reales pierden sus trabajos reales porque el código abierto no genera dinero. Incluso cuando lo hace, hace muy poco. La gente solía decir que termina con una porción más pequeña de un pastel más grande. Esto es cierto, pero solo se aplica a los grandes jugadores y tienes dos opciones: convertirte en el gran jugador o ver cómo un gran jugador se lleva las ganancias de tu arduo trabajo.


No me malinterpreten, no estoy en contra de las personas que se benefician de mi trabajo o incluso de las grandes corporaciones. Hago OSS por diversión y me encanta la idea de que la gente triunfe en base a mi trabajo. Pero entiendo la frustración que sienten muchos desarrolladores, y la "defensa del código abierto" general que veo en la gente es problemática.

Cebo y cambio

Lo malo es el cinismo empresarial. Toma Google. Abren Android de código cuando no tenía usuarios. Las empresas construyeron sobre él y también lo hicieron los desarrolladores. La defensa se formó a su alrededor porque "es de código abierto". Luego lanzaron Google Play Services de código cerrado, que luego agregó el requisito de SaaS Firebase para algunas funciones esenciales (es gratis para eso en este momento) y ahora tenemos dependencias profundas de código cerrado de proveedores que se hacen pasar por código abierto.


No tenemos que usar Google Play Services si queremos construir para Android. Por supuesto. Pero hace que sea mucho más difícil crear una aplicación de Android y si no la usa para algunas cosas (por ejemplo, empujar, comprar, etc.), entonces está prohibido en el mercado de Android más grande. La gran mayoría de los desarrolladores "simplemente lo usan". Esto significa que cualquiera que quiera borrar Google Play de su dispositivo Android a favor de una solución 100 % de código abierto; encontrará que tienen muy pocas opciones de software para aplicaciones.


Tome la búsqueda elástica. Eran de código abierto y lo mataban. Pero AWS se estaba bifurcando y realmente no estaba ayudando a su resultado final. Así que Elastic cambió su licencia para bloquear AWS. AWS comenzó su propia bifurcación. Algunas personas vilipendian a Elastic en esta historia, pero esas personas probablemente nunca tuvieron que luchar contra Amazon por la supervivencia de su negocio. En este caso, ambas partes usaron el código abierto como arma en una pelea comercial.


El caso de Java es ligeramente diferente. Java no era de código abierto y se hizo de código abierto más tarde. Todavía mantuvo IP sobre el idioma. Así que entiendo algo del férreo control de Oracle sobre el proyecto y lo acepto. Es bueno que haya una mano firme en el barco y contribuyó al éxito de Java. El problema con la demanda de Google fue que Oracle trató de ampliar su IP para incluir las API. Eso fue un error.

GPL es la mejor licencia

Hace aproximadamente una década, una startup llamada RoboVM lanzó un compilador de código abierto que traducía Java a aplicaciones iOS nativas. Fue genial y hablé bastante con el fundador de JavaOne. En ese entonces, estábamos considerando construir nuestra propia VM o elegir una solución como RoboVM. Terminamos con el primero y creamos nuestra propia máquina virtual, que era mucho más simple y se adaptaba mejor a nuestras necesidades ( también es de código abierto ).


Esa decisión se basó en méritos técnicos y creo que valió la pena, pero aún tengo un gran respeto por el equipo de RoboVM. Mi preocupación era Apple. Rompen muchas cosas... Construir una máquina virtual de bajo nivel es un peligroso juego del gato y el ratón en el que Apple cambiaría algo de repente y nos quedaríamos atascados. Una preocupación secundaria era la monetización. Comprendí que el equipo de RoboVM tendría que pagar los salarios de sus empleados y fundadores de alguna manera. ¿Cómo se gana dinero con un compilador de código abierto? Tenga en cuenta que esto fue hace una década y no había ningún precedente como Zig que pudiéramos ver como plantilla.


En algún momento, mis temores sobre las políticas de Apple se materializaron y Apple agregó un requisito de código de bits al apuntar a algunas plataformas. RoboVM pasó una gran cantidad de tiempo trabajando en la compatibilidad con códigos de bits y decidió cerrar su código fuente. Comprendieron que no pueden financiar el desarrollo continuo sin él. No tome esto como un juicio hacia su decisión. Entiendo totalmente que, como dije, monetizar OSS es muy difícil.


La GPL protegió a la comunidad al obligar a RoboVM a publicar el código de la versión final antes de la migración del bitcode. Esto permitió algunas bifurcaciones del código en años posteriores, pero aún no se mantiene. La compañía fue comprada por Xamarin y descontinuada rápidamente cuando Microsoft compró esta última. Sin la GPL, el código podría haber sido inaccesible. También obligó a terceros a publicar su código.


En este sentido, creo firmemente en GPL en lugar de licencias más permisivas como MIT, BSD, Apache, etc. Creo que nosotros, como comunidad, deberíamos preferir una licencia que preserve los derechos de la comunidad en lugar de los derechos corporativos. También proporciona una buena opción de monetización para el creador del proyecto. Simplemente vuelva a obtener la licencia como una licencia propietaria y cobre por eso. Desafortunadamente, la GPL es a menudo un punto de partida para muchos desarrolladores porque asumen incorrectamente que es malo para ellos. El opuesto es verdad. La GPL es una de las mejores formas de preservar los derechos de la comunidad a largo plazo.

¿Han cambiado las cosas?

Mencioné a Zig antes. Hay muchos otros ejemplos de bases que tuvieron éxito, como SQLite, Mozilla, etc. Llegar a este punto suele ser difícil y no necesariamente funciona para todos los proyectos de código abierto. Por ejemplo, casi todo el mundo usa cURL, pero no creo que veamos una base cURL. También tenga en cuenta que todos estos proyectos se basan en centros tecnológicos de EE. UU. Desde mi experiencia, es mucho más difícil conseguir patrocinadores en otros territorios.


¿Significa esto que todo el código abierto debe ser un pasatiempo o un mega proyecto que lo abarque todo?

Desafortunadamente, no tengo buenas respuestas. Pero tengo un problema: los defensores entusiastas del código abierto. ¡No estás ayudando!


El código abierto se está convirtiendo en un juego exclusivo para empresas. Se utiliza como arma entre las empresas tecnológicas que luchan. Hay un nombre para esto en el comercio minorista: líder de pérdidas.


En el comercio minorista, una gran tienda de supermercado vendería algunos productos a pérdida y anunciaría este precio increíblemente bajo. Esto atrae audiencias que compran otras cosas en el camino, por lo que el supermercado termina obteniendo ganancias. Pero la razón de esto es ahogar a la competencia. La competencia parece cara (ya que no pueden vender con pérdidas). Se van a la quiebra, y la gran empresa minorista aumenta los precios. Inicialmente, parece que obtuvimos un trato tremendo de la competencia, pero al final terminamos perdiendo. Por eso, algunos reguladores prohíben este tipo de prácticas, ya que acaban destruyendo un mercado.


El código abierto es utilizado de manera similar y cínica por las grandes tecnológicas. Forman “comunidades” mediante la contratación de ejércitos de profesionales de relaciones con desarrolladores para crear una mascarada de entusiasmo de base. A veces no necesitan monetizar el mercado, es suficiente para mantener fuera a la competencia.

TL;RD

Me encanta el código abierto y creo que es muy importante. Es por eso que no debemos permitir que las corporaciones lo conviertan en un arma. Necesitamos diversidad dentro del ecosistema y necesitamos apoyar proyectos críticos más pequeños. La idea de "descuentos" para proyectos de código abierto o "consultoría" no es sostenible.

Las grandes corporaciones utilizan el código abierto como arma para luchar entre sí, parece que nos beneficiamos a corto plazo. Pero a medida que ganan, la mentalidad corporativa se hace cargo y duplican el control.


Las soluciones que sugiero son:

  • Use GPL: está aquí para proteger los derechos de la comunidad. No es de extrañar que a las corporaciones no les guste.

  • No sea un puritano de OSS: las pequeñas empresas necesitan ganar dinero. Ofrecerán SaaS, extensiones de código cerrado, etc. Está bien.

  • Las grandes corporaciones no son benévolas: la defensa que veo en torno a los proyectos de OSS de las empresas FAANG (MAANG) es problemática. No son compatibles con OSS. Lo usan y lo aprovechan. No me malinterpreten, estoy agradecido por su código y es maravilloso que lo publiquen. Pero debemos ser cautelosos, tienen requisitos fiduciarios que pueden chocar con hacer lo "correcto" según los estándares de OSS.


No sé si lo próximo que haré será OSS. No sé si elegiré GPL ya que, como dije, la gente tiene problemas con eso. Pero sé esto: si eres un defensor del código abierto. Afina la retórica. No es útil.


También publicado aquí .