Elastic kehrt zu Open-Source-Wurzeln zurück

Elastic ist zurück in Open-Source-Gefilden.
rafapress | shutterstock.com



Der Gründer und CTO von Elastic, Shay Banon verkündete vergangene Woche in einem längeren Blogbeitrag die Rückkehr des Unternehmens in die Open-Source-Welt: „Wir haben nie aufgehört an Open Source zu glauben. Deshalb werden wir in den kommenden Wochen AGPL als weitere Lizenzoption neben ELv2 und SSPL anbieten.“



Dabei ist sich Banon auch bewusst, was Elastic ermöglicht hat, zu seinen Open-Source-Wurzeln zurückzukehren: Amazon Web Services (AWS) konnte Elasticsearch nach der Lizenzänderung im Jahr 2021 nicht mehr länger für sich vereinnahmen und als eigenes Serviceangebot anpreisen. Deshalb entschied sich der Konzern dazu, mit OpenSearch sein eigenes Konkurrenzprodukt auf Elasticsearch-Grundlage zu entwickeln – das sich wachsender Beliebtheit erfreut.



Nun da Amazon vollständig in seinen eigenen Fork investiert habe und die Verwirrung am Markt um das Elasticsearch-Brand beseitigt wurde, müsse man sich nicht länger darüber Sorgen machen, dass AWS Elasticsearch als sein eigenes Produkt verkaufe, erklärt Banon im Gespräch und fügt hinzu: „Das hat zu einer Partnerschaft mit AWS geführt, die stärker ist als je zuvor.“



Das deckt sich mit den Erfahrungen, die ich als ehemaliger Mitarbeiter von MongoDB gemacht habe: AWS kann ein exzellenter Partner sein. Allerdings muss man dazu manchmal etwas nachhelfen. Nach Elastics Open-Source-Comeback stellt sich zudem die Frage, ob andere ehemalige Open-Source-Unternehmen diesem Beispiel folgen könnten. Auch das liegt – wie Banon andeutet – im Wesentlichen an AWS.



Partnerschaft trifft Trademark



Wer nicht genau hinsieht, könnte sich von Klischees vereinnahmen lassen und denken, dass Unternehmen wie Elastic „die Bösen“ sind, die Open Source als „Marketingtrick“ nutzen und dann ihre Lizenzpraktiken umstellen, sobald Geld fließt. Argumentationen dieser Art verfangen eventuell auf Online- und Social-Media-Plattformen – zeichnen in aller Regel jedoch ein völlig falsches Bild von der Realität.



Das verdeutlicht die Entwicklung von Elastic sehr anschaulich: Das Projekt wurde von Banon im Jahr 2010 ins Leben gerufen – nach eigenen Angaben nahm der Gründer damals Kredite auf, um seine Arbeit und die Marke Elasticsearch schützen zu können. Es handelte sich hier also nicht um das Werk eines raffgierigen Unternehmens, sondern die Arbeit eines einzelnen Entwicklers, der versuchte, nach den gängigen Open-Source-Regeln zu spielen. Ganz nach dem Vorbild von Red Hat, JBoss und anderen Pionieren in diesem Bereich, die ihre Investitionen per Trademark schützen wollten.



Im Jahr 2015 verkündete Amazon-CTO Werner Vogels schließlich die Einführung des AWS-gebrandeten Elasticsearch Service – und eine „großartige Partnerschaft“ zwischen Elastic und AWS. Nur dass die gar nicht existierte. AWS verkaufte Elasticsearch schlicht und ergreifend als eigenes Produkt – ohne Geld, Code, Know-how oder sonst irgendetwas beizusteuern.



Wie Banon anmerkt, ging es Elastic dabei nicht um das Konkurrenzprodukt an sich, sondern um die Art und Weise, wie der Konzern dabei vorgegangen ist: „Das Problem war nie, dass AWS Elasticsearch nahm und als Service zur Verfügung stellte. Vielmehr, dass das Produkt ‚AWS Elasticsearch‘ genannt wurde, was nahelegte, dass es ihr eigener Service ist. Es handelte sich um eine klare Markenrechtsverletzung. Doch egal, wie sehr wir uns bemühten dagegen anzugehen – wir wurden mit Heerscharen von Anwälten konfrontiert.“



Die Fork-Lektionen für AWS



Was uns zu OpenSearch bringt. Nicht wenige sind davon ausgegangen, dass der Fork das Ende von Elastic einläuten würde. Weit gefehlt. Zwar ist OpenSearch von Vorteil für AWS, deswegen aber kein Nachteil für Elastic – eher im Gegenteil: Indem AWS gezwungen wurde, OpenSearch zu entwickeln, konnte Elastic sich selbst Raum verschaffen und wieder auf den Open-Source-Weg zurückfinden.



Wie Banon verdeutlicht, war das lange sein Ziel: „Ich wollte persönlich immer zu Open Source zurückkehren, selbst als wir die Lizenz geändert hatten. Wir haben auf den Fork durch AWS gehofft – und dass uns das ein Open-Source-Comeback ermöglicht, wenn genug Zeit vergangen ist.“



Dieses kalkulierte Risiko scheine sich nun auszuzahlen, so der Elastic-Gründer weiter: „Wir haben das Gefühl, diesen Move nun sicher vollziehen zu können, nachdem der Fork durch ist und AWS massiv investiert hat.“



In der Tat war und ist OpenSearch für AWS ein erheblicher Kostenfaktor. Aber auch eine gute Möglichkeit, dazu zu lernen. Der Fork hat dem Konzern veranschaulicht, wie schwierig es ist, eine Community um ein quelloffenes Projekt herum aufzubauen. Und wie viel Geld nötig ist, um ein eigenes Produkt zu entwickeln – statt einfach das anderer zu operationalisieren.  



Vor kurzem hat Amazon Web Services in Zusammenarbeit mit anderen Unternehmen auch einen Redis-Fork vorangetrieben, um das Valkey-Projekt auf die Beine zu stellen. Bisher findet man AWS eher nicht unter den Top-Kontributoren für Open-Source-Projekte. Valkey könnte hier ein positives Zeichen setzen.  



Das könnte auch Redis zugutekommen: Eventuell investiert AWS ähnlich stark in das Projekt wie es beim Elasticsearch-Fork der Fall war. Das könnte dazu führen, dass für einen Redis-Service (ElastiCache) von AWS kein Platz mehr ist.



Die Erkenntnis: Wenn AWS Open-Source-Code als seinen eigenen ausliefert, ohne der Community etwas zurückzugeben, wird es für andere schwierig, das Open-Source-Konzept weiter zu verfolgen. Wenn AWS jedoch Partnerschaften eingeht und/oder über einen Projekt-Fork sein eigenen Angebote bereitstellt, folgt es damit nicht nur seinem Leitprinzip der „Customer Obsession“, sondern macht es Open Source auch leichter, „offen zu bleiben“. (fm)



Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox