«A Europa hoje se assemelha a um barril de pólvora, e os líderes como pessoas fumando dentro. Uma faísca provocará uma explosão que nos enterrará a todos. Não sei quando isso ocorrerá, mas sei onde. Um evento estúpido nos Bálcãs estragará tudo» — Otto von Bismarck, 1878
Há cem anos, em 11 de novembro de 1918, foi assinado um armistício que pôs fim à Primeira Guerra Mundial. O número de vidas perdidas naquela guerra é difícil de imaginar hoje. Por exemplo, nos Estados Unidos, a guerra do Vietnã é considerada uma catástrofe militar. Durante vinte anos de combates, os EUA perderam 58.318 soldados. Para comparação, apenas na primeira batalha do Marne, em 1914, os aliados perderam quatro vezes mais. Em apenas cinco dias.
Alguns dirão que os horrores da guerra eram imprevisíveis. O problema é que pelo menos algumas das partes envolvidas tinham uma boa compreensão das consequências. O ministro das Relações Exteriores britânico, Edward Grey, após um discurso no Parlamento em apoio à guerra, é dito que disse: «As luzes se apagam por toda a Europa. Na nossa vida, elas não acenderão novamente».
Portanto, nos anos seguintes, os historiadores tentaram responder à pergunta: se as consequências eram claras, como permitiram — uma série de eventos interconectados, que resultaram na guerra como a única saída possível.
Embora seja extremamente complexo em detalhes, a resposta é simples. Considerando a atmosfera e as estruturas políticas da época, nenhum dos participantes sentia que tinha uma alternativa. Uma das coisas mais assustadoras ao estudar as causas da guerra, na verdade, é que, quando você considera as realidades políticas da época, torna-se bastante fácil entender as justificativas para as ações de cada país.
No final, concordamos que a guerra era realmente inevitável. A facilidade em aceitar essa verdade é realmente perturbadora.
Três anos atrás, um fundo de investimento reuniu um pequeno grupo de representantes da mídia, fornecedores e analistas, incluindo nós, para discutir a importância do open source nas atividades comerciais. Após a apresentação de seu próprio modelo, um parceiro da empresa de venture capital apresentou um grupo de líderes de empresas comerciais parceiras de open source. Cada um deles descreveu em detalhes como o open source substituiu as alternativas proprietárias para os clientes.
Com certeza, concordamos que a transição dos desenvolvedores para o open source em larga escala está mudando a natureza do fornecimento. De certa forma, essa é a principal crença que promovemos ao longo dos anos. Já em 2011, publicamos um artigo . Mas o que era interessante no modelo proposto não era o que ele dizia sobre o presente, mas sim o que ele não conseguia prever sobre o futuro.
No evento, os serviços de nuvem não foram mencionados diretamente. Foi dito que investidores e desenvolvedores comerciais de OSS competem com software proprietário. Não houve atenção especial para a Amazon e outros provedores de nuvem em grande escala, nem mesmo foram nomeados. A pergunta sobre o assunto foi educadamente recusada.
Isso é interessante porque, na RedMonk, naquele momento, ao avaliar equipes comerciais de open source, pedimos que eles respondessem a uma simples pergunta padrão: “Quem é seu concorrente?” Se eles mencionassem uma alternativa propietária, isso sugeria que a empresa estava voltada para o passado. Se a resposta fosse a nuvem, podia-se supor com segurança que a startup estava olhando para o futuro.
Como vemos, esse pensamento chegou ao mercado. Nos últimos 12 a 18 meses, de fato, ocorreu uma revolução. Se antes as empresas não consideravam provedores de nuvem, como Amazon, Google e Microsoft, dignos de menção, agora os veem como uma ameaça mortal. O medo dos provedores de nuvem se tornou tão esmagador que fornecedores comerciais de open source frequentemente, em contrariedade aos conselhos dos consultores, tomam decisões estratégicas que quebram as normas culturais do open source, gerando uma repercussão negativa massiva e duradoura e colocando em risco as relações com desenvolvedores, parceiros e clientes. Em particular, eles estão cada vez mais adotando modelos que borram as fronteiras entre software open source e proprietário na tentativa de obter vantagens de ambos os mundos, mas ao final é alta a probabilidade de que eles acabem recebendo as desvantagens de ambos.
Os fornecedores comerciais de código aberto tomaram essas medidas, sendo avisados antecipadamente sobre os riscos. Isso reflete sua avaliação de suas perspectivas em um mundo cada vez mais dominado por grandes nuvens que expandem o leque de serviços. Sem dúvida, tais decisões estratégicas têm consequências negativas sérias e inevitáveis, mas os fornecedores comerciais de código aberto — ou, pelo menos, seus investidores — consideram a falta de ação uma opção ainda mais destrutiva.
É interessante ver se essa crença se manterá após o anúncio da Amazon Web Services esta semana. Aqui está um breve resumo da história que levou aos eventos atuais:
- 2010: escrita por Shay Banon há quase dez anos, o Elasticsearch é um sistema de busca de código aberto com uma licença permissiva. Ele se tornou popular o suficiente para que eventualmente uma organização comercial se formasse ao seu redor. A Elastic NV — originalmente Elasticsearch BV — passou por várias rodadas de financiamento que totalizaram mais de cem milhões de dólares, realizou uma oferta pública inicial (IPO) em outubro do ano passado e atualmente é avaliada em pouco menos de $6 bilhões.
- 2015: cinco anos após a fundação do projeto — supostamente a pedido de clientes — a Amazon lançou um serviço em nuvem chamado Amazon Elasticsearch Service baseado nessa licença permissiva. Ele competiu diretamente com as ofertas comerciais da Elastic NV, tanto locais quanto em nuvem.
- 2018: em parte devido à concorrência com essa e outras nuvens, a Elastic NV começou a borrar as fronteiras entre sua oferta de código aberto e os complementos de licenciamento proprietário, especificamente o x-pack. É notável que a Elastic não seguiu o caminho de alguns colegas, mas tentou resolver o problema com licenças híbridas, começando a misturar em um único repositório código aberto e proprietário, enquanto as compilações por padrão incluíam esse software não livre.
- 2019: nesta semana, a Amazon tomou várias medidas em resposta. Primeiro, com o apoio da Expedia e da Netflix, apresentou o que considera ser uma “distribuição” do Elasticsearch. Porém, acredita-se que funcionará em todos os aspectos como um fork. Em segundo lugar, o projeto inclui complementos de código aberto, semelhantes às funcionalidades pelas quais a Elastic NV cobra, sem disponibilizá-los publicamente. Em terceiro lugar, assim como no serviço original da AWS baseado em Elasticsearch, a empresa utilizou para o projeto o nome Elasticsearch.
Considerando que as controvérsias anteriores evoluíram para um conflito aberto, surgem muitas perguntas. Como isso aconteceu? Foi inevitável? E a pergunta óbvia: quem é o culpado?
Pelo menos, para uma dessas perguntas, é fácil responder. Essa medida era esperada há algum tempo. Pelo menos desde setembro, quando surgiu a licença :
Certamente, parece incrível que os provedores de nuvem comecem a implementar e licenciar softwares de código aberto sob a licença Commons Clause de fornecedores comerciais. Na verdade, a Commons Clause pode ter efeitos inversos. Ela aumenta a probabilidade de que os provedores de nuvem tentem recrutar desenvolvedores-chave e criar um fork público ou privado do projeto. Esta é uma opção mais barata, que também garante o controle necessário sobre os ativos de software.
A controvérsia entre a Amazon e a Elastic é resultado do choque de modelos. Para a honra de Bannon e da Elastic, o software Elasticsearch se tornou extremamente popular, em grande parte devido à sua licença permissiva.
No entanto, as licenças permissivas permitem o uso do sistema também por provedores de nuvem, como a Amazon. Para não perder lucro e atender às demandas de seus clientes, os provedores de nuvem certamente oferecerão serviços nativos para o Elasticsearch e projetos semelhantes que são populares e bem conhecidos.
- O licenciamento é irrealista. Apesar da opinião de alguns investidores, na verdade, adicionar condições comerciais a um software livre anterior nunca fará com que os maiores fornecedores de serviços em nuvem assinem. Nenhuma empresa que opera em tal escala quer entregar um grande serviço — seja no desenvolvimento de produtos ou na definição de preços — a uma terceira parte que não controlam.
- A aquisição é mais uma opção para atender à demanda, mas tem uma escalabilidade ruim. Mesmo os ricos provedores de nuvem não querem gastar dinheiro a mais para comprar cada novo serviço em seu portfólio, especialmente quando há uma alternativa mais barata e simples — e esta realmente existe.
- Nas comunidades de código aberto, o fork historicamente foi visto como uma opção tóxica, mas do ponto de vista de relações públicas, ele se torna mais aceitável se um fornecedor comercial de código aberto ameaçar seu próprio status ao adotar táticas e métodos que contradizem as normas da comunidade de código aberto. Nesse caso, até grandes terceiros podem tentar assumir uma posição moral mais elevada, servindo, ao mesmo tempo, seus próprios interesses.
Diante dessas opções, o fork parece uma resposta lógica de um serviço em nuvem ao surgimento de condições de licenciamento desfavoráveis. É por isso que a decisão da Amazon foi esperada e inevitável. E, portanto, é difícil determinar um culpado pela situação. Em princípio, ambas as partes agiram de maneira lógica — como poderia ser esperado, considerando suas perspectivas, capacidades e direitos legais.
É bem provável que a Amazon seja a primeira, mas não a última provedora de nuvem a agir assim. Outros também tentarão alinhar a demanda do consumidor com a falta de restrições legais para criar seus próprios projetos, como "distribuição aberta para Elasticsearch". Probavelmente, eles inevitavelmente chegarão à conclusão de que isso é lucrativo. Evidentemente, do lado dos fornecedores comerciais de código aberto, também será inevitável que a conclusão seja que a nuvem apresenta uma ameaça tão grande que é necessário expandir os limites do código aberto.
Na verdade, a única questão real é se os desenvolvedores de código aberto conseguirão sair da situação atual com a Elastic, que agora compete com a Amazon não apenas em produtos, mas também em código aberto. Eles perceberão que os benefícios de algumas abordagens controversas de licenciamento simplesmente não justificam os custos.
No entanto, é mais provável que o status quo seja mantido. Os incentivos e motivos de ambas as partes são claros, compreensíveis e lógicos dentro dos seus respectivos modelos. Modelos que sempre estarão internamente contraditórios, mesmo que indissociavelmente interligados.
Cem anos atrás, líderes de dezenas de países decidiram entrar em conflito. Eles sabiam que o conflito seria caro, devastador e que raramente alguém sairia vitorioso. Eles fizeram isso porque não viam outra saída.
A indústria tecnológica também parece não ver.
Nota: A Amazon e a Elastic são clientes da RedMonk, assim como o Google e a Microsoft. A Expedia e a Netflix não são clientes da RedMonk.
Fonte: habr.com
