Nubes y polvorín de código abierto

Nubes y polvorín de código abierto

“Europa hoy es como un polvorín y los líderes son como gente fumando en su interior. Una chispa provocará una explosión que nos enterrará a todos. No sé cuándo sucederá, pero sé dónde. Todo se arruinará por algún acontecimiento estúpido en los Balcanes" - Otto von Bismarck, 1878

Hace cien años, el 11 de noviembre de 1918, se firmó un armisticio que puso fin a la Primera Guerra Mundial. Hoy es difícil imaginar el número de vidas perdidas en esa guerra. Por ejemplo, en Estados Unidos consideran con razón la guerra de Vietnam como un desastre militar. En veinte años de lucha, Estados Unidos perdió 58 soldados. En comparación, sólo en la Primera Batalla del Marne en 318, los aliados perdieron cuatro veces más. En cinco días.

Algunos dirán que los horrores de la guerra no podrían haberse predicho. El problema es que al menos algunas de las partes involucradas eran muy conscientes de las consecuencias. Se dice que el Secretario de Asuntos Exteriores británico, Edward Gray, después de hablar en el Parlamento en apoyo de la guerra, dijo: “Las lámparas se están apagando en toda Europa. No volverán a arder durante nuestra vida”.

Por lo tanto, en los años siguientes, los historiadores intentaron responder a la pregunta: si las consecuencias eran claras, ¿cómo permitieron que sucediera? Crisis de julio - una serie de acontecimientos relacionados que hicieron de la guerra el único resultado posible.

Aunque extremadamente compleja en detalles, la respuesta es simple. Dada la atmósfera y las estructuras políticas de la época, ninguno de los participantes sintió que tuviera una alternativa. De hecho, una de las cosas más aterradoras de estudiar las causas de la guerra es que si se consideran las realidades políticas de la época, en realidad es fácil entender las justificaciones de las acciones de cada estado.

Al final, estaremos de acuerdo en que la guerra era, de hecho, inevitable. La facilidad para aceptar esta verdad es realmente aterradora.

Hace tres años, un fondo de riesgo reunió a un pequeño grupo de representantes de medios, proveedores y analistas, incluidos nosotros, para discutir la importancia del código abierto en los negocios. Tras presentar su propio modelo, el socio de la empresa de capital riesgo presentó a un grupo de directivos de empresas comerciales colaboradoras de código abierto. Cada uno de ellos detalló cómo el código abierto reemplazó a las alternativas propietarias para los clientes.

Por supuesto, estamos de acuerdo en que el cambio de los desarrolladores al código abierto en toda la empresa está cambiando la naturaleza de las adquisiciones. Hasta cierto punto, ésta es una creencia fundamental que hemos estado promoviendo durante muchos años. En 2011 publicamos un artículo. "Implementación de abajo hacia arriba: el fin del suministro tal como lo conocemos". Pero lo interesante del modelo propuesto no era lo que decía sobre el presente, sino lo que no podía decir sobre el futuro.

En el evento no hubo ninguna mención directa a los servicios en la nube. Se ha dicho que los inversores y los desarrolladores comerciales de OSS compiten con el software propietario. No hubo ningún enfoque particular en Amazon y otros proveedores de nube a hiperescala, ni siquiera fueron nombrados. Se rechazó cortésmente una pregunta sobre este tema.

Esto es interesante porque en RedMonk, en ese momento, al evaluar equipos comerciales de código abierto, les pedimos que respondieran una pregunta estándar simple: "¿Quién es su competencia?" Si mencionaban una alternativa patentada, sugería que la empresa estaba mirando hacia el pasado. Si la respuesta era la nube, era seguro asumir que la startup estaba mirando hacia el futuro.

