Auf der Suche nach dem Neuen im Alten
Artikel drucken

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.

Kategorien: Freie Software, Praxis-Reflexionen

Tags: , , ,

18. Dezember 2006, 12:30 Uhr   5 Kommentare

1 benni (18.12.2006, 18:06 Uhr)

Ich verstehe nicht so ganz, wieso er einerseits die Zusammenarbeit bei *BSD lobt, aber andererseits im Fork das Übel sieht (schliesslich ist die BSD-Vielfalt auch durch Forken entstanden). Mir scheint es eher so zu sein, dass nicht entscheidend ist ob geforkt wird, sondern wie. Wenn man sich danach als Konkurrenten (im destruktiven Sinn) betrachtet ist das sicherlich schädlich. Wenn man auch weiterhin zu Zusammenarbeit in der Lage ist (und sei sie auch nur punktuell), dann ist doch schon die Halbe Miete gewonnen für das Produktivmachen von Widersprüchen (so würde ich das bezeichnen, was er „managing diversity“ bezeichnet).

2 StefanMz (19.12.2006, 12:48 Uhr)

Er sieht ja nicht grundsätzlich im Fork ein Übel (siehe Liste der Gründe: einer von fünf ist akzeptabel), sondern in vielen Forks, die gerade keine Widersprüche produktiv machen, sondern schlicht nur die Ressourcen aufspalten. Diese Kritik an dem leichtfertigen Umgang mit Forks halte ich für berechtigt. Er liefert nur keine wirklich nützlichen Hinweise, wie damit umzugehen ist. Alle Vorschläge laufen auf „Technik“ hinaus, und das ist es einfach nicht.

Hast du weitergehende Vorstellungen zum „Produktivmachen von Widersprüchen“? Das ist ja leicht gesagt… Und leicht gefragt;-)

3 benni (19.12.2006, 13:33 Uhr)

Ne, hab keine genaueren Vorstellungen, ausser vielleicht, dass es schon viel Hilft, wenn man sich das als Ziel setzt. Und vielleicht, dass ich diese Frage für ziemlich zentral halte für die Keimformfrage.

Freie Kooperation bietet vielleicht einen Teil der Antwort?

4 keimform.de » Bericht vom CCC (31.12.2006, 16:57 Uhr)

[…] Zu dem von Stefan vorab analysierten Vortrag “The Rise and Fall of Open Source” konnte ich nicht, aber (wie ich von anderen gehört habe) scheint der Vortrag auch nicht so doll gewesen zu sein. […]

5 keimform.de » Freie Software produzieren (09.04.2007, 17:03 Uhr)

[…] Ein Fork ist die vollzogene Spaltung eines Projektes, was die Aufteilung der menschlichen (und ggf. infrastrukturellen) Ressourcen bedeutet. Die Möglichkeit eines Forks steht jedem offen. Da ein Fork niemandem nutzt, die Möglichkeit zum Fork die treibende Kraft hinter dem Willen zum Konsens. Daher gibt es in Freien Projekten auch keine wirklichen Diktatoren im Sinne eines Tyrannen [vgl. dazu auch einen früheren Blogbeitrag]. Einen »gutmütigen Diktator« würde Fogel deswegen auch eher als von der Community akzeptierten »Schiedsrichter« bezeichnen. Ein guter Schiedsrichter lässt die Dinge sich selbst entwickeln, Diskussion und Experimente sind die wichtigsten Mittel. Nur im Notfall hat der Schiedsrichter das letzte Wort. […]

Schreibe einen Kommentar