Inhaltsverzeichnis
Nur wenige freie Software-Projekte sind erfolgreich.
Man hört selten etwas von einem fehlgeschlagen Projekt. Nur erfolgreiche Projekte bekommen Aufmerksamkeit, und es gibt insgesamt so viele Open Source Projekte [4], 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 einzelnen 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 diejenigen die sie durchführen, wissen für gewöhnlich nicht, dass es die Letzte war. Es gibt nicht einmal eine klare Definition wann ein Projekt abgelaufen ist. Ist es wenn an einem Projekt seit sechs Monaten nicht Aktive gearbeitet wurde? Sobald seine Nutzer Gemeinde aufhört zu wachsen, ohne die Entwickler Gemeinde übertroffen zu haben? Was ist wenn die Entwickler ihr Projekt verlassen, wenn sie merken, dass ein anderes Projekt die gleichen Ziele hat und sie unnötig einen Doppelten Aufwand betreiben. Was ist wenn 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 ein 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 es 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 mit dem Wachstum und der Pflege eines Projekts erfolgreich. 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.
Es wäre verlockend zu sagen, dass freie Software Projekte aus den selben Gründen fehlschlagen, wie proprietäre Software Projekte. Freie Software hat sicherlich kein Monopol auf unrealistische Anforderungen, vage Spezifikationen, unzureichende Verwaltung von Ressourcen, zu kurze Entwurfsphasen, oder ein anderes der bekannten Kobolde aus der Software Industrie. Es gibt eine gewaltige menge Schriftstücke zu diesem Thema und ich werde sie in diesem Buch nicht versuchen zu reproduzieren. Statt dessen werde ich versuchen die spezifischen Probleme freier Software zu beschreiben. Wenn ein freies Software Projekt an die Wand gefahren wird, dann ist es oft weil die Entwickler (oder die Projektleiter) nicht die einzigartigen Probleme von Open Source Software zu würdigen 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 Seite für Entwickler aufzubauen, einen E-Mail Verteiler 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. 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 ein warnende Lehre hier 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 verwandter Fehler ist an Aufmachung und Präsentation zu sparen, in der Annahme, dass diese Sachen auch später, wenn das Projekt erst einmal läuft, erledigt werden können. 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 nebensächlich zum eigentlichen Quellcode. Dafür gibt es ein paar Gründe. Erstens, kann es einem wie Fleißarbeit vorkommen, denn es kommt meistens nur denen zugute, die noch am wenigsten mit dem Projekt zu tun haben und umgekehrt. Schließlich braucht jemand der bereits mit dem Projekt vertraut ist, nicht unbedingt diese ganze Aufmachung. Wie man die Software installiert, administriert und benutzt ist alles schon bekannt, schließlich hat man es selbst geschrieben. Zweitens sind für Aufgaben die sich um vernünftige Aufmachung und Präsentation drehen, andere Fähigkeiten gefordert, als solche die man benötigt um Quellcode zu schreiben. Menschen neigen dazu, sich auf ihre Stärken zu konzentrieren, selbst wenn es für das Projekt besser wäre, ein wenig Zeit in etwas zu investieren, was ihnen weniger liegt. Kapitel 2, Der Einstieg behandelt Aufmachung und Präsentation im Detail, und erklärt warum es von Anfang an eine Priorität sein 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 eine Open Source Projekt anwenden lassen. Die Verwaltung ist bei einem Open Source Projekt, nicht immer besonders offensichtlich, im Hintergrund haben erfolgreiche Projekte sie aber, in einer Form. Ein kleines Gedankenexperiment reicht um die Gründe dafür zu zeigen. Ein Open Source Projekt besteht aus einem zufällig zusammengewürfeltem Haufen Programmierer—die an und für sich schon eine notorisch eigensinnige Truppe sind—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. Ohne ein Wunder, würden sie sehr schnell außeinander 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 mehr zusammen erreichen können, als jeder alleine. Die Aufgabe einer Verwaltung besteht deshalb hauptsächlich darin, dieses Gefühl aufrechtzuerhalten, indem sie Richtlinien für die Kommunikation festlegt, brauchbare Entwickler davor schützt, aufgrund persönlicher Eigenheiten an den Rand gedrängt zu werden, und allgemein das Projekt als Ort zu gestalten, an dem Entwickler zurückkehren wollen. Bestimmte Methoden das zu erreichen, werden im Verlauf des Buchs behandelt.
Zuletzt, gibt es noch die generelle Problemgruppe die man "Versagen der kulturellen Navigation" nennen könnte. Vor zehn Jahren, gar vor fünf, wäre es vorschnell gewesen, 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 von diesen Kern wesentlich 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, worauf sie zurückgreifen können, um Meinungsverschiedenheiten zu klären.
Dieses Buch ist ein praktischer Führer, keine anthropologische Studie oder Historie. Ein Hintergrund zur Kultur freier Software ist 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 jemand ohne Verständnis für die Kultur, die Organisations- und Beteiligungsvorgänge in einem Projekt als schwierig und voller Überraschungen empfinden. Da die Anzahl der Menschen die freie Software entwickeln immer noch stark im Anstieg ist, 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. 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 Disketten oder Magnetbänder mittels Post zu einander und manchmal fungierten die Hersteller selbst als zentrale Anlaufstelle für Patches. Es half auch das viele frühen Computer Entwickler an Universitäten arbeiteten, wo die Veröffentlichung des eigenen Wissens erwartet wurde. Die Physikalischen Realitäten der Datenübertragung bedeuteten jedoch, dass der Austauschen immer einen Widerstand mit sich brachte, der proportional zu der Entfernung (echte oder organisatorische) anwuchs, die von der Software überwunden werden musste. Weitverbreitete reibungsloses Tauschen, wie wir sie heute erleben, war nicht möglich.
Während die Industrie heranreifte, traten gleichzeitig mehrere zusammenhängende Veränderungen auf. Die wilde Vielfalt der Hardware Architekturen wich langsam einige wenige Gewinner—Gewinner durch überlegene Technologie, überlegenes Marketing, oder eine Kombination beider. Gleichzeitig, und nicht ganz zufällig, bedeutete die Entwicklung sogenannter "höherer" Programmiersprachen, dass man eine Anwendung einmal schreiben konnte, in einer Sprache, und es automatisch übersetzen ("Kompilieren") lassen konnte, um es auf verschiedene Computer laufen zu lassen. Die Folgen hiervon, blieben den Hardware Herstellern nicht verborgen: Ein Kunde konnte jetzt ein großes Software Projekte in Angriff nehmen, ohne sich zwangsläufig auf eine bestimmte Computer Architektur festzulegen. Diese Tatsache zusammen mit den allmählich keiner werden Unterschieden zwischen den verschiedenen Marken, da weniger effiziente Bauweisen ausgelesen wurden, zwang Hersteller die ihre Hardware als seine einziges Gut behandelten dazu, sich auf sinkende Gewinnmargen einstellen zu müssen. 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 mussten deshalb anfangen, ihre Urheberrechte auf den Quellcode strenger durchzusetzen. Wenn Nutzer einfach weiterhin frei miteinander Code tauschten und modifizierten, würden sie vielleicht manche der Verbesserungen die vom Hersteller als "Mehrwert" verkauft wurden, eigenständig neu implementieren. Schlimmer noch, getauschter Quellcode könnte in den Hände der 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.
Während der unbeschränkte Austauschen von Quellcode langsam nachließ, kristallisierte sich, zumindest im Kopf von einem Programmierer, eine Gegenreaktion. Richard Stallman arbeitete im Labor für künstliche Intelligenz, an dem MIT in den 1970ern und frühen '80ern, während was sich als goldene Zeit und als goldener Ort für den Austauschen von Quellcode, herausstellen sollte. 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. Wie Stallman später schrieb:
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, zum lesen, um es zu verändern oder Teile davon für eine neue Anwendung auszuschlachten.
Diese Edenische Gemeinschaft brach um Stallman herum, kurz nach 1980 zusammen, als die Veränderungen die in der restliche Industrie, endlich 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, nur jetzt unter einer exclusiven Lizenz. Zur gleichen Zeit, 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.
Das hatte zur Folge, dass der erste Schritt bei der Nutzung eines neuen Computers, ein Versprechen war, seinen eigenen Nachbarn nicht zu helfen. Eine gemeinschaftliche Zusammenarbeit war verboten. Die Regel die von den Besitzern proprietärer Software aufgestellt wurde war, "Wenn du mit deinem Nachbarn Teilst, bist du ein Pirat. Wenn du irgendwelche Änderungen haben möchtest, dann musst du uns darum betteln.".
Aus irgend einer persönlichen Eigenart, entschied er sich gegen diese Entwicklung Widerstand 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 Sammlung von Anwendungen zu entwickeln, die jedem Benutzer ermöglichen sollte an der Software zu zu hacken sowie ihre Änderungen untereinander auszutauschen. 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, dessen 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. Wenn es ohne Lizenz wäre, könnte irgendeine beliebige Kopie in einer proprietären Anwendung aufgenommen werden (ein bekanntes Phänomen, bei Code welches unter tolerante Lizenzen veröffentlicht wird). Obwohl solche eine Einbindung in keiner Weise die weiter 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 freie Software Lizenzen werden im Kapitel ??? ausführlich behandelt.
Mit Unterstützung durch viele andere Programmierer, die zum Teil die Ideologie von Stallman teilten und von denen andere einfach nur eine Menge freien Code wollten, fing das GNU Projekt an freien Ersatz für viele der wichtigsten Komponenten eines Betriebssystems zu veröffentlichen. Aufgrund der nunmehr weit verbreiteten Standardisierung von Hardware und Software, war es möglich GNU Ersatz in ansonsten nicht freie Systeme zu verwenden, was viele auch taten. Der GNU Text-Editor (Emacs) und C Compiler GCC, die großen Anklang fanden, nicht aufgrund der Ideologie, sondern einfach aufgrund ihrer technischen Vorzüge, waren besonders erfolgreich. Bis ca. 1990, hatte GNU den größten Teil eines freien Betriebssystems fertiggestellt, bis auf den Kernal—dem Teil der den Computer tatsächlich hochfährt und dafür zuständig ist Haupt-Speicher, Festplatten und andere Ressourcen des Systems zu verwalten.
Leider hatte das GNU Projekt ein Kernel Aufbau gewählt, der 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 Student 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. [7]
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 als eine Glaubenssache sprachen, wofür es sich zu kämpfen lohnt, und nicht nur als eine Bequemlichkeit, machten sie es für Programmierer schwierig nicht ein politisches Bewusstsein darüber zu haben. Selbst solche, die der FSF nicht zustimmten mussten 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. Mit der weiten Verbreitung ihres Codes verbreitete sich auch ihre Botschaft.
Es gab jedoch viele andere Vorgänge in der aufkeimenden Szene der freien Software und wenige waren derart explizit 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 nicht ideologische Entwicklung freier Software und diente als Ausbildungsstätte für viele Entwickler die später weiterhin, in der Open Source Welt 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 [8] 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, welches dem GNU Projekt ein paar Jahre vorausging war TeX, ein freies Textsatzsystem für druckfertige Dokumente von Donald Knuth. 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 zu 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 nahm keine 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 Software Entwicklung 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 sich allzuviele Sorgen um eine Qualifizierung, außerhalb des technischen, zu machen.
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 rein aus 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 zu widmen, profitiert aber von den Beiträgen aller Beteiligten, also auch von unbezahlte Freiwillige und Programmierer anderer Unternehmen.
Mit zunehmender Aufmerksamkeit aus der Unternehmenswelt, wurden Programmierer freier Software mit Fragen der Präsentation konfrontiert. Eines war das Wort "Frei"[9] 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 ist[10], 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 es zu modifizieren und weiterzugeben[11]. 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."[12]. Trotzdem, das wieder und immer wieder erklären zu müssen, ist auf Dauer ermüdend. Viele Programmierer fühlten teils zurecht, dass die Zweideutigkeit des Worts "frei" das Verständnis 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 einträchtiger 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 das die Software selbst das wichtigste Argument für freie Software ist 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, dass der Autor (bzw. bei bezahlter Arbeit der Arbeitgeber) das Recht haben sollte, zu bestimmen unter welchen Bedingungen die Software verteilt werden darf und das 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.[13] 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 Vorstandsetage 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 nur mit konkreten, auf Tatsachen beruhende Begriffe denken und nicht verstehen 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 http://opensource.feratech.com/advocacy/faq.php und http://opensource.feratech.com/advocacy/case_for_hackers.php#marketing)
Die Spitzen vieler Eisberge sind in diesem Text sichtbar. Es redet 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 Code 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, von dem die OSI behauptet, was 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 damit die Bewegung, 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 werden zum Beispiel, 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. Selbst Organisationen 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.
[4] 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.
[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 relativ neuen 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... dasselbe.
[7] Rein Technisch gesehen war Linux nicht das erste freie Betriebssystem sondern eines für IBM-kompatible Rechner namens 386BSD, welches kurz zuvor erschienen war. Es war jedoch viel schwieriger 386BSD zum laufen zu bringen. Linux machte solch einen guten Anfang, nicht nur weil es frei war, sondern weil man tatsächlich eine gute Chance hatte, es auf seinen Computer zum laufen zu bringen.
[8] 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.
[9] 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.
[10] 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
[11] Der Quellcode vom Netscape Navigator wurde letztendlich 1998 unter einer Open Source Lizenz gestellt, und wurde zur Grundlage für den Mozilla Browser. Siehe http://www.mozilla.org/.
[12] engl.: "It's free as in freedom—think free speech, not free beer."
[13] Die Webseite von OSI ist http://www.opensource.org/.