„Dziś Europa przypomina prochownię, a jej liderzy to jakby ludzie palący w środku. Jedna iskra wywoła eksplozję, która pochłonie nas wszystkich. Nie wiem, kiedy to się stanie, ale wiem, gdzie. Wszystko zrujnuje jakieś głupie wydarzenie na Bałkanach” — Otto von Bismarck, 1878
Sto lat temu, 11 listopada 1918 roku, podpisano rozejm, który zakończył I wojnę światową. Liczba utraconych żyć w tej wojnie jest teraz trudna do wyobrażenia. Na przykład, w Ameryce wojna w Wietnamie słusznie uznawana jest za katastrofę wojenną. Przez dwadzieścia lat działań wojennych USA straciły 58 318 żołnierzy. Dla porównania, tylko w pierwszej bitwie na Marne w 1914 roku alianci stracili czterokrotnie więcej. W ciągu pięciu dni.
Niektórzy powiedzą, że okropności wojny były niemożliwe do przewidzenia. Problem polega na tym, że przynajmniej niektóre ze zaangażowanych stron doskonale zdawały sobie sprawę z konsekwencji. Brytyjski minister spraw zagranicznych Edward Grey, po wystąpieniu w parlamencie na rzecz wojny, rzekomo powiedział: „Lampy gasną w całej Europie. Na nasze życie więcej się nie zapalą.”
Dlatego w kolejnych latach historycy próbowali odpowiedzieć na pytanie: jeśli konsekwencje były zrozumiałe, to jak dopuściły się — serii powiązanych wydarzeń, w wyniku których wojna stała się jedynym możliwym rezultatem.
Chociaż odpowiedź jest niezwykle skomplikowana, jest prosta. Biorąc pod uwagę atmosferę i struktury polityczne tamtych czasów, żaden z uczestników wydarzeń nie czuł, że ma alternatywę. Jedną z najbardziej przerażających rzeczy w badaniu przyczyn wojny jest to, że jeśli przyjrzeć się ówczesnym realiom politycznym, w rzeczywistości łatwo zrozumieć uzasadnienia działań każdego państwa.
W efekcie zgodzimy się, że wojna w rzeczywistości była nieuchronna. Łatwość, z jaką przyjmujemy tę prawdę, rzeczywiście przeraża.
Trzy lata temu jedna firma venture capital zorganizowała niewielką grupę przedstawicieli mediów, dostawców i analityków, w tym nas, aby omówić znaczenie open source w działalności komercyjnej. Po prezentacji własnego modelu partner firmy venture przedstawił grupę liderów z partnerskich komercyjnych firm open source. Każdy z nich szczegółowo opisał, jak open source zastąpił klientom alternatywy własnościowe.
Oczywiście, zgadzamy się, że przejście deweloperów na open source w skali przedsiębiorstwa zmienia charakter dostarczania. W pewnym sensie to główna teza, którą propagujemy od wielu lat. Już w 2011 roku opublikowaliśmy artykuł . Jednak w proponowanym modelu interesujące nie było to, co mówi o teraźniejszości, ale raczej to, czego nie może powiedzieć o przyszłości.
Na wydarzeniu nie wspomniano bezpośrednio o usługach chmurowych. Powiedziano, że inwestorzy i komercyjni deweloperzy OSS konkurują z oprogramowaniem własnościowym. Nie poświęcono szczególnej uwagi Amazonowi i innym dostawcom chmur o ponadprzeciętnej skali, nawet ich nie wymieniono. Pytanie w tej sprawie zostało uprzejmie odrzucone.
To interesujące, ponieważ w RedMonk w tym czasie, oceniając komercyjne zespoły open source, pytaliśmy ich o standardowe proste pytanie: „Kto jest twoim konkurentem?” Jeśli wymieniali alternatywę własnościową, sugerowało to, że firma jest zwrócona ku przeszłości. Jeśli odpowiedzią była chmura, można było z pewnością założyć, że startup patrzy w przyszłość.
Jak widzimy, obecnie to myślenie dotarło na rynek. W ciągu ostatnich 12–18 miesięcy nastąpił w zasadzie przewrót. O ile wcześniej firmy nie traktowały cloud providerów, takich jak Amazon, Google czy Microsoft, jako godnych uwagi, teraz postrzegają ich jako śmiertelne zagrożenie. Strach przed dostawcami chmurowymi stał się na tyle przytłaczający, że komercyjni dostawcy open source często wbrew radom doradców podejmują strategiczne decyzje, które łamią kulturowe normy open source, wywołują masowy i trwały negatywny PR oraz zagrażają relacjom z deweloperami, partnerami i klientami. W szczególności coraz częściej zwracają się ku modelom, które rozmywają granice między open source a oprogramowaniem własnościowym, w próbie uzyskania korzyści z obu światów, ale ostatecznie istnieje duże prawdopodobieństwo, że uzyskają wady obu.
Dostawcy komercyjni open source podjęli te działania po wcześniejszym poinformowaniu o ryzyku. To świadczy o ich ocenie swoich perspektyw w świecie, w którym coraz bardziej dominują masowe chmury, poszerzające zakres usług. Bez wątpienia takie strategiczne decyzje mają poważne, nieuniknione negatywne konsekwencje, ale dostawcy komercyjni open source — lub przynajmniej ich inwestorzy — uważają brak działania za jeszcze bardziej destrukcyjną opcję.
Interesujące jest, czy takie przekonanie utrzyma się po ogłoszeniu Amazon Web Services w tym tygodniu. Oto krótkie podsumowanie historii, która doprowadziła do obecnych wydarzeń:
- 2010: napisana przez Sheema Bénona prawie dziesięć lat temu, Elasticsearch to wyszukiwarka z otwartym kodem źródłowym i licencją zezwalającą. Okazała się na tyle popularna, że w końcu wokół niej powstała organizacja komercyjna. Elastic NV — pierwotnie Elasticsearch BV — przeszła kilka rund finansowania na łączną kwotę ponad stu milionów dolarów, w październiku ubiegłego roku zrealizowała IPO, a obecnie jest wyceniana na nieco poniżej 6 miliardów dolarów.
- 2015: pięć lat po założeniu projektu — przypuszczalnie na prośbę klientów — Amazon uruchomił usługę chmurową pod nazwą Amazon Elasticsearch Service, bazującą na tej licencji zezwalającej. Konkurowała ona bezpośrednio z komercyjnymi ofertami Elastic NV, zarówno lokalnymi, jak i chmurowymi.
- 2018: częściowo z powodu konkurencji z tym i innymi chmurami, Elastic NV zaczęła zacierać granice między swoją ofertą open source a dodatkami licencyjnymi, w szczególności x-pack. Co ciekawe, Elastic nie poszła drogą niektórych kolegów, a próbowała rozwiązać problem za pomocą hybrydowych licencji, ale zaczęła łączyć w jednym repozytorium otwarty i własnościowy kod źródłowy, a domyślne kompilacje zawierały to oprogramowanie, które nie było wolne.
- 2019: W tym tygodniu Amazon podjął kilka działań odpowiedzialnych. Po pierwsze, przy wsparciu Expedią i Netflixem, zaprezentował to, co uważa za „dystrybucję” Elasticsearch. Jednak oczekuje się, że w każdej kwestii będzie to działać jako fork. Po drugie, projekt obejmuje open source dodatki, podobne do funkcji, za które Elastic NV pobiera opłaty, nie udostępniając ich publicznie. Po trzecie, podobnie jak w przypadku oryginalnej usługi AWS opartej na Elasticsearch, firma użyła do projektu nazwy Elasticsearch.
Biorąc pod uwagę, że wcześniejsze kontrowersje przerodziły się w otwarty konflikt, pojawia się wiele pytań. Jak do tego doszło? Czy to było nieuniknione? I oczywiste pytanie: kto jest winny?
Przynajmniej na jedno z tych pytań łatwo odpowiedzieć. Ten krok był oczekiwany od jakiegoś czasu. Przynajmniej od września, kiedy pojawiła się licencja :
Oczywiście, wydaje się niewiarygodne, że dostawcy usług w chmurze zaczęliby masowo wdrażać i licencjonować oprogramowanie open source od komercyjnych dostawców na licencji Commons Clause. W rzeczywistości Commons Clause może prowadzić do odwrotnych skutków. Zwiększa prawdopodobieństwo, że dostawcy usług w chmurze spróbują przejąć kluczowych deweloperów i stworzyć publiczny lub prywatny fork projektu. Jest to tańsza opcja, która ponadto zapewnia niezbędną kontrolę nad aktywami programowymi.
Kontrowersje między Amazon a Elastic są wynikiem zderzenia modeli. Ku chwale Bénona i Elastic, oprogramowanie Elasticsearch okazało się niezwykle popularne, także dzięki liberalnej licencji.
Jednak licencje liberalne pozwalają na korzystanie z systemu również dostawcom w chmurze, takim jak Amazon. Aby nie stracić zysku i zaspokoić potrzeby swoich klientów, dostawcy usług w chmurze na pewno będą oferować natywne usługi dla Elasticsearch i podobnych projektów, które są popularne i dobrze znane.
- Licencjonowanie jest nierealistyczne. Pomimo opinii niektórych inwestorów, wprowadzenie warunków komercyjnych do wcześniej wolnego oprogramowania nigdy nie skłoni największych dostawców usług w chmurze do podpisania umowy. Żadna firma działająca na takim poziomie nie chce oddać dużej usługi — czy to rozwój produktu, czy kształtowanie cen — stronie trzeciej, której nie kontroluje.
- Zakup to kolejna opcja zaspokojenia popytu, ale nie skalować się. Nawet bogate dostawcy chmur nie chcą płacić dodatkowych pieniędzy za zakup każdej nowej usługi w swoim portfolio, zwłaszcza gdy istnieje tańsza i prostsza alternatywa — a ta jest dostępna.
- W społeczności open source forka historycznie uważano za toksyczną opcję, ale z perspektywy PR staje się ona bardziej akceptowalna, jeśli komercyjny dostawca open source zagraża własnemu statusowi, przyjmując taktyki i metody, które są sprzeczne z normami społeczności open source. W takim przypadku nawet duże strony trzecie mogą próbować zająć wyższe moralne stanowisko, jednocześnie służąc własnym interesom.
Stawiając czoła tym opcjom, forka wydaje się logiczną odpowiedzią dostawcy usług w chmurze na pojawienie się niekorzystnych warunków licencyjnych. Dlatego decyzja Amazon była oczekiwana i nieunikniona. Dlatego trudno określić winnego w tej sytuacji. W zasadzie obie strony działały logicznie — tak, jak można było się spodziewać, biorąc pod uwagę ich perspektywy, możliwości i legalne prawa.
Jest bardzo prawdopodobne, że Amazon będzie pierwszym, ale nie ostatnim dostawcą chmury, który postąpił w ten sposób. Inni również będą próbować zharmonizować popyt konsumencki z brakiem ograniczeń prawnych na stworzenie swoich projektów, takich jak „otwarty dystrybucja dla Elasticsearch”. Prawdopodobnie nieuchronnie dojdą do wniosku, że jest to opłacalne. Wydaje się, że ze strony komercyjnych dostawców open source również nieuchronnie zapadnie wniosek, że chmura stanowi na tyle poważne zagrożenie, że należy rozszerzyć granice open source.
W rzeczywistości jedynym prawdziwym pytaniem jest to, czy programiści open source wydobędą się z obecnej sytuacji z Elastic, która teraz konkuruje z Amazonem nie tylko w zakresie produktów, ale także otwartych źródeł. Czy zrozumieją, że korzyści płynące z niektórych kontrowersyjnych podejść do licencjonowania po prostu nie uzasadniają kosztów?
Jednak bardziej prawdopodobne jest zachowanie status quo. Motywacje i zasady obu stron są jasne, zrozumiałe i logiczne w kontekście ich odpowiednich modeli. Modeli, które zawsze będą w wewnętrznej sprzeczności, nawet jeśli są nierozerwalnie związane.
Sto lat temu przywódcy dziesiątek krajów postanowili wejść w konflikt. Wiedzieli, że konflikt będzie ich drogo kosztować, będzie straszliwie destrukcyjny i mało kto wyjdzie z niego zwycięsko. Zrobili to, ponieważ nie widzieli innego wyjścia.
Branża technologiczna również wydaje się tego nie dostrzegać.
Uwaga: Amazon i Elastic są klientami RedMonk, tak samo jak Google i Microsoft. Expedia i Netflix nie są klientami RedMonk.
Źródło: habr.com
