Es gibt eine Zahl, die fast niemand kennt, obwohl sie jeden betrifft: Drei. Drei Browser-Engines rendern nahezu das gesamte World Wide Web. Blink, entwickelt von Google. Gecko, entwickelt von Mozilla. WebKit, entwickelt von Apple. Alles, was Sie im Browser sehen — jede Webseite, jede Anwendung, jeder Online-Shop, jede Banking-Sitzung, jede Videokonferenz — wird von einer dieser drei Engines auf den Bildschirm gebracht.

Drei Unternehmen. Ein Markt, der die digitale Welt kontrolliert.

Und jetzt kommt jemand daher und baut eine vierte. Von Grund auf. Ohne den Code einer der bestehenden Engines zu übernehmen. Ohne Fork. Ohne Nutzervermarktung. Finanziert durch Spenden, getragen von einer Non-Profit-Organisation. Der Name: Ladybird.

Das ist nicht einfach ein neues Produkt. Es ist ein Akt der Weigerung.

Warum der Browser das wichtigste Programm ist

Der Browser ist die am häufigsten genutzte Anwendung auf fast jedem Gerät. Er ist Tür, Fenster und Brücke zugleich. Durch ihn erreichen wir Behörden, Banken, Schulen, Ärzte, Freunde, Arbeitgeber. Er hat das Betriebssystem teilweise ersetzt — viele Menschen brauchen außer dem Browser kaum noch ein lokales Programm.

Wer den Browser kontrolliert, kontrolliert den Zugang zur digitalen Welt. Und wer die Browser-Engine kontrolliert, kontrolliert den Browser.

Eine Browser-Engine ist das Herzstück: Sie parst HTML, interpretiert CSS, führt JavaScript aus, layoutet die Seite, rendert Pixel auf den Bildschirm. Sie entscheidet, wie eine Webseite aussieht, wie schnell sie lädt, ob sie überhaupt funktioniert. Sie bestimmt, welche Web-Standards unterstützt werden und welche nicht. Sie ist die Instanz, die zwischen dem Code einer Webseite und dem, was der Nutzer sieht, übersetzt.

Drei Instanzen. Drei Übersetzer. Drei Interpretationen desselben Standards.

Ein dünner Markt, der dünner wurde

Es war nicht immer so. In den Neunzigern gab es Dutzende Browser-Engines. Netscape Navigator, Internet Explorer, Opera mit Presto, KDEs KHTML, Mozillas frühes Gecko, Amaya, Mosaic — jede mit eigenen Stärken, eigenen Schwächen, eigenen Meinungen darüber, wie das Web funktionieren sollte.

Dann kam die Konsolidierung. Internet Explorer eroberte den Markt und erstickte die Konkurrenz fast vollständig. Mozilla kämpfte sich mit Firefox zurück. Apple spaltete KHTML ab und erschuf WebKit. Google nahm WebKit, spaltete es erneut und erschuf Blink. Opera gab Presto auf und wechselte zu Blink. Microsoft gab EdgeHTML auf und wechselte ebenfalls zu Blink. KHTML, Trident, Presto, EdgeHTML — alle verschwunden.

Übrig blieben drei.

Goanna, ein Gecko-Fork, der in Pale Moon weiterlebt, ist ein Nischenprojekt. Servo, ein experimentelles Mozilla-Projekt, existiert, ist aber nicht produktivreif. NetSurf existiert, ist aber extrem limitiert. Flow existiert, ist aber kommerziell und geschlossen. Die Realität ist: Wer heute im Web unterwegs ist, nutzt Blink, Gecko oder WebKit. Punkt.

Was Monokultur bedeutet

Monokultur klingt nach einem agrarischen Begriff, aber in der IT ist er präzise. Wenn alle dieselbe Engine nutzen, sind alle anfällig für denselben Fehler. Ein Sicherheitsleck in Blink betrifft Chrome, Edge, Opera, Brave, Vivaldi, Arc — etwa siebzig Prozent des Marktes. Ein Rendering-Bug in WebKit betrifft jeden Safari-Nutzer, jeden iOS-Nutzer (denn auf iOS ist WebKit die einzig erlaubte Engine), jeden, der GNOME Web nutzt.

Aber das Sicherheitsargument ist nur das Offensichtliche. Das tiefere Problem ist die Machtfrage.

