Einleitung Die meisten freien Software-Projekte scheitern. Wir hören nicht viel über Fehlschäge. Nur erfolgreiche Projekte ziehen die Aufmerksamkeit auf sich, und es gibt insgesamt so viele Open-Source-Projekte Die beliebte Hosting-Seite SourceForge.net, verzeichnete mitte April 2004 79,225 Projekte. Natürlich ist das nicht einmal annähernd die Gesamtzahl der freien Software-Projekte im Internet, sondern lediglich die Teilmenge die Sourceforge als Plattform gewählt haben., dass obwohl nur ein Bruchteil Erfolg hat, immer noch eine Menge Projekte sichtbar sind. Von den Fehlschlägen hören wir auch deshalb nicht, weil Versagen kein Ereignis ist. Es gibt keinen bestimmten Zeitpunkt, an dem ein Projekt aufhört realisierbar zu sein; Teilnehmer gleiten irgendwie langsam davon und hören auf daran zu arbeiten. Es gibt vielleicht einen Moment an dem die letzte Änderung gemacht wird, aber derjenige der sie durchführt, weiß für gewöhnlich nicht, dass es die letzte sein wird. Es gibt nicht einmal eine klare Definition, wann ein Projekt abgelaufen ist. Ist es wenn an einem Projekt seit sechs Monaten nicht aktiv gearbeitet wurde? Sobald seine Nutzergemeinde aufhört zu wachsen, ohne die Entwicklergemeinde übertroffen zu haben? Was ist wenn die Entwickler ihr Projekt verlassen, sobald sie merken, dass ein anderes Projekt die gleichen Ziele verfolgt, und sie nur unnötig einen doppelten Aufwand betreiben, und sie sich diesem anderen Projekt anschließen und ihre früheren Anstrengungen mit einzubeziehen? Wurde das Projekt beendet, oder ist es nur umgezogen? Durch diese Komplexität ist es unmöglich die Ausfallquote genau zu beziffern. Einzelberichte aus über einem Jahrzehnt freier Software, kurzes Stöbern auf SourceForge.net und ein wenig Googeln, deuten jedoch alle auf den gleichen Schluss: die Rate ist extrem hoch, wahrscheinlich in der Größenordnung von 90%–95%. Die Zahl wird größer, wenn man überlebende aber nicht vernünftig laufende Projekte mit einbezieht: solche die zwar laufenden Code produzieren, aber weder ein angenehmer Aufenthaltsort sind, noch so schnell oder zuverlässig Fortschritte machen, wie sie könnten. In diesem Buch geht es darum, Versagen zu vermeiden. Es untersucht nicht nur wie man Sachen richtig macht, sondern wie man sie falsch macht, um frühzeitig Probleme erkennen und korrigieren zu können. Ich hoffe Ihnen zeigen zu können, wie man häufige Stolpersteine vermeidet, und erfolgreich Wachstum und der Pflege eines Projekts meistert. Erfolg ist kein Nullsummenspiel, und in diesem Buch geht es nicht darum zu Gewinnen oder der Konkurrenz voraus zu sein. Tatsächlich ist ein wichtiger Teil beim Betrieb eines Open-Source-Projekts die reibungslose Zusammenarbeit mit anderen verwandten Projekten. Auf lange Sicht, trägt jedes erfolgreiche Open-Source-Projekt zum Wohl der gesamten Welt der freien Software bei. Man ist versucht zu sagen, freie Software-Projekte würden aus den selben Gründen fehlschlagen, wie proprietäre Software-Projekte. Freie Software hat sicherlich kein Monopol auf unrealistische Anforderungen, vage Spezifikationen, schlechte Verwaltung von Ressourcen, zu kurze Entwurfsphasen, oder irgend einen der anderen Kobolde die der Software-Industrie bereits wohl bekannt sind. Es gibt genügend Material zu diesem Thema und ich werde in diesem Buch nicht versuchen es zu duplizieren. Statt dessen werde ich versuchen die Probleme zu beschreiben, die der freien Software eigen sind. Wenn ein freies Software-Projekt an die Wand gefahren wird, liegt es oft daran dass die Entwickler (oder die Projektleiter) nicht um die spezifischen Probleme von Open-Source-Software wussten, auch wenn sie durchaus auf die bekannteren Probleme der Closed-Source-Entwicklung vorbereitet waren. Einer der häufigsten Fehler sind unrealistische Erwartungen über die Vorteile von offenem Quellcode. Eine offene Lizenz garantiert weder, dass eine Horde aktiver Entwickler urplötzlich anfangen, von sich aus, Zeit in Ihr Projekt zu investieren, noch wird die Offenlegung die Krankheiten des Projekts automatisch heilen. Tatsächlich kann es sogar genau das Gegenteil bewirken: Es kann eine ganze Reihe neuer Komplexitäten hinzufügen, und kurzfristig mehr kosten als die Software einfach im Betrieb zu behalten. Das Projekt zu öffnen, bedeutet den Quellcode so zu gestalten, dass er für völlig Fremde verständlich ist, eine Site für Entwickler aufzubauen, Mailinglisten einzurichten und oft auch zum erstem mal eine Dokumentation zu schreiben. All das ist eine Menge Arbeit. Und falls interessierte Entwickler auftauchen, gibt es die zusätzliche Bürde, eine Zeit lang ihre Fragen beantworten zu müssen, bevor man aus ihrer Anwesenheit einen Nutzen zieht. Der Entwickler Jamie Zawinski hatte folgendes über die Anfangstage des Mozilla Projekts zu sagen:
Open Source funktioniert schon, aber es ist sicherlich kein Allheilmittel. Falls es hier eine warnende Lehre gibt, dann die, dass man ein sterbendes Projekt nicht einfach mit dem magischen Elfenstaub des "Open Source" bestreuen kann, und danach alles wie von selbst läuft. Die Probleme sind nicht so einfach. (aus )
Ein verwandter Fehler ist an Aufmachung und Präsentation zu sparen, in der Annahme, dass diese Sachen auch später erledigt werden können, sobald das Projekt erst einmal läuft. Aufmachung und Präsentation umfasst eine weite Reihe von Aufgaben, die sich alle um das Thema drehen, die Einstiegshürden niedriger zu legen. Das Projekt für Außenstehende einladend zu machen bedeutet, Anleitungen für Nutzer und Entwickler zu schreiben, eine Webseite aufzubauen, die für Neuankömmlinge informativ ist, möglichst viele der Kompilierungs- und Installationsvorgänge der Software zu automatisieren, usw. Viele Entwickler behandeln diese Aufgaben leider so als wären sie nur von zweitrangiger Bedeutung im Verhältnis zum eigentlichen Quellcode. Es gibt hierfür ein paar Gründe. Erstens, kann es einem wie Fleißarbeit vorkommen, denn die Vorteile sind zumeist nur für diejenigen sichtbar, die noch am wenigsten mit dem Projekt zu tun haben und umgekehrt. Schließlich kann jemand, der bereits mit dem Projekt vertraut ist, auf diese ganze Aufmachung verzichten. Er weiß schon, wie man die Software installiert, administriert und benutzt, schließlich hat er sie ja entwickelt. Zweitens sind die Fähigkeiten, die Aufmachung und Präsentation vernünftig zu gestalten, andere als solche die man benötigt um Quellcode zu schreiben. Menschen neigen dazu, sich auf das zu konzentrieren, was sie gut können, selbst wenn es für das Projekt besser wäre, ein wenig Zeit in etwas zu investieren, was ihnen weniger liegt. behandelt Aufmachung und Präsentation im Detail, und erklärt warum es entscheidend ist, dass sie gleich von Anfang an Priorität haben sollte. Der nächste Trugschluss ist, dass bei freier Software wenig bis gar kein Projektmanagement erforderlich ist, bzw. umgekehrt, dass die selben Management-Verfahren, die für die Entwicklung im Betrieb benutzt werden, sich genau so gut auf ein Open-Source-Projekt anwenden lassen. Die Verwaltung ist bei einem Open-Source-Projekt, nicht immer besonders offensichtlich, aber bei erfolgreichen Projekten, gibt es sie in irgend einer Form im Hintergrund. Ein kleines Gedankenexperiment reicht um die Gründe dafür zu zeigen. Ein Open-Source-Projekt besteht aus einem zufällig zusammengewürfeltem Haufen von Programmierern – bereits an und für sich notorisch eigensinnige Leute –, von denen untereinander wahrscheinlich keiner einem andere je begegnet ist, und von denen jeder u.U. unterschiedliche eigene persönliche Ziele verfolgt. Das Gedankenexperiment ist einfach: Stellen Sie sich vor, was mit einer solchen Gruppe passieren würde, ohne eine Verwaltung. Wenn kein Wunder geschieht, würden sie sehr schnell auseinander gehen. Auch wenn wir es uns anders wünschen, läuft das Ganze nicht einfach von alleine. Die Verwaltung ist aber, wenn auch ziemlich aktiv, meistens informell, subtil und unauffällig. Das einzige was die Entwickler zusammenhält ist, dass sie zusammen mehr erreichen können, als jeder für sich. Deshalb muss die Aufgabe einer Verwaltung hauptsächlich darin bestehen, sie weiterhin daran glauben zu lassen, indem sie Richtlinien für die Kommunikation festlegt, dafür sorgt, dass brauchbare Entwickler nicht aufgrund persönlicher Eigenheiten an den Rand gedrängt werden, und allgemein das Projekt als einen Ort zu gestalten, an den Entwickler gern zurückkehren. Im Verlauf des Buchs soll gezeigt werden, wie man diese Ziele erreicht. Schließlich gibt es eine generelle Problematik, die man als "Versagen kultureller Navigation" bezeichnen könnte. Vor zehn, vielleicht auch nur fünf Jahren, hätte es als voreilig gegolten, von einer globalen Kultur der freien Software zu reden, heute jedoch nicht. Eine erkennbare Kultur ist langsam gewachsen, und obwohl sie sicherlich nicht monolitisch ist – sie ist mindestens so anfällig für interne Meinungsverschiedenheiten und Parteigeist wie irgend eine geographisch gebundene Kultur – hat sie doch einen im Grunde genommen beständigen Kern. Die meisten erfolgreichen Open-Source-Projekte, zeigen alle, oder zumindest einen großen Teil der Merkmale von diesem Kern. Sie belohnen bestimmte Verhaltensmuster und bestrafen andere; sie schaffen eine Atmosphäre, die spontane Beteiligung fördert, manchmal auf kosten zentraler Koordination; sie haben Konzepte von Unhöflichkeit und gutes Benehmen, die von den anderswo vorherrschenden erheblich abweichen können. Vielleicht am wichtigsten, sind die erfahrenen Teilnehmer die diese Konzepte meistens verinnerlicht haben, sodass sie einen groben Konsens über das zu erwartenden Benehmen teilen. Nicht erfolgreiche Projekte weichen für gewöhnlich wesentlich von diesen Kern ab, wenn auch unabsichtlich, und haben oft keinen Konsens darüber, welches Benehmen als angemessen einzustufen ist. Das hat zur folge, dass sobald Probleme auftreten, die Situation schnell eskalieren kann, da den Teilnehmern ein etablierter Grundbestand kultureller Reflexe fehlt, um Meinungsverschiedenheiten zu klären. Dieses Buch ist ein praktischer Führer, keine anthropologische Studie oder Historie. Grundkenntnisse über die Herkunft der Kultur der freien Software sind dennoch, eine erforderliche Grundlage bei jedem praktischen Ratschlag. Jemand der die Kultur versteht, kann weit und breit in der Open-Source-Welt reisen, viele lokale Unterschiede in den Gebräuchen und Dialekten begegnen, und trotzdem in der Lage sein, sich überall bequem und effektiv zu beteiligen. Im Gegensatz dazu, wird eine Person ohne Verständnis für die Kultur, die Organisation- und die Art sich an einem Projekt zu beteiligen, die Bräuche als schwierig und voller Überraschungen empfinden. Da die Anzahl der Menschen die freie Software entwickeln immer noch stark ansteigt, gibt es viele in der letzten Kategorie – diese sind zum größten Teil vor kurzem Eingewandert und das wird auch eine Weile lang so bleiben. Wenn Sie meinen vielleicht eine von ihnen zu sein, gibt der nächste Abschnitt einen Hintergrund für spätere Diskussionen, sowohl im Buch als auch im Internet. (Wenn Sie andererseits bereits eine Weile lang mit Open Source arbeiten, und u.U. bereits eine Menge seiner Geschichte kennen, können Sie den nächsten Abschnitt getrost überspringen.) Die Geschichte Software wurde schon immer an andere weitergegeben und miteinander geteilt. In den frühen Tagen der Computerindustrie, waren Hersteller der Meinung, vor allem durch Innovationen in der Hardware Wettbewerbsvorteile zu erreichen, und schenkten der Software als Vorteil gegenüber der Konkurrenz wenig Aufmerksamkeit. Viele Kunden dieser frühen Maschinen waren Wissenschaftler oder Techniker, die in der Lage waren, die Software die mit der Maschine selbst ausgeliefert wurde, selbst zu verändern und zu erweitern. Kunden gaben ihre Verbesserungen nicht nur an den Hersteller zurück, sondern teilten es manchmal auch mit den Besitzern ähnlicher Maschinen. Dem Hersteller war das nur recht, ermutigten sogar dazu: aus ihrer Sicht, machte jede Verbesserung an der Software, egal aus welcher Quelle, ihre Maschine attraktiver für andere potenzielle Kunden. Obwohl diese frühe Zeit in vielerlei Hinsicht der heutigen freien Software-Kultur ähnelte, gab es zwei wesentliche Unterschiede. Erstens, gab es noch kaum standardisierte Hardware – es war eine Zeit florierender Innovationen bei den Architekturen in Computern, aber diese Vielfalt bedeutete, dass alles inkompatible zu einander war. Deshalb lief Software die für eine Maschine geschrieben wurde, im allgemeinen auf keiner anderen. Programmierer eigneten sich im allgemeinen Fachkenntnisse zu einer bestimmten Architektur oder Familie von Architekturen an (im Gegensatz dazu, würden sie heute eher Fachkenntnisse in einer Programmiersprache oder Familie von Programmiersprachen sammeln, mit der Zuversicht, dass ihre Kenntnisse, auf welche Hardware sie auch arbeiten mögen, übertragbar wären). Weil die Erfahrungen einer Person dazu neigten sich auf einen Computer zu beschränken, hatte die Aneignung von Erfahrung die Folge, diesen Computer für sie und ihre Kollegen attraktiver zu machen. Deshalb war es im Interesse des Herstellers, dass Wissen und Code, spezifisch zu ihren Maschinen sich so weit wie möglich verbreitete. Zweitens, gab es kein Internet. Obwohl es weniger rechtliche Einschränkungen gab als heute, die den Austauschen von Software verhinderten, gab es mehr technische: Es gab ein ein paar wenige, lokale Netzwerke, die gut waren um Informationen unter Mitarbeiter der gleichen Forschungseinrichtung auszutauschen. Aber es blieben Barrieren die es zu überwinden galt, wenn man mit jedem teilen wollte, unabhängig von seinem Standort. Diese Barrieren wurden in vielen Fällen überwunden. Manchmal stellten verschiedene Gruppen eigenständig Kontakt zueinander her. Sie sandten einander Disketten oder Magnetbänder mittels Post zu und manchmal fungierten die Hersteller selbst als zentrale Anlaufstelle für Patches. Es half auch, dass viele frühe Computer-Entwickler an Universitäten arbeiteten, wo die Veröffentlichung des eigenen Wissens erwartet wurde. Die physische Realit der Datenübertragung bedeutete jedoch, dass der Austauschen immer einen Widerstand mit sich brachte, der proportional zur Entfernung (echte oder organisatorische) anwuchs, die von der Software überwunden werden musste. Weitverbreitetes reibungsloses Tauschen, wie wir sie heute erleben, war nicht möglich. Der Aufstieg proprietärer und freier Software Mit der Reifung der Industrie ergaben sich mehrere zusammenhängende Veränderungen. Der Wildwuchs bei den Hardware-Architekturen konsolidierte sich auf einige wenige Gewinner – Gewinner durch überlegene Technologie, überlegenes Marketing, oder eine Kombination beider. Gleichzeitig, und nicht ganz zufällig, hatte die Entwicklung sogenannter "höherer" Programmiersprachen zur Folge, dass man Anwendungen in einer Sprache schreiben konnte, und es automatisch übersetzen ("Kompilieren") lassen konnte, sodass es auf viele verschiedene Computer laufen konnte. Die Folgen hiervon blieben den Hardware-Herstellern nicht verborgen: Ein Kunde konnte jetzt ein großes Software-Projekte in Angriff nehmen, ohne sich auf eine bestimmte Computer-Architektur festzulegen. Diese Tatsache zusammen mit den allmählich keiner werden Unterschieden zwischen den verschiedenen Marken, da weniger effiziente Architekturen ausgelesen wurden, zwang Hersteller die ihre Hardware als seine einziges Gut behandelten, sich auf sinkende Gewinnmargen einzustellen. Rohe Rechenleistung wurde ein ersetzbares Gut, während Software zum Unterscheidungsmerkmal wurde. Software zu verkaufen, oder zumindest es als integrierten Bestandteil der Hardware zu verkaufen, wurde zu einer verlockenden Strategie. Hersteller fingen also an, die Urheberrechte auf ihren Quellcode strenger durchzusetzen. Wenn Nutzer einfach weiterhin frei miteinander Code tauschen und modifizieren konnten, würden sie vielleicht manche der Verbesserungen eigenständig neu implementieren, die der Hersteller als "Mehrwert" verkaufen wollte. Schlimmer noch, getauschter Quellcode könnte in an die Konkurrenz gelangen. Ironisch dabei ist, dass all das zur selben Zeit geschah, als das Internet endlich anfing abzuheben. Gerade als der echte reibungslose Austausch von Software, endlich technisch machbar wurde, machten Veränderungen in der Computerindustrie, es wirtschaftlich nicht wünschenswert, zumindest aus Sicht der einzelnen Unternehmen. Die Hersteller wurden restriktiver, entweder verwehrten Sie den Nutzern den Zugriff auf den Quellcode der auf ihren Maschinen lief, oder sie bestanden auf Vertraulichkeitsvereinbarungen, die das Tauschen praktisch unmöglich machten. Bewusster Widerstand Langsam ließ der unbeschränkte Austauschen von Quellcode in der überall in der Softwareindustrie nach. Überall? Zumindest im Kopf von einem Programmierer, kristallisierte eine Gegenreaktion. Richard Stallman arbeitete im Labor für künstliche Intelligenz am Massachusetts Institute of Technology in den 1970ern und frühen '80ern. Es sollte sich herausstellen, dass dies die goldene Zeit und der goldene Ort für den freien Austausch von Quellcode war. Das KI-Labor hatte eine starke "Hacker-Ethik", Stallman benutzt das Wort "Hacker" im ursprünglichen Sinne von "Jemand der es liebt zu Programmieren und Spaß daran hat sich dabei geschickt anzustellen", nicht im Sinne der relativ neuen Bedeutung von "Jemand der in Computer einbricht". und Leute wurden nicht nur dazu ermutigt sondern es wurde von ihnen erwartet, alle Verbesserungen am System mit Anderen zu teilen. Stallman schrieb später:
Wir nannten unsere Software nicht "freie Software" weil es diesen Begriff noch nicht gab; aber genau das war es. Immer als Leute von anderen Universitäten oder Firmen eine Anwendung benutzen und portieren wollte, konnten sie das gerne machen. Wenn du jemand bei der Nutzung einer unbekannte und interessanten Anwendung gesehen hast, konntest du immer darum bitten dir den Quellcode anzuschauen, um es zu lesen, zu verändern oder Teile davon für eine neue Anwendung auszuschlachten. (von )
Die Edenische Gemeinschaft um Stallman herum, brach kurz nach 1980 zusammen, als die Veränderungen der restliche Industrie, letztendlich das KI-Labor einholten. Eine Startup-Firma stellte viele Programmierer des Labors ein, um an einem Betriebssystem zu arbeiten, ähnlich zu dem welches sie im Labor programmiert hatten, diesmal aber unter einer exklusiven Lizenz. Gleichzeitig, schaffte sich das KI-Labor neue Ausrüstung an, welches mit einem proprietären Betriebssystem ausgeliefert wurde. Stallman sah in den Geschehnissen das größere Muster:
Die modernen Computer dieser Ära, wie z.B. der VAX oder die 68020, hatten ihre eigenen Betriebssysteme, aber keines davon war freie Software: Man musste eine Vertraulichkeitsvereinbarung unterschreiben, nur um eine ausführbare Kopie zu bekommen. Um einen neuen Computer zu nutzen, musste man also als allererstes versprechen, seinen eigenen Nachbarn nicht zu helfen. Eine gemeinschaftliche Zusammenarbeit war verboten. Die Hersteller proprietärer Software stellten die Regel auf: "Wenn du mit deinem Nachbarn teilst, bist du ein Pirat. Wenn du irgendwelche Änderungen haben möchtest, dann musst du bei uns darum betteln.".
Stallman entschied sich aus irgend eine persönliche Eigenart heraus Widerstand gegen diese Entwicklung zu leisten. Anstatt für das nunmehr dezimierte KI-Labor weiterzuarbeiten, oder eine Arbeit bei einer der neuen Firmen anzunehmen, wo die Ergebnisse seiner Arbeit verschlossen in einer Kiste wären, kündigte er dem Labor und gründete das GNU Projekt und die Free Software Foundation (FSF). Das Ziel von GNU Abkürzung für "GNU's Not Unix", und das "GNU" in dieser Erweiterung steht für... dasselbe. war es ein komplett freies und offenes Betriebssystem und eine Reihe von Anwendungen zu entwickeln, die jedem Benutzer ermöglichen sollte an der Software zu hacken, sowie ihre Änderungen untereinander zu teilen. Im wesentlichen machte er sich auf dem Weg wiederherzustellen, was im KI-Labor zerstört wurde, aber auf einer Welt umspannenden Größenordnung und ohne die Schwachstellen welche die Kultur des KI-Labors verwundbar gemacht hatten. Zusätzlich zur Arbeit am neuen Betriebssystem, entwarf er eine urheberrechtliche Lizenz, deren Bedingungen garantierten, dass sein Code für immer frei bleiben würde. Die GNU General Public License (GPL) ist ein kleveres Stück juristisches Judo: Es besagt, dass Code ohne Einschränkungen kopiert und verändert werden darf, und dass sowohl Kopien als auch abgeleitete Werke (das heißt veränderte Versionen) unter derselben Lizenz wie das Original, ohne weitere Einschränkungen, freigegeben werden müssen. Tatsächlich, benutzt es das Urheberrecht um genau das Gegenteil zu erreichen wozu es üblicherweise benutzt wird: Anstatt die Verbreitung der Software einzuschränken, hindert es jeden, sogar den Autor, an seiner Einschränkung. Für Stallman war das besser als seinen Code einfach als öffentliches Gut freizugeben. Ohne eine Lizenz, könnte jede beliebige Kopie in eine proprietäre Anwendung aufgenommen werden (ein bekanntes Phänomen bei Code welches unter tolerante Lizenzen veröffentlicht wird). Obwohl solch eine Einbindung in keiner Weise die weitere Verfügbarkeit des Codes einschränken würde, könnten die Anstrengungen von Stallman dadurch dem Feind – Proprietäre Software – zum Vorteil gereichen. Die GPL kann man als ein Schutz für freie Software betrachten, da es nicht-freie Software daran hindert, seinen GPL Code komplett auszunutzen. Die GPL und ihre Beziehung zu anderen freien Software-Lizenzen werden im Kapitel ausführlich behandelt. Mit der Unterstützung vieler anderer Programmierer, Teils gleichgesinnte von Stallman, die seine Ideologie teilten sowie andere, die einfach nur möglichst viel freien Quellcode wollten, fing das GNU Projekt an freien Ersatz für viele der wichtigsten Komponenten eines Betriebssystems zu veröffentlichen. Die nunmehr weit verbreitete Standardisierung von Hardware und Software, erlaubte den Einsatz von GNU Software in ansonsten proprietäre Systeme, was von vielen gemacht wurde. Der GNU Text-Editor (Emacs) und C Compiler GCC fanden großen Anklang, nicht nur wegen der Ideologie, sondern einfach aufgrund ihrer technischen Vorzüge. Bis ca. 1990, hatte GNU den Großteil eines freien Betriebssystems fertiggestellt. Es fehlte noch ein Kernel – also die Software die beim Hochfahren geladen wird und für die Verwaltung von Arbeitsspeicher, Festplatten und anderen Ressourcen des Systems zuständig ist. Leider hatte das GNU Projekt eine Kernelstruktur gewählt, die schwieriger zu implementieren war, als sie es erwartet hatten. Die dadurch entstandene Verzögerung, hinderte die Free Software Foundation daran, die erste Veröffentlichung eines komplett freien Betriebssystems zu machen. Das letzte Stück wurde statt dessen von Linus Torvalds, einem finnischen Informatik-Studenten hervorgebracht, der mit der Hilfe von vielen Freiwilligen, verteilt auf der ganzen Welt, einen freien Kernel fertig gestellt hatte, der auf einem viel konservativerem Aufbau basierte. Er nannte es Linux, und als es mit den bereits existierenden GNU Anwendungen kombiniert wurde, war das Ergebnis ein komplett freies Betriebssystem. Zum ersten Mal konnte man seinen Computer ohne proprietäre Software hochfahren und damit arbeiten. Rein Technisch gesehen war Linux nicht das erste freie Betriebssystem sondern das kurz vorher erschienene 386BSD für IBM-kompatible Rechner. 386BSD war jedoch viel schwieriger zum laufen zu bringen. Linux machte solch einen guten Anfang, nicht nur weil es frei war, sondern weil man es auf seinen Computer tatsächliche zum laufen bringen konnte. Viel Software dieses neuen Betriebssystems wurde nicht vom GNU Projekt produziert. In der Tat war GNU nicht einmal die einzige Gruppe die daran arbeitete ein freies Betriebssystem herzustellen (ein Beispiel ist der Code der letztendlich in NetBSD und FreeBSD aufging, an dem zu dieser Zeit bereits entwickelt wurde). Die Free Software Foundation war nicht nur aufgrund des Codes, welches sie produzierten von Bedeutung, sondern auch wegen ihrer Rhetorik. Indem sie von freier Software eher als Glaubenssache sprachen wofür es sich zu kämpfen lohnt, und nicht als eine Sache der Bequemlichkeit, machten sie es für Programmierer schwierig nicht ein politisches Bewusstsein darüber zu haben. Selbst wenn man der FSF nicht zustimmte, mussten man sich mit dem Thema befassen, wenn auch nur um eine andere Position einzunehmen. Die Wirksamkeit der FSF als Propagandisten bestand darin, ihren Code mittels der GPL und anderer Texte an eine Botschaft zu binden. Zusammen mit der weiten Verbreitung ihres Codes, verbreitete sich auch ihre Botschaft. Zufälliger Widerstand Es gab jedoch viele andere Vorgänge in der aufkeimenden Szene der freien Software und wenige waren derart offen ideologisch wie das GNU Projekt von Stallman. Einer der wichtigsten war die Berkeley Software Distribution (BSD), eine schrittweise Neuimplementierung des Unix-Betriebssystems – welches bis in den späten 1970ern ein loses proprietäres Forschungsprojekt bei AT&T von Programmierern an der Universität von Kalifornien in Berkly gewesen war. Die BSD Gruppe machte keine offenkundige politische Äußerungen darüber, dass Programmierer sich verbünden und miteinander Teilen mussten, aber sie praktizierten die Idee mit Spürsinn und Enthusiasmus, indem sie eine massive verteilte Anstrengung koordinierten, bei dem Unix-Konsolen-Anwendungen, Code-Bibliotheken und schließlich das Betriebssystem selbst von Grund auf, größtenteils von Freiwilligen neu geschrieben wurde. Das BSD Projekt wurde zum Aushängeschild für Entwicklung freier Software ohne ideologischem Hintergrund und diente als Ausbildungsstätte für viele Entwickler die später in der Open-Source-Welt weiterhin aktiv bleiben sollten. Eine weitere Feuerprobe der kooperativen Entwicklung, war das X Window System, eine freie netzwerktransparente graphische EDV-Umgebung, welches Mitte der 1980er an dem MIT in Zusammenarbeit mit Hardware-Anbietern entwickelt wurde, die ein gemeinsames Interesse daran hatten ihren Kunden ein Fenstersystem anbieten zu können. Weit davon entfernt sich proprietärer Software entgegenzustellen, erlaubte die X Lizenz ganz bewusst proprietäre Erweiterungen auf seinem freien Kern – alle Beteiligten des Konsortiums wollten die Möglichkeit die übliche X Version zu verbessern und sich dadurch von den anderen Mitgliedern abzuheben. X Windows Sie bevorzugen den Namen "X Window System", aber für gewöhnlich nennt man es "X Windows", da drei Wörter einfach zu schwerfällig sind. selbst war freie Software, aber hauptsächlich als Mittel um das Spielfeld zwischen konkurierende wirtschaftliche Interessen zu ebnen, nicht als Wunsch die Vormacht proprietärer Software zu brechen. Ein weiteres Beispiel, dass dem GNU Projekt ein paar Jahre vorausging war TeX von Donald Knuth, ein freies Textsatzsystem für druckfertige Dokumente. Er veröffentlichte es unter einer Lizenz, welches jedem erlaubte es zu modifizieren und zu veröffentlichen, solange man das Ergebnis nicht "TeX" nannte, wenn es nicht einen strikten Satz an Prüfungen bestand, die Kompatibilität gewährleisten sollten (TeX ist ein Beispiel für eine Klasse von Lizenzen für freie Software die ein Markenzeichen schützen sollen, welches im Kapitel ausführlicher behandelt wird). Knuth bezog nicht Stellung für die eine oder andere Partei im Bezug auf die Frage freie gegen proprietäre Software, er brauchte nur ein besseres Textsatzsystem um sein echtes Ziel zu erreichen – ein Buch über Softwareentwicklung zu schreiben – und sah keinen Grund als er fertig war, sein System nicht der Welt zu veröffentlichen. Ohne hier jedes Projekt und jede Lizenz aufzulisten, kann man doch mit Sicherheit sagen, dass ende der 1980er eine Menge freie Software unter einer breiten Auswahl an Lizenzen zu Verfügung stand. Die Vielfalt an Lizenzen spiegelte eine entsprechende Vielfalt an Motivationen wider. Selbst einige der Programmierer welche die GNU GPL wählten waren viel weniger ideologisch getrieben als das GNU Projekt selbst. Obwohl sie es genossen an freie Software zu arbeiten, betrachteten viele Entwickler proprietäre Software, nicht als soziales Übel. Es gab Menschen die einen moralischen Drang spürten die Welt von "Software-Hortung" (der Begriff den Stallman für nicht freie Software benutzt) zu befreien, andere waren jedoch eher durch technische Begeisterung motiviert, durch die Freude an der Zusammenarbeit mit Gleichgesinnten, sogar durch das einfache menschliche Bedürfnis nach Ruhm. Dennoch beeinflussten sich diese ungleichen Motivationen größtenteils nicht negativ. Teilweise liegt das daran, dass Software im Gegensatz zu anderen kreativen Aktivitäten wie Prosa oder die Bildende Kunst einige mehr oder weniger objektive Prüfungen bestehen muss um als erfolgreich erachtet zu werden: Es muss Laufen und zu einem gewissen Maß frei von Fehlern sein. Dadurch haben alle Teilnehmer eines Projekts automatisch Grundlegende gemeinsame Interessen, eine Basis und ein Rahmenwerk um miteinander zu arbeiten, ohne allzuviele Sorgen um eine Qualifizierung außerhalb des technischen. Entwickler hatten noch einen Grund zusammenzuhalten: es stellte sich heraus, dass die Welt freier Software, Qualitativ sehr hochwertigen Code produzierte. Manchmal war es aus technischer Sicht, der nächst besten nicht-freien Alternative nachweislich überlegen; manchmal war es zumindest vergleichbar und natürlich kostete es weniger. Auch wenn nur wenige motiviert gewesen wären freie Software aus rein philosophischen Gründen zu nutzen, waren eine Viele mehr als glücklich sie wegen ihrer technischen Überlegenheit zu nutzen. Und von denen die es benutzten, war immer irgend ein Bruchteil bereit ihre Zeit und Fähigkeiten zu spenden, um bei der Pflege und Verbesserung der Software mitzuhelfen. Diese Tendenz guten Code zu produzieren war sicherlich nicht überall gegeben, aber bei freien Software-Projekten auf der ganzen Welt zunehmend oft der Fall. Geschäftszweige die zu einem gewichtigen Teil von Software abhingen, fingen langsam an davon Wind zu bekommen. Viele bemerkten, dass in ihren Betrieben bereits jeden Tag freie Software eingesetzt wurde, ohne es gewusst zu haben (die Geschäftsleitung wird nicht immer über alles informiert, was sich in der IT Abteilung abspielt). Firmen fingen an eine aktivere Rollen bei freie Software-Projekte einzunehmen, manchmal trugen sie mit Zeit und Ausrüstung bei, manchmal auch direkt durch finanzielle Unterstützung der Entwicklung freier Software-Anwendungen. Solche Investitionen konnten sich im Idealfall, um ein Vielfaches auszahlen. Der Geldgeber stellt lediglich eine kleine Gruppe erfahrener Entwickler ein, die sich ganztags einem Projekt widmen, profitiert aber von den Beiträgen aller Beteiligten, also auch von unbezahlte Freiwillige und Programmierer anderer Unternehmen. "Frei" kontra "Open Source" Mit zunehmender Aufmerksamkeit aus der Unternehmenswelt, wurden Programmierer freier Software mit Fragen der Präsentation konfrontiert. Eines war das Wort "Frei"Anm. d. Übersetzer Das Wort "frei" wird hier für das englische Wort "free" benutzt. Es hat eine ähnliche Doppeldeutigkeit wie im Englischen, auch wenn man im deutschen zur besseren Unterscheidung den Begriff "kostenlos" verwenden kann was im englischen nicht so leicht möglich ist. selbst. Wenn man den Begriff "freie software" zum ersten mal hört, denken viele es bedeutet lediglich "gratis Software". Es stimmt zwar, dass freie Software auch kostenlos istMan kann eine Gebühr für die Aushändigung von Kopien freier Software verlangen, da man aber den Empfänger nicht daran hindern kann es danach kostenlos weiterzugeben, läuft der Preis effektiv sofort gegen null, aber nicht jede Software die nichts kostet, ist auch frei. Ein Beispiel sind die Browser-Kriege der 1990er, indem sowohl Netscape als auch Microsoft ihre konkurierenden Browser kostenlos anboten, um eilig einen möglichst großen Marktanteil zu erlangen. Keiner von ihnen war jedoch frei im sinne "freier Software". Man hatte keinen Zugriff auf den Quellcode und selbst wenn, hätte man nicht die Rechte ihn zu modifizieren und weiterzugebenDer Quellcode vom Netscape Navigator wurde letztendlich 1998 unter einer Open-Source-Lizenz gestellt, und wurde zur Grundlage für den Mozilla-Browser. Siehe .. Man konnte lediglich eine Ausführbare Datei herunterladen und laufen lassen. Die Browser waren nicht freier als eingeschweißte Software aus dem Geschäft; sie waren lediglich etwas günstiger. Die Verwirrung um das Wort "frei" ist einer ganz und gar unglücklichen Doppeldeutigkeit der Englischen Sprache zuzuschreiben. Die meisten anderen Sprachen unterscheiden zwischen einem niedrigen Preis und Freiheit (die Unterscheidung zwischen gratis und libre leuchtet den meisten Sprechern romanischer Sprachen sofort ein). Die Stellung der Englischen Sprache als de-facto Brückensprache des Internets, hat zur Folge, dass dieses Problem im Englischen zu einem gewissen Grad, ein Problem aller ist. Die Missverständnisse um das Wort "free" waren so verbreitet, dass die Programmierer freier Software schließlich eine Standard-Formulierung als Reaktion parat hielten: "Es ist frei im Sinne von Freiheit – denke an die Redefreiheit, nicht an Freibier."engl.: "It's free as in freedom—think free speech, not free beer.". Diese Erklärung dauernd wiederholen zu müssen ist aber auf Dauer ermüdend. Viele Programmierer fühlten teils zurecht, dass die Zweideutigkeit des Worts "frei" das Verständnis in der Öffentlichkeit behinderte. Das Problem war aber viel schwerwiegender. Das Wort "frei" trug eine unausweichliche moralische Konnotation: Wenn die Freiheit ein Ziel für sich war, dann machte es keinen Unterschied ob die Software zufällig auch besser oder unter bestimmten Bedingungen auch für bestimmte Geschäfte profitabler war. Das waren lediglich angenehme Nebeneffekte einer Motivation, welches im Grunde genommen weder technischer noch geschäftlicher, sondern moralischer Natur war. Zusätzlich wurde Firmen, durch den Standpunkt "frei im sinne von Freiheit", eine grelle Inkonsistenz aufgezwungen, die für einen Geschäftszweig einige bestimmte freie Anwendungen unterstützen wollten, aber für andere weiterhin proprietäre Software vertrieben. Diese Dilemma trafen auf eine Gemeinschaft die sich bereits mit einer Identitätskrise konfrontiert sah. Programmierer die wirklich freie Software schreiben, waren sich nie sonderlich einig über das Endziel der freien Software-Bewegung, wenn es überhaupt eine solches gibt. Zu sagen, dass die Meinungen von einem Extrem zum anderen laufen wäre aber irreführend, da es fälschlicherweise eine lineare Reihe implizieren würde, wo es in Wirklichkeit eine mehrdimensionale Verteilung gibt. Wir können jedoch grob zwischen zwei Glaubensrichtungen unterschieden, wenn wir uns darauf einigen können Feinheiten außen vor zu lassen. Eine Gruppe vertritt die Ansicht von Stallman, das die Freiheit zu teilen und zu modifizieren das Wichtigste ist. Sollte man also aufhören über Freiheit zu reden, dann hat man die Kernfrage weggelassen. Andere sind der Meinung, die Software selbst ist das wichtigste Argument für freie Software und fühlen sich Unwohl bei der Behauptung, proprietäre Software sei an und für sich schlecht. Manche, aber nicht alle Programmierer freier Software, glauben der Autor (bzw. bei bezahlter Arbeit der Arbeitgeber) sollte das Recht haben die Bedingungen zu bestimmen, mit denen die Software verteilt werden darf und dass keine moralische Beurteilung an eine bestimmte Wahl von Bedingungen geknüpft sein muss. Lange Zeit, mussten diese Meinungsverschiedenheiten nicht klar untersucht oder Formuliert werden. Durch den anbrechenden Erfolg in der Geschäftswelt wurde die Angelegenheit aber unausweichlich. 1998 wurde der Begriff Open Source erschaffen, als Alternative zu "frei", durch eine Vereinigung von Programmierern die letztendlich zur Open-Source-Initiative (OSI) wurde. Die Webseite von OSI ist . Die OSI war der Meinung, dass der Begriff "freie Software" nicht nur potentiell verwirrend war, sondern dass es ein Symptom eines allgemeinen Problems war: Die Bewegung brauchte eine Marketing-Kampagne, um es der Geschäftswelt schmackhaft zu machen und um zu verhindern, dass das Gerede über Moral, soziale Vorteile und zügellosen Austausch niemals in den Vorstandsetagen ankommen würde. Mit anderen Worten:
Die Open-Source-Initiative ist ein Marketing Kampagne für freie Software. Es ist ein Angebot für freie Software, auf einer pragmatischen Basis anstatt auf geschwollenes ideologisches Gerede. An der erfolgreichen Substanz hat sich nichts geändert, an der schlechten Einstellung schon. ... Was den meisten Technikfreaks klargemacht werden muss ist nicht das Konzept von Open Source sondern der Name. Warum sollen wir es nicht wie bisher "freie Software" nennen? Ein Grund, ist dass der Begriff "freie Software" leicht missverstanden wird und dadurch zu Konflikten führen kann. ... Der echte Grund für die Umbenennung ist aber eines der Vermarktung. Wir versuchen jetzt unser Konzept der Geschäftswelt zu verkaufen. Wir haben ein gutes Produkt waren aber bisher furchtbar Aufgestellt. Der Begriff "freie Software" wurde von Geschäftsleute falsch verstanden, die den Wunsch miteinander zu teilen so verstanden haben als wäre es gegen den Kommerz, gar schlimmer noch, als Diebstahl. Die durchschnittliche Firmenleitung wird niemals "freie Software" kaufen. Wenn wir aber genau die gleiche Tradition, die selben Menschen und die selben freien Software-Lizenzen nehmen und den Namen in "Open Source" umändern? dann kaufen Sie es gerne. Manche Hacker finden das schwer zu glauben, was aber nur daran liegt, dass sie logisch denken und nur konkrete Tatsachen betrachten. Sie verstehen nicht wie wichtig das Erscheinungsbild ist, wenn man etwas verkaufen will. Bei der Vermarktung, entspricht das Erscheinungsbild auch der Wirklichkeit. Der Anschein, dass wir bereit sind von unseren Barrikaden herunterzukommen um mit Geschäftsleute zu arbeiten zählt genau soviel wie unser tatsächliches Verhalten, unsere Überzeugungen und unsere Software. (von und )
Die Spitzen vieler Eisberge sind in diesem Text sichtbar. Es spricht von "unseren Überzeugungen", vermeidet aber schlauerweise klar zu formulieren, was diese sind. Für manche mag es die Überzeugung sein, dass Code der in einem offenen Prozess entwickelt wurde besserer sein wird; für andere mag es wiederum die Überzeugung sein, dass alle Informationen geteilt werden sollten. Das Wort "Diebstahl" wird benutzt, um (vermutlich) auf illegales Kopieren hinzuweisen – wozu viele Vorbehalte auf der Grundlage hegen, dass es kein Diebstahl ist, wenn der ursprüngliche Besitzer nachher noch den Gegenstand besitzt. Der Text gibt einen verlockenden Hinweis, dass die Bewegung der freien Software versehentlich als anti-kommerziell beschuldigt werden könnte, untersucht aber vorsichtigerweise nicht ob solch eine Beschuldigung vielleicht einen Grundlage hat. Das soll nicht heißen, die Webseite der OSI wäre inkonsistent oder irreführend. Das ist sie nicht. Es ist vielmehr genau dafür ein Beispiel was die OSI behauptet, der freien Software-Bewegung fehlen würde: eine gute Vermarktung, wobei "gut" hier "brauchbar für die Geschäftswelt" bedeutet. Die Open-Source-Initiative gab vielen genau das wonach sie gesucht hatten – ein Wortschatz um über freie Software als Entwicklungsprinzip und Geschäftsstrategie zu sprechen, anstatt als moralischen Kreuzzug. Die Entstehung der Open-Source-Initiative veränderte die Landschaft der freien Software. Es formalisierte einen Zwiespalt der lange ohne Namen geblieben war, und zwang die Bewegung so, die Tatsache anzuerkennen, dass es sowohl eine interne als auch eine externe Politik hatte. Beide Seiten waren dadurch gezwungen eine gemeinsame Basis zu finden, denn die meisten Projekte haben Programmierer aus beiden Lagern, sowie solche die sich nicht klar einer Kategorie zuordnen lassen. Was nicht bedeutet, dass die Leute nie über moralische Motivationen reden – Manchmal wird zum Beispiel auf Fehler in der traditionellen "Hacker-Ethik" hingewiesen. Aber es ist selten, dass ein Entwickler freier / Open-Source-Software offen die Motive anderer im Projekt in Frage stellt. Die Beteiligung ist wichtiger als der Beteiligte. Wenn jemand guten Code schreibt, sollte man sie nicht fragen ob sie es aus moralische Gründen macht, weil sie dafür bezahlt wird, weil sie Ihr Lebenslauf erweitern will, oder aus sonstwelchen Gründen. Man beurteilt den Beitrag den sie leistet auf technischer Ebene und antwortet auf technischer Ebene. Selbstorganisationen wie Debian, die explizit politischer Natur sind, dessen Ziel es ist eine komplett freie Rechenumgebung bereitzustellen, sind relativ locker wenn es darum geht mit nicht freien Code zu funktionieren und mit Programmierern zusammenzuarbeiten, die nicht genau die selben Ziele teilen. Die Situation heute Beim Betrieb eines freien Software-Projekts werden Sie nicht täglich über derart schwerwiegende philosophische Themen reden müssen. Kein Programmierer wird darauf bestehen, dass jeder andere im Projekt die gleichen Ansichten vertritt wie er selbst (und wer es tut, wird ganz schnell feststellen, dass er sich an keinem Projekt beteiligen kann). Sie sollten sich aber darüber im Klaren sein, dass die Kontroverse "frei" kontra "Open Source" existiert, teils um Aussagen zu vermeiden die von manchen Teilnehmern als feindlich aufgefasst werden könnten, teils da ein Verständnis über die Motivationen der Entwickler der beste Weg ist – in gewissem Sinne der einzige – ein Projekt zu leiten. Freie Software ist eine Kultur die man sich aussucht. Um darin erfolgreich wirken zu können, muss man verstehen warum Leute überhaupt die Wahl treffen, sich daran zu beteiligen. Sie zu zwingen funktioniert nicht. Wenn Leute in einem Projekt unglücklich sind, gehen sie einfach zu einem anderen. Freie Software ist selbst unter Gemeinschaften von Freiwilligen bemerkenswert darin, nur eine geringe Investition zu fordern. Die meisten Beteiligten sind einander noch nie wirklich von Angesicht zu Angesicht begegnet und spenden kleine Häppchen ihrer Zeit, wann immer ihnen danach ist. Die Fäden, die Menschen für gewöhnlich verbinden, um eine beständige Gruppe zu formen, sind auf einen winzigen Kanal reduziert: das geschriebene Wort, übertragen durch elektrische Leitungen. Aus diesem Grund kann es lange dauern, bis sich eine geschlossene, engagierte Gruppe bildet. Umgekehrt kann eine Gruppe schon während der ersten fünf Minuten ihrer Begegnung mit einem potentiellen Freiwilligen, sein Interesse sehr leicht verspielen. Wenn ein Projekt keinen guten ersten Eindruck macht, werden Neulinge ihm selten eine zweite Chance geben. Die Vergänglichkeit der Beziehungen, bzw. ihre potenzielle Vergänglichkeit, ist das vielleicht größte Problem, welchem ein neues Projekt sich stellen muss. Was soll all diese Menschen dazu bewegen, lange genug zusammen zu bleiben, um etwas Nützliches zu produzieren? Die Antwort auf diese Frage ist komplex genug, um sie zum Thema dieses Buchs zu machen, müsste man es jedoch in einem Satz zusammenfassen, wäre es folgender:
Menschen sollten spüren, dass ihre Verbindung zu einem Projekt und ihr Einfluss darauf proportional zu ihrer Beteiligung ist.
Kein Entwickler oder potentieller Entwickler sollte sich jemals aus nicht-technischen Gründen herabgesetzt oder diskriminiert fühlen. Projekte mit Unterstützung durch Firmen müssen in dieser Hinsicht ganz besonders vorsichtig sein. Der Abschnitt behandelt dieses Thema im Detail. Keine Unterstützung durch eine Firma zu haben, bedeutet natürlich nicht, dass man sich um nichts Sorgen machen muss. Geld ist nur einer vieler Faktoren, die den Erfolg eines Projekts beeinflussen können. Es sind ebenso die Fragen zu klären, welche Sprache, welche Lizenz und welche Art der Entwicklung man wählen sollte, welche Infrastruktur man aufbauen sollte, wie man die Gründung des Projekts am besten bekanntgeben sollte und vieles mehr. Wie man ein Projekt auf dem richtigen Fuß startet, ist Thema des nächsten Kapitels.