Message 00155 [Homepage] [Navigation]
Thread: oxderawT00155 Message: 1/1 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] keimform.de: Freie Software produzieren



http://www.keimform.de/2007/04/09/freie-software-produzieren/

Freie Software produzieren

Von StefanMz, 9. April 2007, 17:03 Uhr 

Obwohl schon eine Weile unter einer Creative Commons-Lizenz erhältlich, 
ist das Buch »Producing Open Source Software. How to Run a Successful 
Free Software Project« [http://producingoss.com/] von Karl Fogel 
[http://www.red-bean.com/kfogel/] im deutschsprachigen Raum kaum 
rezensiert worden. Ok, das Buch wurde auf englisch verfasst, aber 
gleichzeitig ist es so interessant, dass es mehr Aufmerksamkeit 
verdient. Vielleicht erleichtert die folgende Besprechung ja den 
Einstieg. Übersetzungen stammen von mir.

Karl Fogel hat eine Anleitung zur Gründung (oder Übernahme) und 
Weiterentwicklung eines Freien Softwareprojektes geschrieben. Grundlage 
sind vor allem seine Erfahrungen aus dem Subversion-Projekt 
[http://subversion.tigris.org/]. Ausgangspunkt ist die These: »Die 
meisten Freien Softwareprojekte schlagen fehl«. Fast checklistenartig 
kann man das Buch als Ratgeber verwenden, um die verschiedenen Fallen 
auf dem Weg zum erfolgreichen Projekt zu umgehen. Was aber macht ein 
Projekt erfolgreich, und was sind die Hauptschwierigkeiten?

   »Die Vergänglichkeit, oder besser die potenzielle Vergänglichkeit,
   von Beziehungen ist vielleicht die gewaltigste Aufgabe in einem neuen
   Projekt. Was wird all diese Leute überzeugen lang genug
   zusammenzubleiben, um etwas Nützliches herzustellen? Die Antwort auf
   diese Frage ist komplex genug, um den Rest des Buches zu
   beanspruchen, aber wenn sie in einem Satz ausgedrückt werden soll,
   dann würde dieser so lauten:

      Die Leute sollten spüren, dass ihre Verbindung zu einem Projekt
      und ihr Einfluss auf das Projekt direkt proportional ist zu ihren
      Beiträgen.

   Keine Klasse von Entwicklern oder potenziellen Entwicklern sollte
   sich jemals aus nicht-technischen Gründen herabgesetzt oder
   diskriminiert fühlen.«

Ein besonderer Schwerpunkt liegt also auf den sozialen Prozessen in 
einem Projekt. Das macht das Buch so lesenswert und auch über den 
Rahmen von Softwareentwicklung hinaus nützlich. Schauen wir, ob die 
Erwartungen erfüllt werden.

Die Gliederung der Hauptkapitel sieht so aus:
1. Einleitung
2. Starten
3. Technische Infrastruktur
4. Soziale und politische Infrastruktur
5. Geld
6. Kommunikation
7. Paketerstellung, Freigabe und tägliche Entwicklung
8. Management von Freiwilligen
9. Lizenzen, Copyrights und Patente

Im Folgenden gehe ich auf die Kapitel 4, 6 und 8 ausführlicher ein.

*Soziale und politische Infrastruktur*

Obwohl oft genannt erfassen Meritokratie 
[http://de.wikipedia.org/wiki/Meritokratie],
Kooperation [http://de.wikipedia.org/wiki/Kooperation] und lauffähiges 
Programm (IETF 
[http://de.wikipedia.org/wiki/Internet_Engineering_Task_Force]: »Wir 
lehnen Könige, Präsidenten und Abstimmungen ab. Wir glauben an groben 
Konsens und lauffähige Programme«) nicht umfassend die Erfolgsfaktoren 
Freier Softwareprojekte. Um eine Kontinuität im Projekt zu erreichen, 
sind zwei weitere Faktoren entscheidend: Die Spaltbarkeit (forkability) 
des Projektes und die gutmütige Diktatorenschaft (benevolent 
dictatorship).

Ein Fork [http://de.wikipedia.org/wiki/Fork_%28Softwareentwicklung%29] 
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 [http://www.keimform.de/2006/12/18/managing-diversity/]]. 
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.

Mit zunehmendem Alter und zunehmender Größe entwickeln sich Projekte weg 
von der gutmütigen Diktatorenschaft hin zu »konsensbasierter 
Demokratie«. Ein Konsens ist dann erreicht, wenn niemand einer 
Konsensformulierung widerspricht. Kann ein Konsens in diesem Sinne 
nicht erreicht werden, ersetzen Abstimmungen immer öfter die 
Entscheidung durch einzelne Schiedsrichter. Es bleibt jedoch die 
schwierige Entscheidung zu treffen, wann genau eine Abstimmung sinnvoll 
ist, denn einen Abstimmung beendet einen Diskussionsprozess. In manchen 
Projekte gibt es wiederum ein Veto, um zu schnelle Entscheidungen zu 
verhindern. Fogel empfiehlt, die gefundenen Regeln in einem Projekt 
aufzuschreiben, damit diese für alle (gerade auch neue Mitglieder) 
transparent sind.

*Kommunikation*

Die Fähigkeit gut zu Schreiben ist auf lange Sicht wichtiger als die 
Fähigkeit gut zu programmieren. Das Schreiben per E-Mail ist in den 
meisten Projekten der zentrale Kontakt zu anderen Projektmitgliedern. 
Deswegen gilt:

   »Du bist was du schreibst.«

Folgende Punkte sind zu beachten:

** *Struktur und Formatierung*: Inhaltlich klar geschriebene und sauber 
formatierte Mails erleichtern das Lesen für andere ungemein. Einige 
Regeln haben sich etabliert: Nur-Textformat, Zeilenlänge maximal 72 
Zeichen, Text in Absätze aufteilen, Absätze durch Leerzeilen trennen, 
bei Antworten die nicht gemeinten Teile des Ursprungstextes löschen, 
Betreff sorgfältig formulieren und ggf. ändern etc.
** *Inhalt*: Erleichtere Anderen das Lesen deines Beitrages. Fasse 
längere Beiträge zusammen. Suche Archiv-URLs heraus, wenn du dich auf 
zurückliegende Debatten beziehst. Verwende keine Übertreibungen, 
betreibe keine sprachliche Aufrüstung aus Angst, nicht gehört zu 
werden. Lies deine Mail noch einmal durch bevor du sie abschickst: 
Kannst du sie kürzen oder freundlicher formulieren?
** *Ton*: Technische Diskussionen tendieren zu einem knappen sachlichen 
Schreibstil, und daran ist auch nichts Falsches. In bestimmten 
Situationen ist es jedoch angebracht, emotionale Botschaften zu senden. 
Ein Smiley oder ein guter Wunsch zeigen, dass man positiv gestimmt ist, 
auch wenn die Aussagen inhaltlich kritisch waren. Wer aufmerksam über 
längere Zeit die Kommunikation beobachtet, wird herausfinden, welche 
Formen bei wem angemessen ist.
** *Grobheiten erkennen*: Bestimmte Ausdrucksweisen werden als grob oder 
unhöflich wahrgenommen. Dies kann Ausdruck unterschiedlicher 
Kommunikationskulturen sein. Diese gilt es herauszufinden, um damit gut 
umzugehen. Ein knapper Schreibstil ist meist Ausdruck begrenzter Zeit 
und nicht von Unfreundlichkeit oder Kälte. Bei Fehlermeldungen helfen 
Basisfragen, bestimmte Fehlerquellen auszuschließen; sie sollen nicht 
demonstrieren, dass der Fragende blöd ist: In der Regel gibt es keine 
verborgene Bedeutung hinter einer Frage. Manchmal kann es helfen, dies 
explizit dazu zu schreiben. Echte Grobheiten sind jedoch klar 
zurückzuweisen.
** *Gesicht*: Verwende deinen Screen-Namen konsistent überall, wo du 
schreibst: Mails, Chats, Wikis etc. Verwende deinen Klarnamen, oder 
wenn Anonymität erforderlich ist, verwende konsistent einen echt 
klingenden Aliasnamen -- es ist dein Gesicht im Netz. Die Verwendung 
von Titeln wie Dr. oder Prof. in einer Diskussion wirkt ausschließend 
und drückt eher Unsicherheit aus. Es geht um den Respekt der Person, 
nicht des Titels. Signaturen am Ende einer Mail sollten möglichst kurz 
und unaufdringlich sein. Auf sie ganz zu verzichten, ist auch nicht 
verkehrt.

Fogel befasst sich ausführlich mit Fallstricken:

** *Schreibe nicht ohne Zweck*: Du must nicht auf alles antworten. Es 
gibt jedoch zwei gute Gründe zu schreiben: Du erkennst einen Fehler in 
einem Vorschlag, den niemand anderes wahrnimmt; du beobachtest eine 
Misskommunikation zwischen anderen und kannst das klären.
** *Produktive vs. unproduktive Diskussionen*: Wenn sich Inhalte 
wiederholen oder die Diskussion ins Allgemeine abdriftet, dann sinkt -- 
technisch ausgedrückt -- die Signal-Rausch-Rate. Auch hier ist es 
wichtig, wie du intervenierst: Schiebst du irgendwem die Schuld zu 
(oder allgemein den anderen) und beschwerst dich oder beschreibst du 
unter Verwendung einer einschließenden "wir"-Formulierung den Stand und 
machst Vorschläge zum weiteren Vorgehen (»Hier stehen wir, und das 
können wir tun«).
** *Umso softer das Thema, desto länger die Debatte*: Nicht-technische 
Debatten (Organisation, Veröffentlichungen etc.) können ausufern, weil 
hier jede/r eine Meinung beitragen kann. Die Beobachtung, dass sich die 
Intensität der Debatte umgekehrt proportional zur Komplexität des 
Themas verhält, ist als Fahrradschuppen-Effekt 
[http://producingoss.com/html-chunk/bikeshed-full.html] in die 
Literatur eingegangen. Das beste, was man hier tun kann, ist auf eben 
diesen Effekt aufmerksam zu machen, ganz sind 
jedoch »Fahrradschuppen-Anstreich-Parties« nicht zu vermeiden.
** *Vermeide »heilige Kriege«*: Beim »heiligen Krieg« verhält es sich 
ähnlich wie bei Diskussionen um die Farbe des Fahrradschuppens. Der 
Unterschied ist jedoch die persönliche Intensität, die mit solchen 
Debatten verbunden wird. Verständnis für eine andere Position wird hier 
als Schwäche interpretiert. Das beste ist, Themen für »heilige Kriege« 
vorab zu minimieren (Lizenzen etc.). Ist er einmal entbrannt, kann man 
öffentlich die Debatte verlassen, am besten jedoch ohne Bitterkeit oder 
Unterstützung einer Position.
** *Der »geräuschvolle Minderheiten« Effekt*: Eine Minderheitenposition 
kann versuchen, durch viele und längliche Mails einen großen Raum in 
einer Mailingliste einzunehmen, um auf diese Weise ihrer Position 
Gewicht zu verschaffen. Hier hilft oft nur, die wirkliche Anzahl der 
Unterstützer zu bestimmen und zu dokumentieren.

Einen relativ großen Raum nimmt der Abschnitt über »schwierige Leute« 
ein. Das sind für Fogel nicht einfach »grobe« Leute, zu deren 
Grobheiten man sich klar zurückweisen könne, sondern Menschen, die auf 
verschiedene Weise die Projektziele unterlaufen und zerstören. Solcher 
Art von Obstruktion [http://de.wikipedia.org/wiki/Obstruktion] ist 
nicht so einfach zu begegnen, da meistens reale Schwachpunkte des 
Projektes Ansatzpunkte für die Obstruktion sind. Fogel nimmt an, dass 
solche Leute nicht bewusst ein Projekt zestören wollen, sondern das ein 
obstruktives Verhalten aus einer individuellen Wahrnehmung von 
Ausgeschlossensein bis hin zu paranoiden Formen der Verschwörung gegen 
sich resultiert.

Ein Reaktion darauf ist schwierig. Toleranz gegenüber solchem Verhalten 
ist für eine gewisse Zeit eine mögliche Reaktion. Wenn sich aber nichts 
ändert, dann ist eine Intervention notwendig. Wer öffentlich 
interveniert, um Obstruktion entgegenzutreten, wird jedoch häufig 
selbst als destruktiv wahrgenommen und liefert weitere Munition für 
u.U. eine Verschärfung der Debatte. Lager können sich bilden, die 
Maßnahmen ablehnen oder befürworten etc.

Fogel gibt kein Patentrezept, sondern berichtet von einem Fall aus 
seiner Praxis. Hier war es so, dass eine Person durch extrem viele 
Mails auffiel, auf die andere sich genötigt sahen zu reagieren, was 
nicht nur von den Projektzielen ablenkte, sondern auch viel Zeit 
absorbierte. Gleichzeitig trug diese Person nichts praktisch bei (Code, 
Doku, Fixes, Reports etc.). Der Maintainer versicherte sich über 
Privatkontakte zunächst bei einer Reihe anderer aktiver 
Projektmitglieder, ob seine Wahrnehmung geteilt werde. Er erstellte 
eine Faktenliste (Anzahl der Mails von wem). Die Gruppe rief die 
betreffende Person an und forderte sie direkt auf, das Mailen 
einzustellen. Die Person sah die erläuterten Gründe nicht ein, folgte 
jedoch der Aufforderung. Die Mailingliste wurde wieder benutzbar.

   _Ein vergleichbarer Fall ereignete sich in der Oekonux
   [http://www.oekonux.de/]-Mailingliste. Auch hier verständigte sich
   eine aktive Gruppe auf Maßnahmen. Eine kollektive Moderation wurde
   beschlossen und umgesetzt. Destruktive Mails -- gleich von wem --
   wurden nun ausgefiltert. In der Folge ging jedoch insgesamt die
   Listenaktivität zurück. Damit wurde ein Argument der »schwierigen
   Person« bestätigt, dass die Liste ohne seine Beiträge nur eine leere
   Hülle sei. Eine kritische Projektsituation und obstruktives Verhalten
   überlagerten sich hier. Eine echte Lösung bot die Moderation nicht._

Die nächsten drei Unterabschnitte des Kapitels »Kommunikation« behandeln 
das Wachstum des Projektes, der Umgang mit Fehlerverfolgungssystemen 
(»Bugtracker«) und die Publikationspraxis (Releases, 
Sicherheitsverletzungen, Fehlerbereinigungen etc.). Zusammenfassend: 
Fogel empfiehlt Offenheit, Transparenz und Dokumentation als Leitlinie 
für eine gute Praxis. Er gibt viele praktische Tipps vom Format von 
Log-Einträgen in der Änderungsdatei bis hin zur Ankündigung von 
Patches. Die Details lasse ich hier weg.

*Management von Freiwilligen*

Es reicht nicht aus, eine gute Atmossphäre im Projekt zu haben, sondern 
es ist notwendig, dass sich jemand (eine/r oder mehrere) um die 
Freiwilligen kümmert. Fogel verwendet hierfür den Begriff »Management«, 
was auf Menschen angewendet (statt auf Prozesse) in meinen Ohren etwas 
befremdlich klingt. Der zweite auffällige Begriff ist der 
des »Politischen«. »Politisch« sind für Fogel alle nichttechnischen 
Resultate der Projektpraxis. Als Beispiel nennt er die Veränderung von 
Machtverhältnissen als Konsequenz bestimmter technischer 
Entscheidungen. Solche Konsequenzen müsse man stets im Blick haben. 
Gemeint ist der oder die Projektmanager/in (Maintainer).

Folgende Themen werden behandelt:

** *Delegation* ist primär ein soziales und politisches Werkzeug. 
Delegieren bedeutet, Vertrauen zu geben. Fogel diskutiert den 
Unterschied zwischen Anfrage und Beauftragung. Eine willkürliche 
Beauftragung ist nicht möglich. Es gibt jedoch eine kolletiv 
nachvollziehbare Erwartung, dass bestimmte Personen eine Aufgabe 
übernehmen. Als Beispiel nennt Fogel das Beheben eines Problems in 
einem Stück Code durch den Autor. Solche Erwartungen müssen offen 
kommuniziert werden. Wenn man jemanden gefragt hat, ob er/sie die 
Aufgabe übernimmt, ist es wichtig, nach einiger Zeit nachzuhaken. Der 
Zweck ist nicht, Druck auszuüben, sondern zu zeigen, dass man auf die 
Reaktionen achtet und wahrnimmt, was geschieht.
** *Lob und Kritik* sind keine Gegensätze, sondern unterschiedliche 
Formen der Aufmerksamkeit. Die geeignete Form von Kritik ist die 
detaillierte und leidenschaftslose Kritik an der Sache -- niemals der 
Person. Lob sollte nicht alltäglichen Aktivitäten gelten, sondern 
besonderen Leistungen. Gleichwohl sollten alle Aktivitäten ein Feedback 
oder eine Bestätigung haben, damit klar ist, dass die Aktivität 
wahrgenommen wurde und nicht unterging.
** *Vermeiden von Territorialität* bedeutet zu verhindern, dass einzelne 
Personen Bereiche eines Projektes für sich reklamieren und dazu 
tendieren, andere von diesem Bereich fernzuhalten. Autorität für einen 
Bereich kann man sich nicht nehmen, sondern man erhält sie durch den 
Konsens und die Akzeptanz des Projektes auf der Basis von Kompetenz und 
Leistungen. Auch wenn die Kompetenz unbestritten vorhanden ist, dürfen 
andere nicht ausgeschlossen werden. Um Territorialkämpfe zu vermeiden, 
erlauben viele Projekte keine Entwicklernamen im Quellcode (dafür gibt 
es eine summarische Credits-Datei).
** Den *Automatisierungsgrad* möglichst hoch zu treiben, ist bei sich 
wiederholenden, deterministischen Aufgaben sinnvoll. Als Daumenregel 
gilt, dass sich eine Automatisierung lohnt, wenn der Aufwand für die 
Einrichtung der Automatisierung höchstens zehn Mal so groß ist wie die 
manuelle Ausführung (bei häufigen oder komplexen Aufgaben zwanzig Mal). 
Ein sehr wichtiger Bereich ist das automatische Testen, insbesondere 
Regressionstests [http://de.wikipedia.org/wiki/Regressionstest].
** *Behandle jeden Nutzer als potenziellen Freiwilligen*. Fogel wirbt in 
diesem Abschnitt für ein Einnehmen der Nutzerperspektive. Nutzer wissen 
in der Regel nicht, wie sie zum Beispiel einen Fehler mitteilen können 
und schreiben dann nur "läuft nicht". Er schlägt drei Botschaften vor, 
die eine Antwort enthalten sollte: (1) Du hast ein Problem, wir 
empfinden den Frust; (2) Beschreiben, welche Form der 
Fehlerdokumentation (kopieren der Fehlermeldung, Screenshot etc.) 
hilfreich wäre; (3) Hinweise geben, wo und wie Fehler in umfassender 
Form gemeldet werden können (Bugtracking 
[http://de.wikipedia.org/wiki/Bugtracking]-System).

Die nächsten Abschnitte, die ich überspringe, behandeln das Aufteilen 
des technischen Managements (Patch-, Übersetzungs-, Dokumentations-, 
Problem-, FAQ-Manager), Verändern von Rollen und Verantwortlichkeiten 
im Projekt, die Auswahl von Personen mit Commit-Rechten (Einspielen von 
Quellcode in die Versionsverwaltung) und Credits (Danksagungen). 
Letztes Thema in dieser Buchsprechung sind _Forks_.

Forks wurden bereits im Kontext der Projektstruktur genannt -- als 
Möglichkeit. Wie aber mit einem Fork umgehen, wenn er geschieht, oder 
gar: Wann sollte ein Fork initiiert werden? Fogel stellt zu Beginn 
klar: Die bloße Existenz eines Forks ist _nicht_ das Problem, das 
Problem ist der Verlust an Entwicklern und Nutzern. Von dort aus 
schlägt er eine offensive und konstruktive Umgehensweise mit Forks vor, 
wenn sie nicht mehr zu vermeiden sind:

** Stelle Entwickler nicht vor Entscheidungen für oder gegen den Fork 
bzw. das eigene Projekt.
** Sei so kooperativ wie möglich; drücke den Wunsch aus, so kompatibel 
wie möglich zu sein.
** Entferne keine Commit-Rechte von Entwicklern, die den Fork 
unterstützen -- sie können eine wichtige Brücke bilden.
** Biete den Forkern infrastrukturelle Unterstützung an (etwa eine Kopie 
der kompletten Versionshistorie).
** Frage, ob die Forker weitere Unterstützung brauchen und biete diese 
an.

Der Grund für diese -- unbedingt öffentlichen -- Angebote ist nicht, den 
Fork zu befördern, sondern die Entwickler durch nicht-rachsüchtiges 
Verhalten davon zu überzeugen, dass die eigene Projektlinie die sichere 
ist. Die Logik des Krieges, sich für eine Seite zu entscheiden, gilt 
für Freie Software nicht, denn es kommt darauf an, Entwickler davon zu 
überzeugen, in beiden Projekten mitzuarbeiten und für Kompatibilität zu 
sorgen. Das erhöht die Wahrscheinlichkeit, nützliche Features aus dem 
Fork in das eigene Projekt zu integrieren und ggf. später einmal wieder 
zu einem Projekt zu verschmelzen (Beispiel ist der GCC/EGCS-Fork 
[http://www.softpanorama.org/People/Stallman/history_of_gcc_development.shtml]).

Das eigene Initiieren eines Forks sollte die absolut letzte Möglichkeit 
darstellen und nicht als »extremistische Debattiertechnik -- Folge mir 
oder ich spalte das Projekt«  verwendet werden. Vor einem Fork gilt es, 
die Stimmung und aktuellen Kräfteverhältnisse im Projekt zu 
berücksichtigen. Ohne dass Fogel einen Begriff davon hätte, beschreibt 
er den Unterschied zwischen einem einfach und doppelt freien 
[http://www.oekonux.de/einfuehrung/kladde/default_8.html] 
Softwareprojekt: Zwar garantiere die Lizenz die Freiheit des Codes, 
aber dennoch kann eine Firma den maßgeblichen Einfluss im Projekt 
ausüben, wenn sie wichtige Entwickler für ihre Tätigkeit im Projekt 
bezahlt. Dann nutze es nichts, wenn die Entwickler zwar forken würden, 
diese Meinung aber zurückhalten, weil es nicht der Firmenpolitik 
entpricht.

Wenn alle Bedingungen gegeben sind und ein Fork wirklich mehr vermeidbar 
ist, dann lauten die Empfehlungen analog zur Anti-Fork-Position:

** Kündige den Fork in einem nichtfeindlichen Ton an.
** Begründe leidenschaftslos und sachlich, was dich zu diesem Schritt 
veranlasste.
** Verdeutliche, dass du den Code forkst und nicht den Namen -- wähle 
einen nicht mit dem ursprünglichen Projekt verwandten neuen Namen.
** Erleichtere den Entwickern den Einstieg in den Fork, in dem du allen 
bisherigen Committern automatisch Commit-Rechte gibst -- auch jenen, 
die sich öffentlich gegen den Fork aussprachen.
** Die Hauptbotschaft ist: Es gibt Unterschiede in den Auffassungen, 
doch es gibt keine Feinde, und jeder ist mit seinem Beitrag willkommen.

   _Hier fällt mir natürlich sofort ein Vergleich mit »Forks« in der
   linken politischen Szene ein. __Ohne Übertreibung kann ich wohl
   sagen, dass die Linke komplett unfähig ist, mit »Forks« anders als
   destruktiv umzugehen. Mir ist noch die Krisis-Exit-Spaltung in
   Erinnerung. Alle »don't do that« sind hier versammelt: Mache den
   anderen nieder, schließe andere aus, schade den anderen so effektiv
   wie möglich, streite um den Namen, suche Schuldige, ziehe vor Gericht
   usw._

*Bewertung -- und was fehlt...*

In meiner Darstellung habe ich sicherlich viel ausführlichere 
Begründungen abgekürzt. Ich hoffe dennoch, dass ich die wesentlichen 
Punkte getroffen habe. Zielgruppe des Buches sind Maintainer von Freien 
Softwareprojekten. Fogel guckt auf die Handlungsmöglichkeiten aus ihrer 
Perspektive. Dadurch hatte die Darstellung nach meinem Gefühl  etwas 
Schlagseite, weil die komplexe Dynamik in sozialen Prozessen nur als 
Umgebung vorkam, die bearbeitet werden will -- nicht als Handlungsfeld, 
in dem ich mich als Maintainer bewege. Obwohl eigentlich klar ist, dass 
ich eigentlich gar nichts selbst auslösen kann -- etwa per Befehl wie 
in einem Unternehmen --, haben die Ratschläge trotzdem manchmal 
tendenziell diesen Charakter.

Das Genderthema wird nicht nicht angesprochen, obwohl es Fogel 
sprachlich durchaus berücksichtigt hat. So wie er zwischen »Open 
Source« und »Freier Software« einfach abwechselt, um hier einem Streit 
aus dem Weg zu gehen, so verwendet er im Wechsel »he« oder »she« im 
Text. Schade, ich unterstelle, dass Fogel auch hier explizit etwas zu 
sagen hätte.

Was auch fehlt, ist die Bedeutung von Real-Life-Events, also 
Konferenzen, Code-Sprints, Doc-Sprints, Workcamps etc. Aus meiner Sicht 
und Erfahrung sind solche Treffen für den sozialen Prozess in einer 
aktiven Community sehr wichtig.

Insgesamt ist es sehr empfehlenswert, das Buch zu lesen. Als physisches 
Ding kann man es von O'Reilly 
[http://www.oreilly.com/catalog/producingoss/] kaufen oder via Internet 
als PDF [http://producingoss.com/producingoss.pdf] herunterladen
oder online lesen [http://producingoss.com/html-chunk/index.html].

-- 
Start here: www.meretz.de



[English translation]
Thread: oxderawT00155 Message: 1/1 L0 [In date index] [In thread index]
Message 00155 [Homepage] [Navigation]