Wer die dominierende Engine kontrolliert, kontrolliert de facto die Web-Standards. Google hat mit Blink die Macht, das Web in eine Richtung zu treiben, die den eigenen Geschäftsinteressen dient — mehr Surfzeit, mehr Werbeeinnahmen, mehr Datensammlung, mehr Abhängigkeit von Google-Diensten. Standards, die Google unbequem finden, werden verschleppt. Features, die Google nützen, werden implementiert, bevor sie standardisiert sind. Das ist keine Verschwörungstheorie. Es ist die normale Dynamik eines Quasi-Monopols.

Mozilla hat mit Gecko eine Stimme, aber eine leise. Apple hat mit WebKit eine Stimme, aber eine, die primär an die eigene Plattform gebunden ist. Wer WebKit nutzt, nutzt es, weil Apple es vorschreibt — nicht weil er es wählt.

Eine vierte Engine bedeutet eine vierte Stimme. Eine vierte Meinung darüber, wie das Web funktionieren sollte. Eine vierte Implementierung desselben Standards, die Fehler findet, die die anderen übersehen. Eine vierte Instanz, die den Quasi-Monopolisten nicht gefällig sein muss.

Ladybird: nicht ein Fork, sondern ein Neuanfang

Hier wird Ladybird interessant. Und hier muss man präzise sein.

Viele Projekte, die sich als »Alternative« bezeichnen, sind keine. Brave nutzt Blink. Vivaldi nutzt Blink. Arc nutzt Blink. Sie mögen andere Oberflächen, andere Philosophien, andere Datenschutzversprechen haben — aber unter der Haube läuft derselbe Motor wie in Chrome. Wenn Blink einen Fehler hat, haben sie ihn alle. Wenn Google eine API ändert, müssen sie alle folgen.

Ladybird ist anders. Es ist keine neue Haut über einem fremden Motor. Es ist ein eigener Motor, von Grund auf neu gebaut. Die Rendering-Engine heißt LibWeb. Die JavaScript-Engine heißt LibJS. Beide wurden von null geschrieben — kein Code aus Blink, Gecko oder WebKit. Das ist eine Aussage, die in ihrer Radikalität in dieser Branche selten geworden ist.

Andreas Kling, der Gründer, begann das Projekt 2019 als Teil von SerenityOS, einem Hobby-Betriebssystem mit einer Kultur des radikalen Selberschreibens. 2022 wurde Ladybird eigenständig. 2024 gründete Kling die Ladybird Browser Initiative, eine 501(c)(3)-Non-Profit-Organisation. Die Finanzierung kommt ausschließlich von Spenden und Sponsoring — Cloudflare, Shopify, FUTO, 37signals, Proton VPN, die Human Rights Foundation gehören zu den Unterstützern.

Keine Suchmaschinendeals. Keine Krypto-Token. Keine Datensammlung. Keine Werbung. Keine Möglichkeit für einen Investor, die technische Roadmap zu beeinflussen. Das steht auf der Website, und es ist in der Organisationsstruktur verankert: Sponsorenschaften sind reine Spenden. Boardsitze sind nicht käuflich. Der technische Kurs wird von den Entwicklern bestimmt, nicht von den Geldgebern.

Wo Ladybird steht

Ladybird ist nicht fertig. Das sollte man ehrlich sagen. Die Alpha-Version ist für 2026 angekündigt, zunächst für Linux und macOS. Eine Beta wird für 2027 erwartet, eine stabile Version für 2028. Wer es heute baut, kann Websites laden — aber es ist kein Browser für den Alltag. Es ist ein Browser für Entwickler, Tester und Neugierige.

Was jedoch beeindruckt: Ladybird belegt in den Web Platform Tests bereits den vierten Platz — hinter Chrome, Safari und Firefox. Die JavaScript-Engine, LibJS, ist nach SpiderMonkey (Firefox) die zweitkonformanteste. Für ein Projekt, das von Grund auf neu begonnen hat, in einer Größenordnung, die von einem kleinen Vollzeit-Team getragen wird, ist das bemerkenswert.

Die Codebasis entstand ursprünglich in C++, wird aber schrittweise auf Rust portiert —Subsystem für Subsystem. Das ist keine kosmetische Entscheidung. Rust eliminiert ganze Klassen von Speicher-Sicherheitsfehlern, die in C++ chronisch sind. Eine Browser-Engine in Rust ist eine Engine, die strukturell sicherer ist als das, was die Konkurrenz betreibt. Dass Ladybird diesen Weg geht, sagt etwas über den Anspruch.

Warum Vielfalt eine Frage der Souveränität ist

