Ein Index-Rollover läuft durch, die Shards verteilen sich neu, und für ein paar Sekunden steigt die Latenz im Dashboard. Solche Ausschläge sind selten ein Defekt. Meistens ist es nur die Art, wie eine verteilte Suchmaschine Arbeit umverteilt. Wer einen solchen Cluster betreut, merkt mit der Zeit: Diese Details entscheiden mehr als jede Ankündigung. Fünf Jahre nach dem Fork von Elasticsearch lässt sich OpenSearch daran messen, nicht am Lizenzstreit von 2021, sondern daran, wie unauffällig der Betrieb inzwischen läuft.
Die kurze Version der Geschichte: Elastic stellte Elasticsearch und Kibana im Januar 2021 auf SSPL und Elastic License um, Amazon Web Services forkte den letzten Apache-2.0-Stand und veröffentlichte im Juli 2021 OpenSearch 1.0 samt OpenSearch Dashboards. Seither hat sich das Projekt bewegt, technisch schneller als viele erwartet hatten, organisatorisch langsamer, als manche gehofft hatten. Die interessanteste Etappe handelt nicht vom Code, sondern davon, wer das Projekt steuert.
Ein Bild hilft: Der Fork war ein Auszug aus einer Mietwohnung, in der der Vermieter kurzfristig die Hausordnung geändert hatte. Bleiben war erlaubt, aber nicht zu den alten Bedingungen. Also zog die Community in ein eigenes Haus, das zunächst ziemlich leer war. Heute tagt dort eine Eigentümergemeinschaft, die über Renovierungen streitet. Daran erkennt man recht gut, wie reif ein Open-Source-Projekt ist.
Der Lizenzwechsel von 2021 und warum daraus ein Fork wurde
Elastic begründete den Schritt mit dem Schutz vor Cloud-Anbietern, die den Code kommerziell verwerten, ohne nennenswert zur Entwicklung beizutragen. Das Argument ist nicht falsch, und man muss es nicht kleinreden, nur weil die Reaktion hart ausfiel. Die Open-Source-Welt sah es anders: Apache 2.0 ist eine Einbahnstraße, ein Wechsel zurück praktisch unmöglich, und bestehende Nutzer standen plötzlich vor Bedingungen, die sie nie akzeptiert hatten. Für viele Betreiber war das weniger eine Rechtsfrage als eine Frage der Planungssicherheit.
AWS reagierte schnell und mit einem technisch naheliegenden, strategisch heiklen Manöver: Man nahm den letzten Stand unter Apache 2.0, also 7.10.2, und baute ihn eigenständig weiter. OpenSearch 1.0 war damit kein Neuanfang aus dem Nichts, sondern eine Fortsetzung auf Zeit. Kibana wurde als OpenSearch Dashboards mitgeforft, was den Aufwand erhöhte und sich rückblickend ausgezahlt hat, weil sonst ein halbes Ökosystem gefehlt hätte. Das Bild vom Auszug stimmt also ziemlich genau: Möbel mitnehmen ja, Fundament neu gießen nein.
Von der AWS-Abteilung zur eigenen Stiftung
Der Vorwurf der ersten Jahre lautete, OpenSearch sei im Kern ein AWS-Produkt mit offenem Quellcode. Ganz falsch war das nicht: Ein großer Teil der Vollzeit-Maintainer kam und kommt von Amazon, die Roadmap folgte häufig den Bedürfnissen des Managed Service. Ein Projekt, das von einem einzigen Geldgeber bezahlt wird, bleibt angreifbar, selbst wenn die Lizenz einwandfrei ist. Open Source ist kein Zustand, den man einmal erreicht, sondern eine Verteilung von Macht, die man pflegen muss.
Im September 2024 wurde die Marke OpenSearch an die OpenSearch Software Foundation unter dem Dach der Linux Foundation übertragen. Das ist kein Papiertrick, sondern verändert die Spielregeln: Markenrechte, Contributors, ein Technical Steering Committee und ein öffentlicher RFC-Prozess liegen nicht mehr bei einem Konzern allein. Natürlich sitzt AWS weiterhin mit am Tisch und stellt Personal, und wer das ignoriert, beschreibt das Projekt schöner, als es ist. Aber die Struktur erlaubt es anderen Firmen, Verantwortung zu übernehmen, ohne als Gast im Wohnzimmer zu gelten.
In der Haus-Gemeinschaft-Analogie ist das der Moment, in dem aus einem Eigentümer mehrere werden und ein Beschlussprotokoll entsteht. Harmonischer wird es dadurch nicht, eher unbequemer, weil jetzt verhandelt werden muss. Das kostet Zeit. Es ist der Sinn der Sache.
Technisch erwachsen: Was OpenSearch heute kann und wo es sich abnabelt
Die technische Basis bleibt der letzte kompatible Stand von 7.10.2, aber das heißt nicht, dass innen alles beim Alten ist. OpenSearch hat ein eigenes Index-Format entwickelt, Segment Replication eingeführt, Searchable Snapshots und Remote-Backed Snapshots nachgezogen und die Analytik um SQL und PPL erweitert. Dazu kommen Alerting, Anomalie-Erkennung und Observability-Funktionen, die früher den kommerziellen Elastic-Varianten vorbehalten waren. Wer heute migriert, findet deutlich mehr vor als 2021.
Der auffälligste Unterschied liegt im Sicherheitsmodell. Feld- und Dokumenten-Level-Security, rollenbasierte Zugriffskontrolle, Audit-Logging und TLS-Verwaltung stecken bei OpenSearch im Apache-2.0-Kern. Bei Elasticsearch sind Teile davon kostenpflichtigen Abos zugeordnet. Für regulierte Umgebungen zählt das, unabhängig vom Vector-Hype der letzten zwei Jahre. Vektorsuche wiederum beherrscht OpenSearch mit eigenen k-NN-Implementierungen, Hybrid Search und Neural-Search-Plugins so weit, dass es für die meisten Retrieval-Anwendungen reicht.
Die Abnabelung hat ihren Preis: Ein Upgrade von Elasticsearch 8.x auf OpenSearch ist kein Knopfdruck, und der Kompatibilitätspfad endet an der 7.10-Schnittstelle. Plugins, Analyzer und Query-Verhalten driften langsam auseinander, das ist bei zwei getrennten Entwicklungslinien unvermeidlich. Wer OpenSearch heute einsetzt, sollte es als bewusste Entscheidung tun, nicht als Notlösung.
Der Faktor AWS: Betrieb, Abhängigkeit und Wahrnehmung
Für die Verbreitung hat der Managed Service dem Projekt Reichweite gebracht, dem Image lange geschadet. Viele Teams kennen OpenSearch ausschließlich als Knopf im AWS-Konsum, mit Serverless-Variante, automatischen Snapshots und Preisgestaltung nach Instanzstunden. Das senkt die Einstiegshürde enorm, erzeugt aber eine stille Abhängigkeit: Wer nie gelernt hat, ein Cluster selbst zu dimensionieren, merkt erst bei der Rechnung, wie viel Betriebsarbeit ausgelagert wurde. Und die Rechnung kann wehtun, gerade bei Log-Mengen, die unkontrolliert wachsen.
Dass OpenSearch als Open Source eine echte Alternative zu Elasticsearch ist, zeigt sich deshalb weniger in der Cloud als auf eigener Hardware und bei spezialisierten Anbietern. Firmen wie Aiven, NetApp Instaclustr oder kleinere Beratungen bieten Betrieb und Support an, oft mit mehreren Providern parallel. Die Debatte um Telemetrie aus dem Jahr 2021, als ein standardmäßig aktives Reporting für Unmut sorgte und anschließend entschärft wurde, zeigt, wie empfindlich die Community auf solche Details reagiert. Der Schatten von AWS ist also kleiner geworden, verschwunden ist er nicht.
Wo OpenSearch als Suchmaschine im Markt steht
Die Konkurrenz ist heute breiter als 2021, und das ist für dich als Betreiber eine gute Nachricht. Elasticsearch hat seine Lizenzlage entschärft und ist wieder über eine AGPL-Variante verfügbar, Solr bleibt für reine Volltext-Indizes eine gute Wahl, Vespa und Quickwit bedienen Spezialfälle, und für kleine Projekte reichen Typesense oder Meilisearch. Dazu kommen Vektor-Datenbanken wie Qdrant oder Weaviate und pgvector für alle, die ohnehin Postgres betreiben. Die Frage lautet nicht mehr, welche Suchmaschine objektiv die beste ist, sondern welche zu deinem Betriebsmodell passt.
OpenSearch besetzt dabei eine pragmatische Nische: Volltextsuche, Log- und Metrik-Analyse und Vektorsuche in einem System, das sich als Cluster betreiben lässt und keine Lizenzkosten kennt. Das ist unspektakulär und genau deshalb brauchbar. Wer Logs und Suche aus einer Hand will und bereits weiß, wie man verteilte Systeme wartet, findet hier ein stimmiges Paket. Wer maximale Bequemlichkeit sucht, landet ohnehin bei einem Managed Service, und dann entscheidet der Preis, nicht die Lizenz.
Was das für Betreiber konkret bedeutet
Reif ist ein Projekt, wenn man es langweilig betreiben kann. OpenSearch ist auf dem Weg dorthin: eigene Releases mit festen Zyklen, eine Stiftung als Dach, dokumentierte Breaking Changes und ein Ökosystem, das nicht mehr nur aus einem Anbieter besteht. Gleichzeitig bleibt die Abhängigkeit von AWS-Engineering real, und wer das verdrängt, plant schlechter. Beides muss man zusammen betrachten.
Praktisch heißt das: Prüfe vor einer Migration, welche Elasticsearch-Funktionen du wirklich nutzt, statt der Marketingliste zu glauben. Teste Query-Verhalten und Analyzer mit echten Daten, nicht mit Demos. Kalkuliere Betriebszeit ein, wenn du selbst hostest, und vergleiche sie ehrlich mit den Cloud-Kosten über drei Jahre. Und behandle Vektorsuche als Feature, nicht als Strategie.
Fünf Jahre nach dem Fork ist die interessanteste Nachricht nicht, dass OpenSearch Elasticsearch technisch eingeholt hat. Es ist die, dass aus einer Lizenzrevolte ein Projekt mit eigener Trägerschaft, eigener Technik und eigenen Streitfragen geworden ist. Aus dem Auszug ist ein Haus geworden, in dem inzwischen gestritten wird, über Renovierungen, Zuständigkeiten und Geld. Das ist unspektakulär, aber es trägt.
Quelle: thenewstack.io
