Managing diversity

Christian wies bereits auf interessante Vorträge beim 23C3 hin. Ich will kurz über den Vortrag »The Rise and Fall of Open Source« berichten, zu dem ein ausführliches PDF online gibt und der deswegen schon vorab besprochen werden kann.

Tonnerre Lombard, BSD-Entwickler, verweist auf die Gefahren von Forks (Spaltung eines Projekts), was im Jahr 2006 bedrohliche Ausmaße angenommen und zu einer „massiven Ausdünnung von Open Source Projekten“ geführt habe. In einigen Bereichen hätten Closed-Source Produkte wieder Terrain zurückgewonnen. Denn eines sei klar: Ein Fork bedeutet immer Aufteilung der Ressourcen und damit potenziell Schwächung beider Projekte – des alten und des neuen.

Als Gründe für einen Fork nennt Lombard:

• Uneinigkeit über den Einsatz neuer Technologien: Neue Techniken mit neuen Möglichkeiten sofort einsetzen oder lieber das Projekt auf Basis der bestehenden Technologien stabilisieren? Besonders wahrscheinlich sei ein Fork, wenn die minoritäre Fraktion Server und den Release Prozess kontrolliert.
• Uneinigkeit über das Versionsverwaltungssystem: Bei CVS bleiben oder zu SVN wechseln – oder noch was anderes? Forks entstünden dadurch, dass eine Gruppe für das gleiche Projekt einfach ein neues Repository unter SVN aufsetzt. Die neuen Versionsverwaltungen würden Forks auch stark unterstützen, da es inzwischen sehr leicht sei, die Sources zu duplizieren und in ein neues Repository zu füllen.
• Rolle des Maintainers: Wenn der Diktator nicht so „gutmütig“ ist und häufig Beiträge (Patches oder anderes) abweist, weil die Richtung nicht genehm ist, kann ein Fork eine verfahrene Situation auflösen. Beispiel sei das XFree86-Projekt, dessen Fork X.Org anschließend wesentlich erfolgreicher gewesen wäre. Solche Forks nennt Lombard ausdrücklich „Forks aus positiven Gründen“.
• Persönlicher Streit im Projekt: Wenn „Alpha Geeks“ miteinander konkurrieren anstatt zu kooperieren, dann sei beides möglich – schnelle Entwicklung oder Forks. Es gäbe sehr viele weitere Gründe, warum sich Entwickler untereinander nicht mögen. Problematisch sei es, wenn sich Fraktionen herausbilden und einander bekämpfen. Dann ist der Fork nicht mehr weit. – Mit der problematischen ausschließenden Entgegensetzung von Konkurrenz und Kooperation haben sich Benni und ich anderenorts auseinandergesetzt.
• Uneinigkeit über Lizenzen: Forks würden auch aufgrund missliebiger, hier: Nicht-Copyleft-Lizenzen, gemacht. Als Beispiel nennt Lombard GnuTLS (GPL) als Fork von OpenSSL (BSD-Lizenz). Beide Projekte würden nun mit ähnlichen Problemen kämpfen, da Kryptographie ein schwer zu beherrschendes Gebiet sei. Lombard hätte auch den GNOME-KDE-Fork nennen können, wobei sich hier eine gute Kooperation herausgebildet hat.

Als Hauptgrund sieht Lombard den „Fork aus persönlichen Gründen“ an. Das könnten kommerzielle Closed-Source Firmen gezielt ausnutzen. Firmen hätten normalerweise keine Chance, mit einem lebendigen Projekt zu konkurrieren, da dieses wesentlich innovativer sei. Dagegen wären Firmen oft besser darin, die Oberflächen der Software aufzuräumen, um das Produkt Enduser-tauglich (und damit verkaufsfähig) zu machen. Daher kann es für eine Firma sinnvoll sei, abzuwarten, bis ein Projekt „Businessreife“ erlangt habe – u.U. auch unterstützt durch eigene Beiträge –, um dann gezielt „psychologische Verwundbarkeiten“ auszunutzen und das Projekt zu spalten. Ist das Projekt auf diese Weise ausgebremst, könnte die Firma nun durch Nachbau der Funktionalitäten und mit einem neuen Design den monetären Gewinn einstreichen, während die geforkten Projekte leer ausgingen. – Lombard sagt nichts dazu, ob so ein Szenario schon stattgefunden hat, oder ob er das nur als potenzielle Gefahr ansieht.

