[ox-de-raw] keimform.de: Freie Software produzieren
- From: Stefan Meretz <stefan.meretz hbv.org>
- Date: Mon, 9 Apr 2007 17:43:49 +0200
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