Inhaltsverzeichnis
Freie Software — Open Source software[3] — wurde zum Rückgrad moderner Informationstechnologie. Sie läuft auf ihrem Telefon, ihrem Laptop und Desktop-Computer und in eingebetteten Mikrocontrollern von Haushaltsgeräten, Automobilen, Industriemaschinen und zahllosen anderen Geräten, bei denen wir häufig nicht dran denken, dass auch sie Software haben.
Noch immer ist sie weitestgehend unsichtbar, vor allem auch gegenüber Menschen, die im Technologiebereich arbeiten. Die Natur von Open Software ist, in den Hintergrund zu verschwinden und unbemerkt zu bleiben, außer für die, deren Arbeit direkte Berührung damit hat.
Wenn Sie bis hierhin gelesen haben, sind Sie bereits einer der Menschen, die sich fragen, woher der Sauerstoff kommt, und der wahrscheinlich selbst welchen erschaffen möchte.
In diesem Buch möchte nicht nur untersuchen, wie man Open Source richtig macht sondern auch, wie man es falsch macht, so dass Sie Probleme frühzeitig erkennen und korrigieren können. Ich hoffe, dass Sie nach dieser Lektüre über ein Repertoir an Techniken verfügen, mit dem Sie nicht nur häufige Stolpersteine vermeiden sondern auch Wachstum und Pflege eines erfolgreichen Projektes meistern. 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 Ressourcenverwaltung, Ignorierung von Nuteranforderungen oder irgend einen der anderen Kobolde, welche der Software-Industrie bereits wohl bekannt sind. Es gibt genügend Material zu diesem Thema und ich werde versuchen, es in diesem Buch nicht zu duplizieren. Stattdessen 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 Mitwirkenden 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 von sich aus Ihem Projekt Zeit widmen, 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 in Betrieb zu halten.
Das Projekt zu öffnen bedeutet, den Quellcode so zu gestalten, dass er für völlig Fremde verständlich ist, Entwicklungsdokumentation zu schreiben und Diskussionsforen und andere Werkzeuge für die Zusammanarbeit aufzubauen (dies wird in Kapitel 3, Technische Infrastruktur detaillierter beschrieben).
All das ist eine Menge Arbeit und zunächst reiner Zusatzaufwand. 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.
Ein ähnlicher Fehler ist es, an der 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 für Neuankömmlinge niedrig zu halten — das Arbeitspacket zu verkleinern, das sie erledigen müssen, um von dort wo sie sind die nächste Stufe der Verbindlichkeit zur erreichen. Die Webseite muss professionell aussehen, die Softwarecompilierung, Packetierung und Installation sollte soweit wie möglich autmatisiert erfolgen, usw.
Viele Programmierer behandeln unglücklicherweise diese Art Arbeit als zweitrangig gegenüber dem eigentlichen Coding. Es gibt eine Reihe Gründe dafür. Erstens kann es sich wie viel Arbeit anfühlen, weil dessen Vorteile für diejenigen am sichtbarsten sind, die am wenigsten mit dem Projekt vertraut sind — und umgekehrt: Letztendlich brauchen diejenigen, welche den Code entwickeln, nicht wirklich die Packetierung. Sie wissen bereits, wie die Software zu installieren, zu administrieren und zu benutzen ist, weil sie diese geschrieben haben. Zweitens sind die erforderlichen Fähigkeiten für Präsentieren und gutes Packetieren oft komplett andere als die, Code zu schreiben. Menschen neigen dazu, sich auf das, worin sie gut sind, zu fokussieren, auch wenn es für das Projekt besser ist, etwas Zeit für etwas zu verbringen, das ihnen weniger gut gefällt. Kapitel 2, Der Einstieg bespricht Präsentation und Packetierung detailliert und erklärt, warum es wichtig ist, dass sie Priorität von Beginn an im Projekt haben.
Der nächste Trugschluss ist, dass bei freier Software wenig bis gar kein Projektmanagement erforderlich ist bzw. umgekehrt, dass dieselben Management-Verfahren, die für die Entwicklung im Unternehmen benutzt werden, sich genauso gut auf ein Open-Source-Projekt anwenden lassen.
Die Verwaltung ist bei einem Open-Source-Projekt nicht immer besonders sichtbar, aber bei erfolgreichen Projekten gibt es sie in irgendeiner 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 eine notorisch eigensinnige Gattung — , von denen untereinander wahrscheinlich keiner einem anderen 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 auseinanderbrechen. 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 zwanzig, vielleicht auch nur zehn 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 dieses Kerns. 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 gutem 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 diesem 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.
Die letzte Kategorie, fehlende kulturelle Orientierung, schließt ein interessantes Phänomen ein: Bestimmte Organisationsformen sind strukturell weniger kompatibel mit Open-Souce Entwicklung als andere. Eine der größten Überaschungen für mich bei der Vorbereitung zu dieser zweiten Auflage war, zu erkennen, dass, alles in Gänze betrachtet, die Erfahrung zeigte, das öffentliche Verwaltungen weniger begeistert von der Beteiligung an freien Software Projekten sind als profitorientierte Kooperationen, wobei Non-Profits irgendwo zwischen diesen beiden liegen. Es gibt viele Ursachen dafür (sieh ???) und die Probleme sind bestimmt überwindbar aber es lohnt sich zu beachten, dass wenn eine existierende Organisation — zumal eine hierarchische und vor allem eine hierarchische, risikoscheue und öffentlichkeits wirksame — einem Open-Source Projekt beitritt oder eins startet, diese Organisation normalerweise ein paar Anpassungen vornehmen werden muss.
Der Aufwand für den Betrieb von Open- im Gegensatz zu Closed-Source ist nicht groß, aber der Aufwand ist am ehesten gerade zu Beginn merklich. Weniger merklich zu Beginn sind die Vorteile, welche beachtlich sind und offensichtlicher werden, während das Projekt läuft. Da ist eine tiefe Zufriedenheit, welche es Entwicklern gewiss gibt: die Freude, seine Arbeit offen, schätzenwert und von seinen Kollegen geschätzt zu machen. Es ist kein Zufall, dass viele Open-Source Entwickler im selben Projekt aktiv bleiben - als Teil ihrer Arbeit - auch nach Wechsel des Arbeitgebers. Aber es gibt auch signifikante organisatorische Vorteile: Die Open-Source Projekte, an denen ihre Organistion teilnimmt, sind wie eine Haut, durch welche ihre Manager und Entwickler ständig gegenüber Menschen und Ideen exponiert sind, die außerhalb ihrer organisatorischen Hierarchie stehen. Es ist in etwa so, als hätte man die Vorteile einer Teilnahme an einer Konferenz während man weiterhin die tägliche Arbeit erledigt und ohne dass Reisekosten entstehen.[4] In einem erfolgreichen Open-Source Projekt wiegen diese Vorteile, wenn sie zu Tage treten, die Kosten um ein vielfaches auf.
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.)
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. Den Herstellern war das nur recht, sie ermutigten sogar dazu: Aus ihrer Sicht machte jede Verbesserung an der Software, egal aus welcher Quelle, ihre Hardware 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 des Computerdesigns, aber diese Vielfalt bedeutete, dass alles inkompatibel zueinander war. Deshalb lief Software, die für eine bestimmte Maschine geschrieben wurde, im Allgemeinen auf keiner anderen; Programmierer bevorzugten, sich Fachkenntnisse zu einer bestimmten Architektur oder Familie von Architekturen anzueignen (im Gegensatz dazu würden sie heute eher Fachkenntnisse in einer Programmiersprache oder Familie von Programmiersprachen sammeln, mit der Zuversicht, dass ihre Kenntnisse, auf welcher Hardware sie auch arbeiten mögen, übertragbar wären). Weil die Erfahrungen einer Person dazu neigten sich auf eine bestimmte Computerarchitektur zu beschränken, hatte die Aneignung von Erfahrung die Folge, dass diese Computerarchitektur für diese und ihre Kollegen attraktiver war. Deshalb war es im Interesse des Herstellers, dass für seine Maschinen spezifisches Wissen und Code sich so weit wie möglich verbreitete.
Zweitens gab es kein weit verbreitetes Internet. Obwohl es weniger rechtliche Einschränkungen für den Austausch von Software gab als heute, waren die technischen Beschränkungen gößer: Es gab ein ein paar wenige, lokale Netzwerke, die gut waren um Informationen unter Mitarbeitern der gleichen Forschungseinrichtung auszutauschen. Aber es blieben Barrieren die es zu überwinden galt, wenn man mit der Welt teilen wollte. 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ät der Datenübertragung bedeutete jedoch, dass der Austausch 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 es heute erleben, war nicht möglich.
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-Projekt in Angriff nehmen, ohne sich auf eine bestimmte Computer-Architektur festzulegen. Diese Tatsache, zusammen mit den allmählich kleiner werdenden Unterschieden zwischen den verschiedenen Marken (da weniger effiziente Architekturen ausgesiebt wurden), zwang Hersteller, die ihre Hardware als ihr 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 an die Konkurrenz gelangen. Ironisch dabei ist, dass all das zur selben Zeit geschah, als das Internet endlich anfing abzuheben. Gerade als dann somit 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.
Langsam ließ der unbeschränkte Austausch von Quellcode überall in der Softwareindustrie nach. Überall? Zumindest im Kopf eines Programmierers kristallisierte sich 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" [5] 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 wenn Leute von anderen Universitäten oder Firmen eine Anwendung benutzen und portieren wollten, konnten sie das gerne machen. Wenn du jemand bei der Nutzung einer unbekannten 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.
Die paradiesische Gemeinschaft um Stallman herum brach kurz nach 1980 zusammen, als die Veränderungen der Industrie letztendlich das KI-Labor einholten. Eine Startup-Firma stellte viele Programmierer des Labors ein, um an einem Betriebssystem zu arbeiten, ähnlich dem, welches sie im Labor programmiert hatten, diesmal aber unter einer exklusiven Lizenz. Gleichzeitig schaffte sich das KI-Labor neue Ausrüstung an, welche 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 einer 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 [6] 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 den Weg, wiederherzustellen, was im KI-Labor zerstört wurde, aber in einer weltumspannenden 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 cleveres 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 von dem zu erreichen, wofür es üblicherweise benutzt wird: Anstatt die Verbreitung der Software einzuschränken, hindert es jeden, sogar den Autor, daran, ihre Verbreitung einzuschränken. 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 (was manchmal auch bei Code, welcher unter toleranten Lizenzen veröffentlicht wird, passiert [7]). 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 einen 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, teils 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ären Systemen, 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 anderer 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 Entwicklern, verteilt auf der ganzen Welt, einen freien Kernel fertig gestellt hatte, der auf einem viel konservativeren Aufbau basierte. Er nannte es Linux, und als es mit den bereits existierenden GNU Anwendungen und anderen freien Anwendungen (speziell das X Windows System) kombiniert wurde, war das Ergebnis ein komplett freies Betriebssystem. Zum ersten Mal konnte man seinen Computer ohne proprietäre Software hochfahren und damit arbeiten. [8]
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, den sie produzierten, von Bedeutung, sondern auch wegen ihrer Rhetorik. Indem sie von freier Software eher als Glaubenssache sprachen, für die 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, musste 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 ihrem Code verbreitete sich auch ihre Botschaft.
Es gab viele andere Vorgänge in der aufkeimenden Szene der freien Software und nicht alle 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 — bis in die späten 1970ern ein loses proprietäres Forschungsprojekt von Programmierern bei AT&T — an der Universität von Kalifornien in Berkeley. Die BSD Gruppe machte keine offenkundigen politischen Ä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 zu einem frühen Beispiel für Entwicklung freier Software ohne ideologischen 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 grafische Benutzerumgebung, welches Mitte der 1980er am 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 gängige X Version zu verbessern und sich dadurch von den anderen Mitgliedern abzuheben. X Windows [9] selbst war freie Software, aber hauptsächlich als Mittel, um das Spielfeld zwischen konkurrierenden wirtschaftlichen Interessen und zunehmender Standardisierung zu ebnen, nicht als Wunsch die Vormacht proprietärer Software zu brechen. Ein weiteres Beispiel, das dem GNU Projekt ein paar Jahre vorausging, war TeX von Donald Knuth, ein freies Textsatzsystem für druckfertige Dokumente. Er veröffentlichte es unter Bedingungen, welche 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 Kapitel 9, Lizenzen, Urheberrecht und Patente ausführlicher behandelt wird). Knuth bezog nicht Stellung für die eine oder andere Partei in Bezug auf die Frage freier gegen proprietäre Software; er brauchte nur ein besseres Textsatzsystem um sein echtes Ziel zu erreichen — ein Buch über Softwareentwicklung zu schreiben — und sah, als er fertig war, keinen Grund, sein System nicht der Welt zur Verfügung zu stellen.
Ohne hier jedes Projekt und jede Lizenz aufzulisten, kann man doch mit Sicherheit sagen, dass Ende der 1980er eine Menge freier 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 es war. Obwohl sie es genossen an freier 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. Dies mag der Grudn sein, warum 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 sich all zu viele Sorgen um Qualifizierungen oder Motivationen außerhalb des technischen machen zu müssen.
Entwickler hatten noch einen weiteren Grund zusammenzuhalten: es stellte sich heraus, dass die Welt freier Software qualitativ sehr hochwertigen Code produzierte. Manchmal war es aus technischer Sicht der nächstbesten nicht-freien Alternative nachweislich überlegen; manchmal war es zumindest vergleichbar und natürlich kostete es weniger es zu erwerben. Auch wenn nur wenige motiviert gewesen wären, freie Software aus rein philosophischen Gründen zu nutzen, waren viele mehr als glücklich sie wegen ihrer technischen Überlegenheit nutzen zu können. 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 freien 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, einschließlich der Arbeit von Programmierern, die von anderen Unternehmen bezahlt werden, und von Freiwilliger, die unterschiedliche eigene Motivationen haben.
Mit zunehmender Aufmerksamkeit aus der Unternehmenswelt wurden Programmierer freier Software mit Fragen der Präsentation konfrontiert. Eines war das Wort "frei"[10] selbst. Wenn man den Begriff "freie Software" zum ersten Mal hört, denken viele, es bedeute lediglich "gratis Software". Es stimmt zwar, dass freie Software auch kostenlos ist[11], aber nicht jede Software, die nichts kostet ist, auch frei im Sinne von "Freiheit"" — welches die Freiheit meint, es zu teilen und zu verändern, egal aus welchem Grund. Ein Beispiel ist der Krieg der Browser in den 1990ern, indem sowohl Netscape als auch Microsoft ihre konkurrierenden 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 weiterzugeben[12]. 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 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."[13]. Diese Erklärung dauernd wiederholen zu müssen ist aber auf Dauer ermüdend. Viele Programmierer fühlten, teils zu Recht, 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, die weder technische noch geschäftliche, sondern moralischer Wurzeln hatte. Zusätzlich wurde Firmen durch den Standpunkt "frei im Sinne von Freiheit" eine grelle Inkonsistenz aufgezwungen, die für einen Geschäftszweig freie Anwendungen unterstützen wollten, aber für andere weiterhin proprietäre Software vertrieben.
Diese Dilemma trafen auf eine Gemeinschaft, welche sich bereits mit einer Identitätskrise konfrontiert sah. Programmierer, die wirklich freie Software schreiben, waren sich nie sonderlich einig über das Gesamtziel der freien Software-Bewegung, wenn es überhaupt ein 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, wohingegen 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, dass 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 sei das wichtigste Argument für freie Software, und fühlen sich bei der Behauptung unwohl, 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 Wertung an eine bestimmte Wahl von Bedingungen geknüpft sein muss. Andere glauben dies nicht.
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 als Alternative zu "frei" erschaffen, durch eine Vereinigung von Programmierern, die letztendlich zur Open-Source-Initiative (OSI) wurde.[14] 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 das Konzept 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 solle. Mit ihren eigenen Worten zu der Zeit:
Die Open-Source-Initiative ist eine Marketingkampagne für freie Software. Es ist die Anpreisung freier Software auf einer pragmatischen Basis, anstatt auf geschwollenem ideologischem 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 einer 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äftsleuten falsch verstanden, die den Wunsch zu teilen als Anti-Kommerz verstanden; 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" — ä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äftsleuten zu arbeiten, zählt genauso viel wie unser tatsächliches Verhalten, unsere Überzeugungen und unsere Software.
(von https://www.opensource.org/. Oder stattdessen einst von dieser Seite — die OSI hat die Seiten offensichtlich seit dem abgeschaltet, sie können trotzdem unter https://web.archive.org/web/20021204155057/http://www.opensource.org/advocacy/faq.php und https://web.archive.org/web/20021204155022/http://www.opensource.org/advocacy/case_for_hackers.php#marketing [sic].) angesehen werden.
Die Spitzen vieler Eisberge sind in diesem Text sichtbar. Er spricht von "unseren Überzeugungen", vermeidet aber schlauerweise klar zu formulieren, was diese sind. Für manche mag es die Überzeugung sein, dass Code, welcher in einem offenen Prozess entwickelt wurde, besser sei; 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 ein Beispiel für genau das, von dem die OSI behauptet, es würde der freien Software-Bewegung fehlen: 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 — einen 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 somit, die Tatsache anzuerkennen, dass sie 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 dieser Kategorien 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 diese nicht fragen, ob sie es aus moralischen Gründen machen, weil sie dafür bezahlt werden, weil sie ihren Lebenslauf erweitern wollen oder aus sonstwelchen Gründen. Man beurteilt den Beitrag, den sie leisten, auf technischer Ebene und antwortet auf technischer Ebene. Selbst explizit politische Organisationen wie das Debian Projekt, dessen Ziel die Bereitstellung einer 100% freien Rechenumgebung ist, sind relativ entspannt, wenn es um die Einbindung nicht-freien Codes und die Zusammanarbeit mit Programmierern geht, die nicht genau die selben Ziele teilen.
[3] Die Begriffe sind Synonyme, wie bereits in Vorwort erwähnt. Sieh „"Frei" kontra "Open Source"“ für Details.
[4] Sicher, es ist weiterhin eine gute Idee für sie, hin und wieder an echten Konferenzen teilzunehmen; sieh ???.
[5] 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 gewisserweise neueren Bedeutung von "Jemand der in Computer einbricht".
[6] Abkürzung für "GNU's Not Unix", und das "GNU" in dieser Erweiterung steht für eine Fußnote unendlicher Länge.
[7] sieh „Terminologie“ zu weiterem über "tollerante" Lizenzierung versus GPL-artiger "copyleft" Lizenzierung. Die opensource.org FAQ ist dafür ebenso eine gute Informationsquelle — sieh https://opensource.org/faq#copyleft.
[8] Rein technisch gesehen war Linux nicht das erste freie Betriebssystem, sondern das kurz zuvor erschienene 386BSD für IBM-kompatible Rechner. 386BSD war jedoch viel schwieriger zum Laufen zu bringen. Linux sorgte für Aufregung, nicht nur weil es frei war, sondern weil es mit hoher Wahrscheinlichkeit deinen Computer bootete, nachdem du es installiert hattest.
[9] 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.
[10] 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.
[11] Man 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.
[12] Der Quellcode vom Netscape Navigator wurde letztendlich 1998 unter eine Open-Source-Lizenz gestellt und zur Grundlage für den Mozilla-Browser. Siehe https://www.mozilla.org/.
[13] engl.: "It's free as in freedom — think free speech, not free beer."
[14] Die Webseite von OSI ist https://www.opensource.org/.