- keimform.de - https://keimform.de -

Managing diversity

Christian wies bereits auf interessante Vorträge [1] beim 23C3 [2] hin. Ich will kurz über den Vortrag »The Rise and Fall of Open Source« [3] berichten, zu dem ein ausführliches PDF [4] 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:

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 [7].

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 [8] 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 [9] hilfreich, wobei der nun gerade keinen Begriff von Selbstentfaltung hat, aber dennoch wichtige Beobachtungen zusammenfasste.

Ein weiterer wichtiger Vorschlag ist der der Freien Kooperation [10] von Christoph Spehr. Aber erstens hat der seine Schwächen [11] 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.