Message 00115 [Homepage] [Navigation]
Thread: oxderawT00115 Message: 1/3 L0 [In date index] [In thread index]
[First in Thread] [Last in Thread] [Date Next] [Date Prev]
[Next in Thread] [Prev in Thread] [Next Thread] [Prev Thread]

[ox-de-raw] Managing diversity



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



[English translation]
Thread: oxderawT00115 Message: 1/3 L0 [In date index] [In thread index]
Message 00115 [Homepage] [Navigation]