deesaster.org

GNU/Linux als Kollektivgut ist das Thema der Arbeit der Soziologin Silvia Frank. In dem Buch soll der Frage nachgegangen werden, wie das Betriebssystem GNU/Linux bzw. Freie Software im Allgemeinen als Kollektivgut überhaupt entstehen kann und welche Faktoren die Entwicklung beeinflussen.

Um was geht's?

"Das Betriebssystem GNU/Linux - Entwicklung und Bereitstellung eines Kolletivguts auf Basis einer virtuellen Organisationstruktur" ... Dies ist der komplette Titel des vorliegenden Buches und schreckt Dank der vielen Wörter erst einmal ab. Dabei ist die Fragestellung ganz einfach:

Wie kommt es, dass so viele Menschen freiwillig an einem Projekt wie dem Linux-Kernel arbeiten ohne damit Geld verdienen zu wollen? Wie organisieren sich die Leute und warum bleiben sie am Ball?

Diese Frage will Silvia Frank auf soziologische Art und Weise in ihrem Buch nachgehen. Aus dem Grund sollte man an dieser Stelle auch eine kleine Warnung aussprechen: "Das Betriebssystem GNU/Linux" ist eine wissenschaftliche Arbeit - und dementsprechend liest sie sich auch. Keine Prosa, keine Ausschmückungen, einfach nur Fakten, Fakten, Fakten und viele Quellverweise.

Was steht drin?

Die Arbeit ist in vier Themenbereiche gegliedert. Zuerst wird eine Definition des Wortes "Kollektivgut" gegeben. Darunter versteht man (nach P. A. Samuelson) ein Gut, welches von allen genutzt werden kann (Nichtauschließbarkeit), ohne dass das Gut weniger wird bzw. der Gebrauch andere nicht negativ beeinflusst (Nichtteilbarkeit). Problematisch bei solchen Gütern sind sogenannte "Trittbrettfahrer". Darunter versteht man die Ausnutzung (nicht die reine Nutzung!) des Gutes von Personen, die nichts zu dessen Erstellung beigetragen haben. Vor allem steht laut einhelliger Forschermeinung das eigene Streben nach dem persönlichen Vorteil einer Entwicklung immer im Wege. Aus diesem Grund muss es Anreize und Faktoren geben, die eine Entwicklung des Gutes positiv beeinflussen.

In dem ersten Bereich wird dabei auch sehr ausführlich auf das Gruppenmodell von Mancur Olson eingegangen, welches aber bei genauer Betrachtung gar nicht auf Freie Software angewendet werden kann, da fast alle Theorien von Silvia Frank im weiteren Verlauf widerlegt werden. Andere Modelle kommen auch zur Sprache und finden eine bessere Anwendung.

Im zweiten und dritten Bereich wird auf die Forschungsfrage eingegangen, d.h. wieso Freie Software als Kollektivgut angesehen werden kann und wieso die herkömmlichen Störfaktoren die Entwicklung eines Projektes nicht negativ beeinflussen. Zusammenfassend gesagt gibt es zwei wichtige Punkte, die GNU/Linux fördern: Das Internet und die GPL. Das Internet dient als Kommunikationsmedium und gleichzeitig als Kontrollstruktur. Egal, wie groß die Gruppe ist, ein aktiver Beitrag (im Sinne einer Entwicklung oder eines Bugreports) geht nicht verloren. Im Gegenteil begünstigt eine große Gruppe sogar die Entwicklung Freier Software. Die GNU General Public License (GPL) dagegen sorgt dafür, dass es keine Trittbrettfahrer geben kann, da niemand die Software nehmen und zu seinem Vorteil einsetzen (sprich verkaufen) kann, ohne dass Veränderungen wieder der Gemeinschaft zugute kommen.

Um dies alles zu zeigen, wird auf die Eigenschaften Freier Software und wie diese entwickelt wird und natürlich auch auf die Eigenschaften der GPL eingegangen. Als selektive Anreize (d.h. positive Faktoren, die zur Mitarbeit an einem Projekt bewegen) zählen laut Silvia Frank:

• Reziprozität - Nach dem Leitspruch: Wenn ich helfe, wird mir (später) auch geholfen.
• Erkennbarkeit der eigenen Leistungen - Der eigene Beitrag wird dank Internet (immer) abrufbar sein und man wird durch die Nutzung einer Freien Lizenz wissen, wer einen Teil zu einem Projekt beigesteuert hat.
• Reputation - Ansehen in der Gemeinschaft und Erfahrungsgwinn für eine spätere Arbeitsstelle.
• Effizienz - Dies korelliert mit dem "Netzeffekt", der besagt, dass wenn ein Gut häufig gebraucht wird, es automatisch mehr Leute anzieht.
• Bedarf - Oft beteiligt man sich an einem Projekt, weil man ein Problem hat, was man gelöst haben will.
• Identifikation - Man sieht das Ziel der Gruppe als erstrebenswert an und stellt seine eigenen Bedürfnisse hinten an (bzw. stimmen diese in den meisten Fällen mit denen der Gruppe überein).

In dem Kapitel wird auch ein spieltheoretische Ansatz erläutert, denn die Arbeit an einem Softwareprojekt kann man als n-Personenspiel betrachten. Nur wenn die Kosten für jeden niedriger sind als der Gewinn, wird eine Person sich entscheiden zu kooperieren, d.h. mitzuhelfen. Freie Software sorgt durch die obige Anreize für ein positives Kosten-Nutzen-Verhältnis, sodass viele Personen freiwillig daran mitarbeiten.

Den Abschluss des dritten Bereichs bildet die Überprüfung der gestellten Thesen anhand zweier Freier Softwareprojekte: Zum einen KDE und zum anderen dem Apache-Server. Bei beiden Projekten wird ausführlich erklärt, wie diese entstanden sind und sich entwickeln. Und natürlich werden die Thesen überprüft und bestätigt.

Der vierte Abschnitt beschäftigt sich dann mit der Frage, wie und wieso Firmen Freie Software einsetzen (können). Es werden die verschiedenen Geschäftsmodelle erläutert, die Freie Software bietet:

• Vertrieb, Dokumentation und Schulung
• Support (in Form von Programmiertätigkeiten)
• Embedded Systems bzw. Einsatz in Hardware im Allgemeinen

Anhand jeden Themas wird eine Firma vorgestellt, die dies umsetzt und erfolgreich nutzt, um im Markt zu bestehen.

Wie liest es sich?

Der erste Abschnitt ist extrem theoretisch und stößt wahrscheinlich nur bei Soziologen und Spieltheoretikern auf Interesse. Sicherlich ist es gut zu erfahren, welche Definitionen es für Kollektivgüter alles gibt und wie diese positiv und negativ beeinflusst werden können. Für Nicht-Fachleute ist das Thema aber sehr trocken und man muss sich manchmal durch die vielen Zitate und Quellnachweise kämpfen.

Der zweite Abschnitt, wo konkret auf Freie Software und die GPL eingegangen wird, liest sich da schon wesentlich interessanter, da sich die meisten Leser dieses Buches in diesem Metrier bewegen und auskennen. Zusätzlich ist der Stoff nicht ganz so trocken und bekannte Personen wie Linus Torvalds, Richard Stallmann oder Eric S. Raymond sind den meisten Lesern eher ein Begriff als die Namen der ganzen auftretenden Soziologen.

Mir hat zudem der praktische Abschnitt zur Spieletheorie und dem Gefangenendilemma gefallen. Ingesamt ist der Teil recht interessant und wer den Film "A Beautiful Mind" gesehen hat, wird zumindest auch einmal vom Nash-Gleichgewicht gehört haben.

Die Vorstellung der beiden bekannten Projekte KDE und Apache ist auch interessant, da die Entstehungsgeschichte grundverschieden ist, der Ablauf der Entwicklung aber sehr ähnlich. Den vierten Teil mit dem Einsatz Freier Software in Firmen war wiederum etwas länglich und nicht ganz so interessant.

Kritik

Nachdem auf den Inhalt und das allgemeine Leseempfinden eingegangen wurde, folgt hier nun die harte Kritik.