Bisher ging es um Technik. Jetzt geht es um Politik — nicht im parteipolitischen Sinne, sondern im Sinne von Macht und Abhängigkeit.

Das Web ist die universelle Plattform. Wer sie kontrolliert, kontrolliert den Zugang zur digitalen Gesellschaft. Wenn drei Unternehmen entscheiden, welche Web-Standards existieren, welche Features implementiert werden, wie Datenschutz gehandhabt wird, welche APIs zugelassen sind und welche nicht — dann ist das Web nicht frei. Es ist verwaltet.

Souveränität im digitalen Raum bedeutet, nicht von der Gnade einzelner Konzerne abhängig zu sein. Es bedeutet, dass die Werkzeuge, die wir nutzen, nachvollziehbar, prüfbar und kontrollierbar sind. Es bedeutet, dass Standards offen sind und dass mehrere unabhängige Implementierungen existieren, die gegenseitig kontrollierbar sind.

Eine vierte Engine ist ein Beitrag zu dieser Souveränität. Sie bricht das Quasi-Monopol auf. Sie zwingt die anderen, sich zu rechtfertigen, wenn sie vom Standard abweichen. Sie bietet eine Referenzimplementierung, an der man messen kann, ob die anderen korrekt arbeiten. Sie ist ein Laboratorium für neue Ideen, die nicht den Geschäftsmodellen der Großen entsprechen müssen.

Und sie ist offen. Ladybird steht unter einer BSD-Lizenz. Der Code liegt auf GitHub. Jeder kann ihn lesen, prüfen, verstehen. Jeder kann nachvollziehen, was die Engine tut — im Gegensatz zu geschlossenen Engines, bei denen man hoffen muss, dass sie das tun, was sie behaupten.

Warum man sich Ladybird ansehen sollte

Wer an offener Software interessiert ist, an Souveränität, an dem Gedanken, dass das Web niemandem gehören sollte, sollte Ladybird auf der Watchlist haben. Nicht, weil es heute ein fertiger Browser ist — es ist keiner. Sondern weil es ein Projekt ist, das eine Frage stellt, die zu selten gestellt wird: Brauchen wir wirklich nur drei Motoren, um die ganze Welt zu rendern?

Man kann das Projekt unterstützen. Durch Spenden über Donorbox, durch Sponsoring, durch Testen, durch Bugreports, durch technische Mitarbeit. Die Website ladybird.dev erklärt, wie. Jeder Beitrag hilft — das Projekt wird vollständig aus Spenden finanziert, und jeder Dollar geht in die Engine, nicht in Marketingabteilungen oder Shareholder Value.

Man kann es auch einfach beobachten. Den monatlichen Newsletter lesen. Schauen, was passiert. Denn selbst wer Ladybird nie nutzen wird, profitiert von seiner Existenz. Ein Projekt, das beweist, dass eine neue Engine möglich ist, erhöht den Druck auf die Etablierten. Es zeigt, dass das Web nicht auf drei Akteure reduziert sein muss. Und es hält die Diskussion darüber lebendig, wem das Web gehört.

Was das für libcom.de bedeutet

Browser-Engines sind Infrastruktur. Und Infrastruktur ist das, was libcom.de tut — planen, bauen, betreiben, verstehen. Nicht jeder Betrieb braucht eine eigene Browser-Engine. Aber jeder Betrieb sollte verstehen, welche Engine seine Nutzer einsetzen, welche Abhängigkeiten das erzeugt, und welche Risiken daraus erwachsen.

Wer eine IT betreibt, in der Browser zentral sind — und welcher Betrieb ist das heute nicht —, sollte wissen, dass die gesamte Webbpräsenz seines Unternehmens von drei Engines gerendert wird, die von drei Unternehmen kontrolliert werden. Das ist ein Risiko. Nicht ein akutes, nicht eines, das morgen zuschlägt. Aber ein strukturelles. Und strukturelle Risiken sind die, die man am leichtesten übersieht und am schwersten korrigiert.

Wenn Sie sich fragen, wie Ihre IT von solchen Abhängigkeiten betroffen ist, welche Alternativen sinnvoll sind, oder wie Sie mehr Souveränität über Ihre Infrastruktur gewinnen: Schreiben Sie an contact@libcom.de. Wir machen eine ehrliche Bestandsaufnahme. Ohne Verkaufsdruck. Mit dem Blick auf das, was langfristig Bestand hat.

Das Web gehört niemandem. Das war die Idee. Drei Motoren sind zu wenig, um das zu gewährleisten. Ein vierter ist ein Anfang.