Federlesen #5: Die Schattenseiten einer Konsenskultur

Inhaltsverzeichnis

Keine Frage, dass bei einem Open-Source-Projekt die "Freiheit" großgeschrieben wird. Transparenz, Toleranz und Offenheit spielen deshalb auch in der Apache-Community eine bedeutende Rolle. Ganz reibungslos verläuft das Zusammenspiel jedoch nicht immer.

Jeder kann nach der Registrierung in den jeweiligen Mailing-Listen unterschiedlicher Apache-Projekte mitdiskutieren oder Fehler melden. Das ist sogar explizit gewünscht. Nur bei Abstimmungen grenzt sich der Kreis der Stimmberechtigten auf als Committer anerkannte Mitglieder ein. Eine Abstimmung (beispielsweise für die Erstellung oder Auslieferung eines neuen Releases) dauert mindestens drei Tage, wobei derjenige, der zur Wahl eingeladen hat, am Ende das Ergebnis und die daraus folgenden Schritte bekannt gibt. Bei den Abstimmungsarten wird zwischen Meinungsbildung zu bestimmten Themen, Release-Planungen oder -Freigaben und Codeänderungen unterschieden. Bei den ersten beiden reicht eine Stimmenmehrheit, und Gegenstimmen werden nicht als Veto bezeichnet.

Mehr Infos

Die Kolumne bisher:

• Federlesen #1: The Apache Way
• Federlesen #2: Infrastruktur und Prozesse als Erfolgsrezept
• Federlesen #3: Das Jahr unter Apachen
• Federlesen #4: Kommunizieren und Teilnahme bei Apache
• Federlesen #5: Die Schattenseiten einer Konsenskultur

Nur bei Codeänderungen gilt das die Freigabe aufschiebende Veto-Prinzip. Erst wenn der Grund für das Veto beseitigt ist, etwa durch eine korrigierte Produktversion oder Codeänderung, kann eine Abstimmung erneut erfolgen. Das setzt bei allen Beteiligten ein hohes Maß an Disziplin und Konsenswillen voraus. Zu viele und zu oft ungeklärte Gegenstimmen oder eine zu geringe Wahlbeteiligung können eine Gefahr für die Weiterentwicklung des Projekts sein. Deswegen streben Projekte möglichst einen breiten Konsens bei einer großen Wahlbeteiligung an und wiederholen lieber die Abstimmung oder verlängern den Zeitraum. Ein erfolgreiches Stimmergebnis ist erreicht, wenn mehr positive (+1) als negative Stimmen (-1) abgegeben wurden. Enthaltungen sind möglich, werden aber nicht mitgezählt.

Spannend wird es, wenn es um die Neuausrichtung eines Projekts geht, da es dann mitunter zum heftigen Streit zwischen Traditionalisten (die lieber den Code beibehalten wollen) und Erneuerern (die etwa eine neue Architektur vorschlagen) kommt. Als Streitschlichter sind alle "unentschiedenen" Projektmitglieder und vor allem der Projektleiter gefordert, damit sich ein gesundes und tragfähiges Ergebnis für alle findet. Denn nicht erst seit Rosa Luxemburg gilt, dass die Freiheit immer die des Andersdenkenden ist. Hilfreich mag auch James Davidsons 2000 verfasster Ratschlag für Apache-Revolutionäre sein, nachdem jeder Entwickler das Recht hat, im nichtversionierten Branch eigene Ideen auszuprobieren und reifen zu lassen, bis sie in den offiziellen Trunk überführt werden.

Sandkasten- und Brutkastenspiele

Eine konfliktfreie Spielwiese für neue Ideen kann ein dafür eingerichteter Bereich innerhalb des Projekts (Sandkasten) oder außerhalb im Brutkasten sein. Oft zeigt sich an lauffähigem Code am besten, ob die neuen Ideen tragfähig sind und sich verwenden lassen. Manchmal werden im Rahmen der ApacheCon-Konferenz sogenannte Hackathons veranstaltet, um neue Ideen mit einem dort erstellten Prototypen zu validieren.

Auch kommt es nicht selten vor, dass das Mutterprojekt in mehrere unabhängige Teilprojekte (etwa bei Lucene und Tika) aufgeteilt wird oder dass sich bei einer Neuausrichtung mehrere thematisch verwandte Projekte zusammenschließen, um gemeinsam ein neues Produkt zu entwickeln (zum Beispiel CXF und ServiceMix bei Karaf).