Noch nie habe ich in einem gedruckten Werk so viele Fehler gesehen. Damit sind unter anderem Rechtschreib- und Grammatikfehler gemeint. Es gibt in dieser Arbeit keine fehlerfreie Seite. Enweder sitzen Kommata an völlig falschen Positionen im Satz oder fehlen ganz. Verschiedene Wörter sind regelmäßig falsch geschrieben - gute Beispiele sind "Email" (Email ist eine farbige Überzug auf Metallgegenständen, E-Mail dagegen ist der elektronische Brief) und "Standart" (es ist nicht die Art zu Stehen gemeint und das kleine Fähnchen vorne am Auto von Politikern heißt Standarte, die gemeinte Norm dagegen bezeichnet man als "Standard"). Das sind aber Fehler, die viele Menschen machen. Spätestens aber, wenn von der Firma "Morzilla" die Rede ist (ja, die Firma mit dem Feuerfuchs und dem Donnervogel), kann man nur den Kopf schütteln. Vor allem englische Begriffe liegen der Autorin definitiv nicht. Da ist die Einzahl von "Patches" schon mal "Patche".

Ich frage mich aber auch, ob der Verlag, der das Buch herausgegeben hat, nicht wenigstens einmal gegengelesen hat. Betrachtet man den Satz und das Layout des Werkes erübrigt sich die Frage aber. Ich bin unsicher, was jemanden dazu bewegt, komplett auf Worttrennung in einer Arbeit zu verzichten, aber das gibt demjenigen noch kein Recht, die Abstände zwischen den Worten in einem Satz nach Lust und Laune zu strecken und Bindestriche nach Gutdünken und nicht nach grammatikalischen Regeln zu setzen. Der Lesefluss gerät ständig ins Stocken, weil der Textsatz
einfach viel zu unruhig ist.

Dies war die Form, nun zum Stil und Inhalt, denn leider zeigt sich Silvia Franks Werk da nicht besser. Freie Software ist zwar keine Wissenschaft, dennoch sollten man die Regeln, wenn man über sie schreibt, korrekt widergeben. Sehr oft verallgemeinert die Autorin Aussagen und lässt wichtige Informationen weg. Hier ein paar Beispiele:

1. "Bei Open-Source-Software, also Software mit offenen Quellen, auch Freie Software genannt, hat jeder Zugang zum Quellcode ..." (S.3) - Das ist so nicht korrekt, auch wenn es in den meisten Fällen zutrifft. Dennoch kann man Freie Software verkaufen und muss den Quellcode nicht jedem, sondern nur dem Käufer frei zugänglich machen. Das ist ein bedeutender Unterschied, der sehr oft vergessen wird.
2. Den gleichen Fehler beschreibt Silvia Frank aber sehr oft und sagt beispielsweise auf Seite 5: "Wer GPL-Code für seine Programme nutzen will, muss diese wieder unter den Regeln der Lizenz veröffentlichen und ihren Source-Code frei zugänglich machen." Der Satz ist in dieser vereinfachten Form nicht richtig, vor allem nicht, wenn derjenige sein Projekt nur intern nutzt und sonst niemanden zur Verfügung stellt.
3. "Nicht zuletzt existiert kein streng vorgegebener Projektplan, kein Zeitplan und keine Termine für Veröffentlichungen." (S.44) - Im Vergleich zu proprietärer Software, wo ein zahlender Kunde auf das Produkt wartet, ist das sicherlich korrekt, aber es gibt natürlich Zeitpläne, an die sich auch meist gehalten wird. So bringt beispielsweise Canonical jedes halbe Jahr eine neue Version ihrer Distribution Ubuntu heraus. Bis auf einmal in 5 Jahren wurde der im Voraus festgelegte Releasetermin immer gehalten. Silvia Franks Aussage kann jedenfalls sehr schnell missverstanden werden als würden alle Freien Projekte nur nach dem Motto "It's done when it's done" arbeiten.
4. "Rechtlich wird die Freiheit der Software durch die General Public License (GPL), die allgemein gesagt das Gegenteil des Copyrights darstellt, abgesichert." (S.54) - Bei solch einer Aussage rauft sich wohl jeder GPL-Anhänger die Haare. Gemeint war wahrscheinlich, dass die GPL ein Copyleft und kein Copyright im herkömmlichen Sinne ist. Interessanterweise zitiert Silvia Frank einen Absatz davor eine Aussage der Free Software Foundationen, dass das Copyleft als Ableitung des Copyrights darstellt. Copyleft heißt also Copyright plus ein paar andere nette Dinge, die man machen darf.
5. "Allerdings besagt die Lizenz nicht, dass die Weiterverbreitung kostenlos zu geschehen hat. Für Dienstleistungen [...] ist die Erhebung einer Gebühr ausdrücklich erlaubt, nicht jedoch für die Software selbst." (S.55) - Auch hier ist die Autorin wahrscheinlich nur zu ungenau, was die Aussage dennoch falsch macht. Es gibt in der GPL keinen Abschnitt, der verbietet, dass man GPL-lizenzierte Software verkauft - und auch wirklich nur für die Software Tausende von Euro zahlen muss. Aber: Es ist nicht erlaubt, für den Quellcode, den der Käufer der Software auf Anfrage erhalten muss, extra Geld zu verlangen (abgesehen von Datenträgerkosten oder ähnlichem). Hier wurde also einfach nur keine Unterscheidung zwischen der Software und dem Quellcode dieser Software gemacht.
6. "Jedoch sei betont, dass komplexe Projekte zwar von einer Person initiiert werden können, finden sich jedenoch nicht schnell Mitentwickler stirbt das Projekt wieder - allerdings konnte ich bei meinen Recherchen kein Projekt finden, welches nach der aller ersten Veröffentlichung nicht von der "Entwicklergemeinde" aufgenommen wurde wäre." (S.82) - Hier hat Silvia Frank wohl nicht gut recherchiert. Es gibt zahlreiche ambitionierte größere Programme, die aufgrund fehlender Entwickler eingestellt wurden (bzw. seit Jahren nicht weiterentwicklt werden). So gut wie jede Community (egal, ob es um Freie Software geht oder nicht) kann davon ein Liedchen singen.
7. "Selbstverständlich gibt es bei Freier Software ebenfalls Updates, aber auf diese kann der Nutzer verzichten, durch die kontinuierliche Fehlerbereinigung auch von "alten" Versionen." (S.104) - Nur die wirklich großen Projekte pflegen alte Versionen und halte diese mit mit Sicherheitsupdates aktuell. Dennoch stirbt so ein alter "Branch" irgendwann und wird nicht ewig mit Updates versorgt. Kleinere Projekte dagegen haben sowieso nur einen Branch und entwickeln auf diesem einfach nur die neueste Version. Wer also einen Fehler bereinigt haben will, muss ein Update machen. Insofern ist die Aussage oben falsch.
8. In meinen Augen gab es bei der Intepretation der KDE-Entwicklung auch einen Fehler. Von KDE wurden innerhalb eines Jahres 11 Versionen veröffentlicht (Mai 2002 bis Mai 2003). Silvia Frank interpretiert das als Entwicklungsschub, da die Entwicklung davor langsamer vorwärts ging. Sicherlich war auch die Fleißigkeit der Entwickler entscheidend für diesen Releasezyklus, dennoch ist der Grund viel einfacher: Zu der Zeit stand ein neues Hauptrelease an, sodass neben der Hauptentwicklung von KDE 3.0.x auch die Alpha- und Beta-Versionen von KDE 3.1 veröffentlicht wurden. Nach der Veröffentlichung im Januar 2003 folgten dann nur noch regelmäßige Updates alle drei Monate für die neue Version. An dieser Häufung ist nichts Besonderes. Vergleicht man einer der großen Linux-Distributionen, sieht man im letzten Monat vor einem Release eine extreme Häufung von Veröffentlichungen. Das hat aber nur den Grund, die fertige Version stabil zu bekommen, sodass viele Leute vorab die Alpha- und Beta-Versionen testen können.

Schlussbemerkung

Was kann man abschließend sagen? Inhaltlich gibt es ein paar Ungenauigkeiten, die ein falsches Bild von Freier Software bei Nicht-Linux-Aktivisten prägen könnten. Für Nicht-Soziologen wiederum ist das Buch insgesamt zu theoretisch und man muss sich durchbeißen, auch wenn man nicht alles versteht. So versucht das Buch zwei Seiten zu bedienen, schafft es aber weder in die eine Richtung, sondern bleibt in der Mitte stehen. Daneben stören die vielen Fehler beim Lesen und unterbrechen ständig den Lesefluss, wenn einem wieder eine ungewohnte - weil falsche - Schreibweise ins Auge fällt.

Der soziologische Ansatz GNU/Linux und Freie Software im Allgemeinen als Kollektivgut anzusehen, ist definitiv interessant. Die Ausarbeitung von Silvia Frank halte ich aber nicht für gelungen. (Wobei nur der Inhalt gewertet wird, nicht der wissenschaftliche Hintergrund. Ob dieser falsch oder korrekt ist, muss ein Soziologe klären.)