Die Öffnung des Mojo-Compilers ist der Schritt, auf den viele Entwickler gewartet haben. Am 18. August 2026 kündigte Modular an, dass Sprache, Compiler und Werkzeuge von Mojo unter Apache 2.0 mit LLVM-Ausnahmen open source sind. Der Code kam über PR #6904 in modular/modular, mit mehr als 561.000 Ergänzungen und 2.853 geänderten Dateien. Das geschah eine Woche nach Mojo 1.0, das Modular als stabile Grundlage beschreibt.

Abstrakte offene Compiler-Pipeline mit offenem Schloss und generischen Chips

Für Open Source Radar ist das mehr als eine weitere Sprachmeldung. Mojo ist spannend, weil es Python-ähnliche Bedienbarkeit mit systemnaher Performance, SIMD, GPU und AI-Beschleunigern verbinden will. Es war aber leicht abzulehnen, weil der Compiler geschlossen blieb. Für Open-Source-Maintainer, Forschungsteams und Unternehmen mit Sicherheitsprüfung war das ein echter Blocker. Dieser Blocker ist kleiner. Jetzt beginnt der eigentliche Test: Kann Mojo ein ernsthaftes offenes Projekt sein?

Was jetzt offen ist

Modular sagt, Mojo sei unter Apache 2.0 with LLVM exceptions geöffnet. Das Repository enthält Compiler, Tooling und den Code zum Bau der Sprache. Das README nennt den Compiler in /KGEN, die Standardbibliothek in /mojo/stdlib, MAX accelerator library in /max/kernels, Pipelines, Beispiele und Dokumentation. Es beschreibt auch einen Build-Pfad mit Bazel wrapper und ./bazelw run --config=build-mojo KGEN:mojo -- run hello.mojo.

Das ist der Unterschied zu früher. Teile waren offen, doch das Herz der Sprache blieb proprietär. Nun sind Code, Historie und Issues sichtbar. GitHub zeigt rund 27.000 Sterne, fast 3.000 Forks und mehr als tausend offene Issues.

Die Lizenz ist ebenfalls wichtig. Apache 2.0 mit LLVM-Ausnahmen ist für Compiler-Infrastruktur vertraut. Sie beantwortet nicht jede Frage, macht aber juristische und technische Prüfung einfacher als ein geschlossener Toolchain.

Was nicht verwechselt werden darf

MAX ist die erste Grenze. Modular spricht von entfernten device usage restrictions, source-available Teilen, open alliance und neuen Beschleunigern. MAX ist aber nicht dasselbe wie der offene Mojo-Compiler. Die ganze Modular Platform ist nicht im gleichen Sinn open source.

Teams sollten deshalb Sprachexperiment und Plattformabhängigkeit trennen. Mojo, MAX inference server, kernels und model pipelines können unterschiedliche Lizenz-, Distributions- und Beitragsregeln haben.

Auch Beiträge sind ein Thema. Das README akzeptiert Beiträge zu Standardbibliothek, MAX accelerator library, Modellarchitekturen, Beispielen und Dokumentation, aber noch nicht zum Mojo-Compiler selbst. Sichtbarer Code und Fork-Rechte sind nicht automatisch reife Governance.

Warum das wichtig war

Ein Compiler ist keine normale Abhängigkeit. Er definiert Semantik, erzeugt Artefakte und gehört zur Vertrauensbasis. Ist er geschlossen, muss man dem Anbieter bei Support, Plattformen, Sicherheit und Lizenzstabilität glauben. Für eine junge Sprache gegen Rust, Zig, Julia, C++, CUDA, Triton, Numba und Cython ist das viel verlangt.

Mojo richtet sich gerade an Menschen, die Toolchains prüfen: ML-Infrastruktur, performance-orientierte Python-Entwickler, Kernel-Autoren und Hardware-nahe Teams. Die Öffnung beantwortet ihre wichtigste Einwendung.

Die Debatte

Hacker News und Lobsters zeigen Interesse und Skepsis. Einige sehen ein Ausschlusskriterium verschwinden. Andere fragen, ob Mojo zu spät kommt, ob Bazel Builds erschwert, was Qualcomm bedeutet, warum Compiler-Patches noch nicht angenommen werden und wie reif 1.0 wirklich ist.

Das sind die richtigen Fragen: Kann ich aus Quellen bauen? Kann meine Distribution den Compiler paketieren? Kann ich Mojo ohne MAX nutzen? Wird Windows ernsthaft unterstützt? Was passiert bei einer Strategieänderung? Eine offene Sprache muss genau diese Prüfung bestehen.

Wo Mojo passen könnte

Mojo ist nicht nur “schnelleres Python”. Der stärkere Anspruch ist Python-Nähe plus Kontrolle: ownership, lifetimes, Compile-Time-Programmierung, explizite Typen, SIMD, GPU und AI-Beschleuniger. Wenn das funktioniert, gibt es eine Nische.

Die Zielgruppe sind Entwickler von numerischen Kernels, Datenverarbeitung, Inference-Infrastruktur oder kritischen Bibliotheksteilen, die heute C++, Rust, Cython, Numba, JAX, Triton oder CUDA verwenden. Mojo will den Sprachwechsel billiger machen, ohne Performance als Magie zu verkaufen.

Wie man testet

Der erste Test sollte langweilig sein: installieren, Beispiel kompilieren, Quell-Build versuchen, Betriebssystem, Hardware, Build-Zeit, Cache und Fehler notieren. Der zweite Test vergleicht mit einer echten internen Alternative. Bewerten Sie Packaging, Editor, Tests, Deployment und Onboarding, nicht nur Geschwindigkeit. Der dritte Test ist organisatorisch: Lizenzen lesen, Mojo von MAX trennen, Beitragsregeln prüfen und fehlende Compiler-Beiträge als aktuelle Governance-Grenze behandeln.

Urteil

Mojo verdient neue Aufmerksamkeit, weil das wichtigste versteckte Teil sichtbar ist. Adoption hängt aber von externen Builds, Dokumentation, öffentlichem Issue-Triage, klaren Beitragsgrenzen, Windows, Paketen und einer ehrlichen Trennung von Mojo und MAX ab. Der offene Compiler ist nicht das Ende, sondern der Beginn des Tests.