Macht zu verteilen ist nicht dasselbe, wie sie zu trennen.

Der Vorschlag verteilt Befugnisse auf mehrere Gremien. Das sieht dezentral aus, aber Macht zu verteilen ist nicht dasselbe, wie sie zu trennen. Für Entwickler sollte der Unterschied vertraut sein. Governance braucht Gewaltenteilung genauso wie Softwarearchitektur Separation of Concerns braucht. Verantwortung auf verschiedene Klassen zu verteilen, schafft keine saubere Architektur, wenn diese Klassen so miteinander gekoppelt bleiben, dass die Trennung faktisch aufgehoben wird.

Macht darf nicht nur verteilt werden. Sie muss getrennt werden.

Die überarbeiteten Regeln für die Unit Councils sind ein gutes Beispiel. Das Council ist für langfristige Policy und Strategie zuständig und kann einen Coordinator oder Deputy nun mit Zweidrittelmehrheit abberufen. Besondere Quorumsregeln verhindern, dass diese Rollen ihre eigene Ersetzung oder Abberufung einfach durch Fernbleiben blockieren.

Bei normalen Council-Entscheidungen ist es anders. Dafür setzt das Quorum weiterhin voraus, dass entweder Coordinator oder Deputy Coordinator anwesend ist. Das für langfristige Policy und Strategie zuständige Gremium kann diese Befugnis also normalerweise nicht ausüben, wenn keiner seiner beiden operativen Leiter anwesend ist. Es gibt einen Ausweg, weil das Council letztlich einen von beiden abberufen kann. Damit wird aus einem gewöhnlichen Sachkonflikt aber potenziell die Frage, ob erst jemand seines Amtes enthoben werden muss, bevor das Council wieder entscheiden kann.

Ein Council, das ohne Anwesenheit seiner Exekutive keine normale Entscheidung treffen kann, ist kein unabhängiges Council. Wenn die vorgesehene Absicherung darin besteht, dass niemand das ausnutzen würde, ist das keine Absicherung. Absicht allein ist nie eine Absicherung. Regeln sind es.

Das wichtigere Problem zeigt sich auf Ebene des Cooperation Panel. Das Panel ist nicht bloß eine Koordinierungsrunde. Es erstellt und priorisiert die Product Roadmap und fungiert als Product Owner für TYPO3 CMS. Seine Regeln können von der General Assembly geändert werden, und genau dort gehören grundlegende Änderungen der Governance hin.

Sofern die Association Bylaws nichts anderes bestimmen, können dieselben Regeln allerdings auch durch eine gemeinsame Entscheidung von Association Board und Cooperation Panel geändert werden. Die Erklärung lautet, dass dies bereits restriktiver sei, als dem Board zu erlauben, die Policy allein zu ändern. Das mag stimmen, beantwortet aber die eigentliche Frage nicht. Ein zusätzlicher Zustimmungsschritt ist noch keine Gewaltenteilung.

Das Board braucht Spielraum zum Regieren, das Panel ebenso. Aber innerhalb der Regeln zu regieren und die Regeln selbst zu bestimmen sind zwei grundverschiedene Befugnisse. Niemand will jedes operative Detail vor die General Assembly zerren. Das Problem beginnt dort, wo dieselbe Änderungsbefugnis auch Regeln erfasst, die festlegen, wer Macht ausübt, wie und in welchem Umfang diese Macht eingesetzt werden darf und wo ihre Grenzen liegen.

Dann reden wir nicht mehr über Verwaltung, sondern über Governance der Governance. Das Board arbeitet für die Association und ihre Mitglieder. Die Mitglieder arbeiten nicht für das Board. Dasselbe Prinzip gilt für jedes Gremium, dessen Befugnisse letztlich von diesen Mitgliedern kommen.

TYPO3 ist kein Staat, aber der Vergleich ist nützlich, weil diese Regeln Dinge ähnlich einer Verfassung gestalten. Sie schaffen Institutionen, verteilen Befugnisse, legen Verfahren fest und setzen Grenzen. In diesem funktionalen Sinn baut TYPO3 gerade eine kleine Verfassung für seine Governance.

Kontrollmechanismen gibt es bereits. Die General Assembly ist das oberste Organ der Association. Es wählt zentrale Gremien, ändert die Statuten und kann Beschwerden gegen Exekutivorgane behandeln. Mitglieder haben außerdem rechtliche Möglichkeiten, Entscheidungen anzufechten, die gegen Gesetz oder Statuten verstoßen.

Was ich in dieser Architektur nicht finde, ist das Gegenstück zu einer Verfassungsprüfung. Es gibt kein dauerhaftes, institutionell unabhängiges internes Gremium, das eine deutlich engere Frage beantworten kann, bevor ein Streit zu einem politischen Kampf in der General Assembly oder zu einem externen Rechtsfall werden muss: Durfte dieses Gremium eigentlich tun, was es gerade getan hat?

Genau das meine ich mit einem Verfassungsgericht. Sein Mandat sollte bewusst langweilig sein. Es soll nicht über Roadmap-Prioritäten, Technologien oder darüber entscheiden, welche Unit die bessere Idee hat. Es soll entscheiden, ob ein Gremium zuständig war, ob verbindliche Verfahren eingehalten wurden und ob delegierte Befugnisse überschritten wurden. Wenn nicht, muss es die Entscheidung aufheben oder zur erneuten Entscheidung zurückverweisen können.

