Moin, du da draußen. Setz dich mal an Deck, während der Wind in den Wanten pfeift, und lass uns ’ne Fahrt machen – nich über die offene Nordsee, sondern durch die Gewässer eines Projekts, das mal als zugänglicher Arch-Nachbau galt und jetzt in schwerer See liegt. Dat is dat Manjaro 2.0 Manifesto, das seit Anfang März 2026 die Foren aufmischt. Als jemand, der seit Jahren Systeme auf Arch-Basis navigiert, seh ich hier ’nen klassischen Fall, wo zentrale Steuerung auf Kollisionskurs mit der Crew geht.
Die Wurzeln
Wie Manjaro überhaupt entstanden ist
Manjaro startete 2011 als Fork von Arch Linux. Arch selbst is ’n reines Rolling-Release-System, bei dem Pakete direkt aus den upstream-Quellen kommen – schnell, aber oft rau an den Kanten. Manjaro hat dat Konzept übernommen, aber ’ne eigene Schicht drübergelegt: drei Repositories in Reihe. Unstable syncronisiert mehrmals täglich mit Arch, Testing filtert wöchentlich, und Stable hält Pakete zurück, bis sie geprüft sind. Dat schafft ’ne Pufferzone, die den Alltag für Nutzer erträglicher macht, ohne den Rolling-Gedanken aufzugeben.
Technisch basiert alles auf pacman und libalpm. Der Package-Manager bleibt schlank, die GUI-Frontend Pamac bringt AUR-Unterstützung, Flatpak- und Snap-Integration mit. Pamac scannt Repos, löst Abhängigkeiten und zeigt AppStream-Metadaten – dat macht den Wechsel von Debian-ähnlichen Systemen leichter. Dazu kommt MHWD, das Manjaro Hardware Detection Tool. Es erkennt Grafikkarten, installiert automatisch die passenden Treiber – besonders bei NVIDIA ’ne echte Erleichterung, weil es Kernel-Module und Konfigurationen in einem Rutsch setzt. Mehrere Kernel-Versionen lassen sich parallel halten, und mhwd-kernel wechselt sie sauber. Calamares als Installer rundet dat ab: grafisch, mit Partitionierung und DE-Auswahl.
Dat ganze System lebt von eigenen Git-Repos, ’nem self-hosted GitLab und dem Forum als zentralem Hafen. Die Infrastruktur – CDN, Mirror, Cloud-Ressourcen bei Hetzner – hält die Pakete am Laufen. Ohne dat würde dat Schiff schnell leck schlagen.
Der Sturm zieht auf
Wo die Lecks sitzen
Über die Jahre hat sich dat Projekt verändert. Aus ’nem reinen Community-Versuch wurde ’ne GmbH & Co KG mit kommerziellem Anstrich. Die Prioritäten drifteten: Der Fokus lag mehr auf Markenpflege als auf der Wartung der Kern-Infrastruktur. Bekannte Probleme wie abgelaufene TLS-Zertifikate blieben liegen, obwohl Teammitglieder Tools und Prozesse angeboten haben. Die Stable-Branche, die eigentlich Sicherheit durch Verzögerung bringen soll, wurde manchmal zur Flasche, weil Updates nicht zügig genug getestet oder freigegeben wurden. Contributors gingen verloren, das Lachen über wiederholte Patzer wurde lauter.
Dat is nich nur ’n organisatorisches Ding. Technisch bedeutet zentrale Steuerung, dass Entscheidungen über Repo-Struktur, Kernel-Patches oder MHWD-Updates von wenigen hängen. Wenn dat Ruder blockiert, stockt der gesamte Update-Flow. Pamac-Nutzer merken dat zuerst, wenn große Paketwellen Treiber oder Bibliotheken brechen. Die Community, die eigentlich mitpullt, fühlt sich wie Ballast statt wie Crew.
Das Manifesto
Die Mannschaft legt den Kurs fest
Am 9. März 2026 hat ’n Teammitglied unter dem Handle Aragorn das Dokument in den Announcements-Thread gestellt. 19 Leute haben unterschrieben, darunter Entwickler, Moderatoren, Community Assistants und sogar der CTO Roman Gilg. Dat is kein kleiner Aufstand.
Das Kernstück: Aufteilung. Der Manjaro Project soll sich von der GmbH trennen und als eingetragener Verein (e.V.) weiterleben – Non-Profit, dezentral, mit flacher Struktur. Jeder interessierte Teammitglied bekommt gleichen Anteil am Eigentum. Neue Mitglieder kommen per Endorsement von mindestens zwei anderen und Abstimmung. Wer geht, kann das jederzeit tun; Rauswurf nur nach langer Inaktivität.
Entscheidungen laufen über Votes: einfache Mehrheit für kleine Sachen, über 70 Prozent für alles mit Risiko. Arbiters – erfahrene Contributor – übernehmen Verantwortung für bestimmte Bereiche, ohne dass jemand drüber hinwegsegelt. Die GmbH wird zum Downstream: sie darf die Marke bis 2029 nutzen, danach für einen Euro abtreten.
Alle Assets – GitHub-Orgs, GitLab-Instanz, Domain manjaro.org, Forum, CDN, OpenCollective Gelder – gehen an den Verein.
Dat is ’ne klare Navigation: weg von einer Person als zentralem Knoten hin zu geteilter Verantwortung. Die Motivation im Dokument is nüchtern: Das Projekt stagniert seit zehn Jahren, Vertrauen ist weg, Contributor-Base ausgedünnt. Die Crew will wieder Wert für die Open-Source-Welt schaffen statt nur als Testkaninchen zu dienen.
Technische Konsequenzen
Was dat für den Rumpf bedeutet
Dat Manjaro 2.0 Manifesto berührt direkt die Maschinen. Die Git-Repos für Manjaro-Kernel, Manjaro-ARM und die eigenen Pakete wären dann unter Vereins-Kontrolle. MHWD-Updates könnten schneller und transparenter laufen, weil Arbiters für Hardware-Domains festgelegt werden. Pamac-Entwicklung, die AUR-Integration und die Branch-Syncs würden nicht mehr von einzelnen Genehmigungen abhängen.
Die drei-Branch-Struktur – unstable, testing, stable – bleibt erhalten, aber die QA-Prozesse könnten offener werden. Statt dass ein Einzelner den finalen Call macht, votet die Crew. Dat reduziert das Risiko von wiederholten Fehlern wie abgelaufenen Zertifikaten oder verzögerten Security-Patches. Für Nutzer bedeutet dat potenziell stabilere Treiber-Installationen und weniger Downtime nach großen Updates.
Gleichzeitig is dat ’n Risiko. Der Übergang von GmbH zu e.V. braucht rechtliche Klärung, Lizenzverträge und Infrastruktur-Migration. Wenn dat Forum oder der CDN temporär hakt, spüren dat alle Mirror und Nutzer.
Die Community-Diskussionen im Thread laufen bereits heiß – über 300 Beiträge in kürzester Zeit.
Der Blick in den Maschinenraum
Mitbestimmung als Kurskorrektur
Open-Source lebt von Mitbestimmung. Bei Arch is dat dezentral und merit-basiert. Manjaro hat dat immer etwas abgemildert, um zugänglicher zu sein. Jetzt will die Crew dat Prinzip auf die Governance ausdehnen. Statt dass die GmbH die Popularität des Namens nutzt und die Community die Arbeit macht, soll der Verein das Schiff führen.
Dat is technisch sinnvoll. Maintainer, die MHWD-Patches oder Pamac-Features vorschlagen, brauchen keine Blockade von oben. Die Stable-Branche profitiert von breiterer QA-Beteiligung. Und die Finanzen – bisher ausgetrocknet – könnten über den Verein wieder in Infrastruktur fließen.
Natürlich bleibt Skepsis. Flache Strukturen können langsam sein, wenn zu viele Votes laufen. Aber die 70-Prozent-Hürde und die Arbiter-Rollen sollen dat ausbalancieren. Dat is ’ne Reifeprüfung für ’n Projekt, das mal als Brücke zwischen Arch und Normalnutzern gegolten hat.
Wo steuern wir hin?
Dat Manifesto is noch offen. Die Crew is in Stage 1: Admins, Mods und Assistants halten nicht-essentielle Arbeit zurück. Philip Müller hat bisher keine umfassende Antwort gegeben. Die Diskussionen laufen weiter, auch außerhalb des Forums.
Für Manjaro-Nutzer bedeutet dat erst mal abwarten. Wer auf Stable läuft, sollte die Update-Threads im Auge behalten. Technisch ändert sich vorerst nix am System – pacman, Pamac und MHWD funktionieren wie gehabt. Aber der Wind dreht sich. Wenn der Verein kommt, könnte dat Schiff wieder Fahrt aufnehmen: mehr Contributor, bessere Wartung, weniger zentrale Engpässe.
Linux lebt von solchen Kurskorrekturen. Manjaro hat ’ne starke Basis – Arch-Power mit benutzerfreundlichen Schichten. Ob die Mannschaft das Ruder zurückbekommt, entscheidet sich in den nächsten Wochen. Dat is dat, was Open Source ausmacht: nicht perfekt, aber korrigierbar. Wenn die Crew gewinnt, gewinnt am Ende das ganze Projekt.
Logbucheintrag beendet.