Como vemos, este pensamiento ya ha llegado al mercado. De hecho, en los últimos 12 a 18 meses ha habido una revolución. Mientras que antes las empresas consideraban dignos de mención a proveedores de nube como Amazon, Google y Microsoft, ahora los ven como una amenaza mortal. El miedo a los proveedores de nube se ha vuelto tan abrumador que los proveedores comerciales de código abierto a menudo toman decisiones estratégicas, en contra del consejo de los consultores, que violan las normas culturales de código abierto, causan relaciones públicas negativas masivas y sostenidas y ponen en peligro las relaciones con desarrolladores, socios y clientes. En particular, están recurriendo cada vez más a modelos que desdibujan la línea entre el software de código abierto y el software propietario en un intento de obtener las ventajas de ambos mundos, pero que probablemente terminen con las desventajas de ambos.

Los proveedores comerciales de código abierto tomaron estas medidas con previo aviso de los riesgos. Esto habla de su evaluación de sus perspectivas en un mundo cada vez más dominado por nubes masivas que amplían la gama de servicios. Por supuesto, este tipo de decisiones estratégicas tienen consecuencias negativas graves e inevitables, pero los proveedores comerciales de código abierto (o al menos sus inversores) consideran que no hacer nada es una opción aún más perjudicial.

Será interesante ver si esta creencia continúa después del anuncio de Amazon Web Services esta semana. Aquí hay un resumen de la historia que condujo a los acontecimientos actuales:

  • 2010: escrito por Shay Banon hace casi diez años Elasticsearch es un motor de búsqueda de código abierto con licencia permisiva. Resultó ser tan popular que finalmente se formó una organización comercial a su alrededor. Elastic NV (originalmente Elasticsearch BV) ha pasado por múltiples rondas de financiación por un total de más de 6 millones de dólares, realizó una oferta pública inicial (IPO) en octubre pasado y ahora está valorada en poco menos de XNUMX mil millones de dólares.
  • 2015: Cinco años después de la fundación del proyecto, presumiblemente en respuesta a las solicitudes de los clientes, Amazon lanzó un servicio en la nube llamado Amazon Elasticsearch Service basado en esta licencia permisiva. Competía directamente con las ofertas comerciales de Elastic NV, tanto en las instalaciones como en la nube.
  • 2018: Debido en parte a la competencia de esta y otras nubes, Elastic NV ha comenzado a desdibujar la línea entre su oferta de código abierto y sus complementos con licencia patentados, particularmente x-pack. Es de destacar que Elastic no siguió los pasos de algunos de sus colegas, sino que intentó resolver el problema utilizando licencias híbridas, pero comenzó a mezclar código fuente abierto y propietario en un repositorio, y las compilaciones predeterminadas incluían este software propietario.
  • 2019: Amazon ha tomado varias medidas en respuesta esta semana. Primero, con el apoyo de Expedia y Netflix, introdujo lo que considera una “distribución” de Elasticsearch. Pero está destinado a funcionar como una bifurcación en todos los aspectos. En segundo lugar, el proyecto incluye complementos de código abierto similares a las funciones que cobra Elastic NV sin ponerlas a disposición del público. En tercer lugar, al igual que con el servicio original de AWS basado en Elasticsearch, la empresa utilizó el nombre Elasticsearch para el proyecto.

Teniendo en cuenta que las contradicciones anteriores se han convertido en un conflicto abierto, surgen muchas preguntas. ¿Cómo se llegó a esto? ¿Era esto realmente inevitable? Y la pregunta obvia es: ¿quién tiene la culpa?

Al menos una de estas preguntas es fácil de responder. Este movimiento se esperaba desde hace algún tiempo. Al menos desde septiembre, cuando apareció la licencia. Cláusula de los comunes:

Por supuesto, parece poco probable que los proveedores de la nube en todo el mundo comiencen a implementar y otorgar licencias de software de código abierto bajo la licencia de la Cláusula Común de proveedores comerciales. De hecho, la Cláusula de los Comunes puede resultar contraproducente. Aumenta la probabilidad de que los proveedores de la nube intenten alejar a los desarrolladores clave y realizar una bifurcación pública o privada del proyecto. Esta es una opción más económica, que también proporciona el control necesario sobre los activos de software.