Was tun?

Zunächst sei es wichtig, zwischen persönlichen und technischen Fork-Gründen zu unterscheiden. Auf der technischen Ebene lassen sich eben auch technische Maßnahmen finden, um einen Fork zu vermeiden. Als Beispiel nennt er Branches (Abzweigungen, wörtlich: „Äste“) in der Versionsverwaltung, in denen „verschiedene neue Dinge“ oder „unterschiedliche Optimierungen“ ausprobiert werden können. Diese sollten dann nach Prüfung und ausführlichem Testen stets wieder in den „stabilen Zweig“ (eigentlich: Trunk – „Stamm“) integriert werden. Es gäbe nun mal keinen einzigen Weg („one and only way“): „Die Leute werden ihre Sachen auf ihre Weise tun, und wenn du sie versuchst zu stoppen das zu tun, dann könntest du sie komplett verlieren“.

Als Alternative schlägt Lombard eine „managed diversity“ (etwa: gemanagte Vielfältigkeit) vor, die er in der BSD-Community realisiert sieht. Im Unterschied zu Außenwahrnehmung sei es nämlich nicht so, dass die verschiedenen BSD-Projekte (OpenBSD, NetBSD, FreeBSD und weitere) miteinander konkurrieren würden, sondern sie hätten eine Menge Cross-Development („Überkreuz-Entwicklung“, also wechselseitige Nutzung entwicklelter Bausteine). Auf diese Weise könnte dennoch eine ziemliche Spezialisierung der einzelnen Projekte ohne Ressourcenverschwendung erreicht werden. Das hätte sich mehrfach bewährt, auch beim letzten angeblichen Tod von NetBSD.

Hm, reicht das?

Soweit meine Zusammenfassung der Darstellung von Tonnerre Lombard. Obwohl Lombard betont, dass die persönlichen Konflikte der wesentliche Forkgrund seien, geht er dann darauf in seinen Vorschlägen nicht groß ein. Auch die „managed diversity“ ist ausschließlich technisch gemeint: Keine Ressourcen verschwenden durch gemeinsame Nutzung von Modulen, was ja auch sehr sinnvoll ist. Aber das schafft die „persönlichen Konflikte“ nicht aus der Welt.

Am nähsten dran war Lombart mit der Aussage, das man den Leuten eine Möglichkeit geben muss, dass zu tun, was sie ohnehin tun wollen. Oder um es in anderer Sprache zu sagen: Die Bedingungen für die Selbstentfaltung müssen bewusst hergestellt werden. Der Spruch „Selbstentfaltung als Voraussetzung für die Entfaltung aller und umgekehrt“ muss gezielt in reale Projektstrukturen und Formen der persönlichen Kommunikation umgesetzt werden. Zu glauben, so was entstehe von alleine, ist naiv: Dann setzen sich wohl die üblichen, eingeschliffenen Verhaltensweisen des „auf-Kosten-Anderer“ durch. Klar bietet Freie Software als solche schon eine ganz gute Infrastruktur (Nicht-Rivalität des Guts, Schutz durch die freien Lizenzen), aber das reicht nicht aus. Nachhaltig erfolgreiche Projekte sind solche geworden, in denen – mehr oder minder intuitiv – ein Maintainer die unterschiedlichen Bedürfnisse im Projekt beachtet und in eine „produktive Form“ gebracht hat. Dabei waren sicherlich auch einige Verallgemeinerungen wie etwa die von Eric Raymond hilfreich, wobei der nun gerade keinen Begriff von Selbstentfaltung hat, aber dennoch wichtige Beobachtungen zusammenfasste.

Ein weiterer wichtiger Vorschlag ist der der Freien Kooperation von Christoph Spehr. Aber erstens hat der seine Schwächen und zweitens hat der nie sowohl die deutschsprachigen wie auch kulturellen Grenzen wesentlich überschritten. Oder weiss da jemand mehr?

Fazit: „Managing diversity“ bleibt eine – theoretisch weitgehend unklare – Aufgabe. Von der Praxis nicht zu reden.