[ox-de-raw] Managing diversity
- From: Stefan Meretz <stefan.meretz hbv.org>
- Date: Mon, 18 Dec 2006 12:43:39 +0100
http://www.keimform.de/2006/12/18/managing-diversity/
Managing diversity
Von StefanMz, 18. Dezember 2006, 12:30 Uhr
Christian wies bereits auf interessante Vorträge
[http://www.keimform.de/2006/12/03/noch-ein-kongress/] beim 23C3
[http://events.ccc.de/congress/2006/Home] hin. Ich will kurz über den
Vortrag »The Rise and Fall of Open Source«
[http://events.ccc.de/congress/2006/Fahrplan/events/1523.en.html]
berichten, der ein ausführliches PDF
[http://events.ccc.de/congress/2006/Fahrplan/attachments/1165-risefall-paper-long.pdf]
online hat und 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
[http://www.opentheory.org/kooperenz/text.phtml] und ich
[http://www.opentheory.org/ko-kurrenz/text.phtml] 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 [http://kerneltrap.org/node/7061].
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
[http://www.freie-gesellschaft.de/wiki/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 [http://catb.org/~esr/writings/cathedral-bazaar/] hilfreich,
wobei der nun gerade keinen Begriff von Selbstentfaltung hat, aber
dennoch wichtige Beobachtungen zusammenfasste.
Ein weiterer wichtiger Vorschlag ist der der Freien Kooperation
[http://www.freie-gesellschaft.de/wiki/Freie_Kooperation] von Christoph
Spehr. Aber erstens hat der seine Schwächen
[http://www.opentheory.org/dschungel/text.phtml] 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.
--
Start here: www.meretz.de