Eine Verfassung ist keine Beschreibung dessen, wer gerade Macht hat. Sie ist ein Regelwerk dafür, was passiert, wenn diese Macht angefochten wird. Ein solches Gremium funktioniert nur, wenn es von den Institutionen unabhängig ist, die es kontrolliert. Seine Legitimation sollte von den Mitgliedern kommen, und Board, Units oder Cooperation Panel dürfen seine Mitglieder nicht absetzen können, nur weil ihnen eine Entscheidung nicht gefällt. Dafür braucht es keinen weiteren Verwaltungsapparat. Es braucht eine klare Grenze.

TYPO3 hat bereits eine Ombudsfunktion und externe Unterstützung für Beschwerden, Konflikte und Code-of-Conduct-Fälle. Das löst ein anderes Problem. Ombuds schützt Menschen und hilft, Konflikte zu lösen. Verfassungsprüfung entscheidet, ob Institutionen innerhalb ihres Mandats handeln. Das Business Control Committee kommt dem näher, weil es bereits eine Kontrollfunktion hat. Aber sein Mandat einfach zu erweitern, würde einem einzigen Gremium wiederum zu viel Kontrolle geben.

Kontrolle darf nicht zu einer weiteren Machtkonzentration werden. Verfassungsprüfung muss eine separate Funktion bleiben.

Einige der Schlussfolgerungen oben lassen sich mit dem Hinweis auf eine Ausnahme, die Bylaws oder eine Erklärung im FAQ bestreiten. Geschenkt. Das ist aber kein Grund, bei der Präzision weniger anspruchsvoll zu sein. Im Gegenteil. Governance-Regeln sollten Leser nicht dazu zwingen, ihre tatsächlichen Grenzen aus mehreren Dokumenten zusammenzubauen oder davon abhängen, dass sich alle darauf einigen, was die Autoren vermutlich gemeint haben.

Eine Verfassung sollte auch dann eindeutig bleiben, wenn jemand sie bewusst anders liest, nicht nur dann, wenn alle mit gutem Willen herangehen. Das bedeutet nicht, jede Unit-Regel in einen hundertseitigen Gesetzestext zu verwandeln. Es bedeutet, dass überall dort, wo Macht vergeben, begrenzt, delegiert oder entzogen wird, die Formulierung diese Grenzen klar machen muss.

Wenn eine Absicherung nur in einer Erklärung existiert, existiert sie noch nicht in der Architektur. Der öffentliche Review hat bereits gezeigt, warum das wichtig ist. Mehrere Regelungen wurden gerade deshalb geändert, weil Reviewer die Absichten der Autoren mit dem verglichen haben, was der Text tatsächlich erlaubt. Genau diese Präzision braucht Governance, bevor Befugnisse vergeben werden, nicht erst dann, wenn ein Konflikt alle dazu zwingt, darüber zu streiten, was angeblich gemeint war.

Der öffentliche Review hat den ursprünglichen Vorschlag besser gemacht. Das ist das stärkste Argument dafür, denselben Prozess fortzusetzen, bis die verbleibenden strukturellen Fragen geklärt sind. Operative Unzulänglichkeiten lassen sich später beheben.

Berichtsintervalle und Meeting-Verfahren können geändert werden, wenn die Praxis zeigt, dass sie nicht funktionieren. Für Grenzen institutioneller Macht muss ein anderer Maßstab gelten, denn sie später zu ändern bedeutet, Menschen innerhalb der bereits bestehenden Struktur darum zu bitten, die Befugnisse einzuschränken, die sie selbst inzwischen erhalten haben. Community-Kultur kann auf Vertrauen basieren. Governance darf davon nicht abhängen. Gute Governance lässt uns Menschen Aufgaben anvertrauen, ohne ihnen selbst trauen zu müssen. Die Frage ist ohnehin nicht, ob wir den Menschen vertrauen, die dieses System heute betreiben werden. Die Frage ist, ob das System auch dann noch funktioniert, wenn wir es irgendwann nicht mehr tun.

Deshalb würde ich gegen den Vorschlag in seiner jetzigen Form stimmen und der Governance Working Group ein klares Mandat geben, die verbleibenden strukturellen Fehler zu beheben, bevor sie ihn erneut der General Assembly vorlegt. Das ist weder eine Stimme gegen Units noch gegen eine Governance-Reform. Der Review hat bereits gezeigt, dass sich der Vorschlag verbessern lässt, wenn konkrete Schwächen benannt und behoben werden. Ich würde diese Arbeit zu Ende bringen, bevor wir die Schlüssel übergeben.

TYPO3 hat einen großen Governance- und Product-Split bereits hinter sich. Die Lehre daraus sollte nicht sein, beim nächsten Mal den richtigen Leuten zu vertrauen. Die Lehre sollte sein, Regeln zu bauen, die auch dann noch Bestand haben werden, wenn die falschen Leute an den Hebeln sitzen.

Offizieller Aufruf zum Review:
https://news.typo3.com/article/review-the-proposed-rules-for-typo3-units-and-the-unit-cooperation-panel

Regeln für TYPO3 Units, PR #49:
https://github.com/TYPO3-Documentation/Policy/pull/49

Regeln für das Unit Cooperation Panel, PR #50:
https://github.com/TYPO3-Documentation/Policy/pull/50

Bisherige Ergebnisse des Review-Prozesses:
https://news.typo3.com/article/summary-of-the-public-review-rules-for-typo3-units-and-the-unit-cooperation-panel