La controversia Amazon-Elastic es el resultado de un choque de modelos. Para crédito de Banon y Elastic, el software Elasticsearch ha demostrado ser extremadamente popular, gracias en parte a su licencia permisiva.

Sin embargo, las licencias permisivas también permiten que los proveedores de la nube como Amazon utilicen el sistema. Para no perder beneficios y satisfacer las necesidades de sus clientes, los proveedores de la nube probablemente ofrecerán servicios nativos para Elasticsearch y proyectos similares que sean populares y bien conocidos.

  • La concesión de licencias no es realista. A pesar de lo que piensan algunos inversores, la realidad es que agregar términos comerciales a software que antes era gratuito nunca obligará a los principales proveedores de servicios en la nube a registrarse. Ninguna empresa que opere a esta escala querría subcontratar un servicio importante (ya sea desarrollo de productos o fijación de precios) a un tercero que no controla.
  • La adquisición es otra opción para satisfacer la demanda, pero no escala bien. Incluso los proveedores ricos de la nube no quieren pagar dinero extra para comprar cada nuevo servicio de su cartera, especialmente cuando existe una alternativa más barata y sencilla, y aquí la hay.
  • En las comunidades de código abierto, una bifurcación ha sido históricamente vista como una opción tóxica, pero desde una perspectiva de relaciones públicas se vuelve más aceptable cuando un proveedor comercial de código abierto compromete su propio estatus al adoptar tácticas y prácticas que van en contra de las normas de la comunidad de código abierto. . En tal caso, incluso terceros grandes pueden intentar tomar la autoridad moral y al mismo tiempo servir a sus propios intereses.

Frente a estas opciones, una bifurcación parece una respuesta lógica de un servicio en la nube ante la aparición de condiciones de licencia desfavorables. Por eso la decisión de Amazon era esperada e inevitable. Y por tanto es difícil determinar quién es el culpable de la situación actual. En principio, ambas partes actuaron de forma lógica, como era de esperar, dadas sus perspectivas, capacidades y derechos legales.

Es probable que Amazon sea el primer, pero no el último, proveedor de nube en hacer esto. Otros también intentarán conciliar la demanda de los consumidores con la falta de restricciones legales a la creación de sus proyectos, como "una distribución abierta para Elasticsearch". Probablemente llegarán inevitablemente a la conclusión de que es beneficioso. Aparentemente, los proveedores comerciales de código abierto también inevitablemente concluirán que la nube representa una amenaza tan grande que los límites del código abierto deberían ampliarse.

De hecho, la única pregunta real es si los desarrolladores de código abierto aprenderán de la situación actual con Elastic, que ahora compite con Amazon no sólo en productos, sino también en código abierto. ¿Entenderán que los beneficios de algunos enfoques controvertidos de concesión de licencias simplemente no justifican los costos?

Sin embargo, lo más probable es que se mantenga el status quo. Los incentivos y motivos de ambas partes son claros, comprensibles y lógicos en el contexto de sus respectivos modelos. Modelos que siempre se contradecirán internamente, aunque estén indisolublemente ligados.

Hace cien años, líderes de decenas de países decidieron entrar en conflicto. Sabían que el conflicto les costaría caro, que sería terriblemente destructivo y del que probablemente nadie saldría victorioso. Lo hicieron porque no vieron otra opción.

La industria tecnológica tampoco parece verlo.

Nota: Amazon y Elastic son clientes de RedMonk, al igual que Google y Microsoft. Expedia y Netflix no son clientes de RedMonk.

Fuente: habr.com

Compre alojamiento confiable para sitios con protección DDoS, servidores VPS VDS 🔥 Compra alojamiento web fiable con protección DDoS, servidores VPS VDS | ProHoster