Open Source - Eine Einführung

Das folgende Kapitel ist ein Auszug aus dem Buch "Open Source einsetzen und integrieren" von Thomas Krumbein.

"Ich denke, dass jede allgemein nützliche Information frei sein sollte. Mit >frei< beziehe ich mich nicht auf den Preis, sondern auf die Freiheit, Informationen zu kopieren und für die eigenen Zwecke anpassen zu können. Wenn Informationen allgemein nützlich sind, wird die Menschheit durch ihre Verbreitung wieder reicher, ganz egal, wer sie weitergibt und wer sie erhält."
(Richard Stallmann, ca. 1990)

In den Anfangstagen der Computertechnologie war die damals verfügbare Software quelloffen und frei. Zu dieser Zeit gab es noch gar keinen Markt für Software. Die Hersteller von Computern verkauften Ihre "Maschinen" und lieferten, so weit verfügbar, die Software kostenfrei mit. Allerdings beschränkten sich die mitgelieferten Programme auf rudimentäre Befehlssequenzen zum Ansteuern und Zugreifen auf die gelieferten Hardware-Komponenten. Der Kunde selbst programmierte dann seine Anwendungsprogramme und die Hardware-Hersteller (z. B. IBM oder DEC) förderten den Wissensaustausch zwischen den unterschiedlichen Kunden. Je mehr Erfahrung und Anwendungen es gab, umso besser konnten Hardwarelösungen (Computer) verkauft werden.

Erst in den 70er Jahren wurde Software kommerziell als eigenständiges Produkt erstellt und verkauft. Da es aber die meisten Programme nach wie vor kostenfrei und quelloffen gab, konnten sich proprietäre Produkte nur langsam etablieren. 1975 wurde "Microsoft" gegründet und Anfang der 80er Jahre brachte IBM den ersten PC auf den Markt, nahm das Projekt aber selbst nicht so richtig ernst und kaufte erstmals Komponenten von außen hinzu, wie z. B. Prozessoren und das Betriebssystem.

Mit dem PC und der Entscheidung von IBM, die Spezifikationen der Hardwarearchitektur zu veröffentlichen, begann ein tief greifender Wandel in der Computerlandschaft. Der Computer wurde zur Massenware, ein Industriestandard, unabhängig von einzelnen Herstellern und Unternehmen, war geboren.

Da IBM sich recht frühzeitig auf das (zugekaufte) Betriebssystem MS-DOS festlegte und sicherstellte, dass alle Programme, die mit dem IBM-PC ausgeliefert wurden, nur mit diesem Betriebssystem funktionierten, dominierte MS-DOS in kürzester Zeit den Markt und verdrängte das technisch bessere CP/M, das bis dahin auf den "kleinen" Maschinen überwiegend installiert war.

Ab dieser Zeit entstand auch das Zeitalter der "Software aus der Schachtel". Maßgefertigte Software für spezielle Anwendungs- und Aufgabenstellungen, erstellt von externen Dienstleistern und Firmen, verkauft über reine Vertriebsgesellschaften.

So entstanden Tausende von nahezu identischen Schreib- und Kalkulationsprogrammen, Buchhaltungs-, Abrechnungs- und Datenbanksystemen und vieles mehr, immer wieder aufs Neue.

"Software" wurde zu einem Produkt, einem Endprodukt. Sie war nur noch für den bestimmten Anwendungsfall zu gebrauchen, und bedurfte spezieller Strukturen, damit sie funktionierte. Der Kunde/Nutzer konnte keine Änderungen mehr selbst vornehmen, noch konnte er individuelle Anpassungen hineinprogrammieren. Er kann diese Software nur noch nutzen und sich darauf verlassen, dass der Hersteller diese nach seinen Bedürfnissen und Vorstellungen funktionstüchtig erstellt hat.

Die weitere Entwicklung führte zu immer komplexeren Betriebssystemen und umfangreicheren Anwendungsprogrammen, aber auch zu einer Ausdünnung der Auswahl vergleichbarer Anwendungen. Es entwickelte sich ein Quasi-Standard, dominiert durch die Marktmacht einzelner Firmen. Ein Quasi-Standard bedeutet, dass die Mehrzahl der Anwender mit den Produkten weniger Hersteller arbeiten und somit ihr Wissen und ihre Erfahrungen speziell geprägt sind. Hieraus entwickelt sich eine Eigendynamik, da dieses eigene Know-how weitergegeben und auch erwartet wird, sei es durch die Weitergabe von Dateien in speziellen Formaten, den Austausch von Informationen oder durch "Expertengespräche".

Die Mehrzahl der Software-Nutzer sehen heute in der Software eben auch "nur" ein Arbeitsmittel und wollen sich gar nicht mit den Details der Datenverarbeitung und "EDV-spezifischem Kram" herumärgern, sondern sie als Teil ihres Arbeitsprozesses verstehen, und da muss sie Ergebnisse liefern, wie andere Arbeitsmittel beispielsweise Papier und Bleistift auch.

Um dieses zu gewährleisten, muss eine Austauschbarkeit der Dateien (Kompatibilität) sowohl innerbetrieblich als auch extern gewährleistet sein, ja sogar im privaten Bereich wird die Austauschbarkeit von Dateien und Daten immer wichtiger. Dieses Verhalten führt dann aber in der Konsequenz zu einer Verstärkung des Quasi-Standard Effektes, mit der Folge, dass heute ca. 90 % der PC-Systeme (am Arbeitsplatz und privat) mit Microsoft-Produkten (Betriebssystem und Office-Programmen) betrieben werden. Lediglich bei spezialisierten Aufgaben findet sich noch eine nennenswerte Anzahl anderer Konstellationen.

Wesen freier Software

Nach diesem kurzen – und zugegebenermaßen unvollständigen – Exkurs in die Geschichte der Datenverarbeitung interessiert natürlich hier schon die Frage: "Was ist eigentlich freie Software?".

Es wäre zu einfach und faktisch falsch, zu sagen: "Freie Software ist kostenlose Software", auch wenn die Software häufig tatsächlich ohne Kosten zu beziehen ist. Nein, der Begriff "freie Software" wird viel weiter gefasst und interpretiert.

Falsch ist auch die Annahme, freie Software würde niemanden gehören, sei also quasi "frei". Auch freie Software "gehört" dem Urheber, mit allen Rechten und Pflichten. Nur er kann ursächlich bestimmen, was mit seinem Produkt geschieht.

Dies ist auch der Grund, warum aus dem englischen "free software" 1998 der Begriff "Open Source" wurde und sich dieser Begriff heute durchgesetzt hat.

"Open Source" (was wörtlich übersetzt "offene Quelle" heißt) grenzt sich insofern ein bisschen vom Begriff "free software" (freie Software) ab, als dass er nicht nur die vermeidliche oder tatsächliche Zweideutigkeit der Wortkombination mit "free" umgeht – "free", kostenlos, umsonst wird auch in Zusammenhang mit materiellen Gegenständen wie "Freibier" etc. verwendet, aber eben auch im übertragenen Sinn im ideellen Bereich für "freies Denken", "freie Rede" und so weiter –, sondern auch einen wesentlicheren Aspekt der "freien Software" stärker betont, den offenen Quellcode. Anders als in angelsächsischen Ländern gibt es in Deutschland keine erkennbare Wandlung des Begriffes, sieht man einmal davon ab, dass auch hierzu Lande eigentlich die englischen Ausdrücke gang und gäbe sind. Insofern gilt für den Rest dieses Buches:

Sprachvereinbarung: Der Begriff "Open Source Software" wird übersetzt und synonym genutzt als "freie Software".

Nun ist allerdings Quelloffenheit eine notwendige, nicht aber hinreichende Voraussetzung für freie Software. Man denke zum Beispiel an die Möglichkeit, den Quellcode einer Software zwar einsehen zu können, aber keine Veränderungen daran vornehmen zu dürfen. Dies würde dem Gedanken hinter dem Begriff "Open Source" nicht gerecht.

Heute definiert man vier Eigenschaften, der freie Software genügen muss, um als solche benannt zu werden:

1. Die Software darf ohne Einschränkungen benutzt werden.
2. Der Quellcode freier Software ist verfügbar. Er darf zitiert und aus ihm darf gelernt werden.
3. Sie darf ohne Einschränkungen und ohne Zahlungsverpflichtungen kopiert und weitergegeben werden.
4. Sie darf verändert und in veränderter Form weitergegeben werden.

Erst diese Definition der Merkmale schaffte auch die Umgebung und Voraussetzungen, freie Software-Projekte auf der Basis einer offenen, kooperativer Entwicklung und unter starker Beteiligung der Anwender zu realisieren. In diesen Projekten sind die beteiligten Entwickler in der Regel nicht auf der Basis von Verträgen (im Sinne von Arbeitsvertrag) gebunden und somit auch frei von Direktiven. Ein solcher Prozess wird natürlich auch durch die starke Verbreitung des Internets gefördert, da dadurch auch die räumliche Nähe der Beteiligten keine notwendige Beschränkung mehr darstellt.

Nach der Definition der Merkmale freier Software soll jetzt noch eine Begriffsbestimmung häufig zu lesender oder ähnlich klingender Bezeichnungen zur Information erfolgen:

Erkennbar ist, dass der Quellcode eine entscheidende Rolle bei der Definition und der Abgrenzung von freier Software spielt: dieser muss verfügbar sein.

Der Quellcode stellt die gesammelten, von Menschen geschriebenen Anweisungen und Befehle an einen Computer und/oder an seinen Prozessor dar und ist somit Ausdruck und Spiegelbild der Kreativität eben jener Programmierer. Da der Code in der Regel nicht in einer Form geschrieben wird, mit der die Maschine direkt etwas anfangen könnte – wie dies beispielsweise mit Assembler Code möglich wäre –, sondern in einer so genannten Hochsprache wie beispielsweise C, C++ oder Java, ist er relativ einfach zu lesen und zu verstehen. Bevor das Programm jedoch eingesetzt werden kann, muss es erst an die Hardware und eventuell auch an das Betriebssystem angepasst und in einen maschinenlesbaren Code umgewandelt werden. Dies geschieht durch ein spezielles Programm, den Compiler, der entstehende Code wird auch "Binary Code" oder kurz "Binarys" genannt. Ist der Code erst einmal kompiliert, ist es nahezu unmöglich, diesen noch zu lesen oder den ursprünglichen Quell-Code zu rekonstruieren. Es gibt zwar inzwischen Verfahren, die dieses versuchen, der Aufwand an Zeit ist jedoch nahezu ebenso groß wie es dauern würde, den Code komplett neu zu schreiben.

Proprietäre Software wird ausschließlich als kompiliertes, ausführbares Programm für eine bestimmte Umgebung (Prozessortyp, Betriebssystem) vertrieben und der zugrunde liegende Quellcode wird als eines der wichtigsten Firmengeheimnisse und -Ressourcen angesehen. Die entsprechenden Lizenzbedingungen verbieten explizit Änderungen des Programmcodes, in der Regel sogar den Versuch, Teile des Programmcodes oder alles zu dekompilieren, um die Quellen zu verstehen.

Im Gegensatz dazu ist es das Wesen "freier Software", dass jeder, der möchte, die Gelegenheit hat, aus dem Programmcode zu lernen und daraus eigenen Code zu entwickeln. "Open Source" bedeutet also, dass das bereits vorhandene Wissen, die Kreativität und das – ideelle - Gedankengut nicht abgekapselt und vor anderen Menschen verborgen wird, sondern dass diese Informationen eben >frei< sind, frei für andere, daraus und damit zu lernen, sich selbst einzubringen und somit das Wissen zu vermehren. Diesem Ansatz liegt eben zu Grunde, dass Informationen und Wissen aus sich heraus grundsätzlich nicht auf einige wenige beschränkt werden darf, sondern der Menschheit selbst dient und somit für alle verfügbar sein sollte.

Nicht verwechseln darf man aber die Freiheit der Information und die daraus abgeleitete Offenheit des Quellcodes mit dem Verzicht auf Eigentum des Gutes. Auch "Open Source" beziehungsweise "freie Software” ist nicht frei von Eigentum, sie gehört nicht "niemanden" und wäre somit rechtefrei. Selbstverständlich bleiben die Urheberrechte" der Autoren bestehen und nur diese selbst können bestimmen, wie Ihre Code-Teile verwendet und weiterverarbeitet werden. Damit dieses aber praktikabel wird, gibt es bestimmte Regeln, die in Open Source-Projekten gelten, und Lizenzbedingungen, die von jedem Autor übernommen werden.

Der offene Quellcode aber kann gelesen und als Anregung für eigene Ideen und Verbesserungen genutzt werden, das Wissen ist also quasi "öffentlich", so wie Lehrbücher und Nachschalgewerke. Mit dem vorhandenen Wissen in Kombination mit der eigenen Kreativität entsteht neues Wissen, ohne dass fundamentale Erkenntnisse neu erfunden werden müssen. Offene Quellen beschränken die Aktivitäten auf neue, kreative Problemlösungen, halten also den Kopf frei für wichtige Aufgaben und minimiert die Zeit, Routinetätigkeiten durchzuführen. Stellen Sie sich vor, sie möchten ein aktuelles Programm schreiben, das auf einer der aktuellen grafischen Oberflächen laufen soll, dann haben sie weder Lust noch Zeit, sich intensiv damit zu beschäftigen, wie denn so ein Fenster auf den Bildschirm "gezeichnet" wird, wie ein Button erstellt wird und so weiter. All diese Aufgaben wurden ja schon vor Ihnen gelöst und haben mit Ihrer eigentlichen Aufgabenstellung nur wenig bis gar nichts zu tun. Also möchten sie auch nicht Zeit und Ressourcen in die Entwicklung dieser Fenstertechnik investieren, sondern sich auf Ihre – hoffentlich neue – Aufgabenlösung konzentrieren.

Selbstverständlich stellen Ihnen heute auch proprietäre Produkte (wie zum Beispiel Microsoft mit dem "Windows-Desktop") entsprechende Schnittstellen und Bibliotheken zur Verfügung, denn schließlich erhöht jede Lösung auch die Attraktivität der eigenen Produkte und – das ist mindestens genauso wichtig – funktionieren diese Schnittstellen auch nur mit eigenen Produkten! Nur – auch diese Schnittstellen und Routinen sind ja nicht "frei", sondern als fertiges Produkt zu verwenden, eben so, wie "sie sind". Änderungen sind nicht möglich, Anpassungen – die vielleicht sogar sinnvoller oder besser wären – nicht durchzuführen.

Lägen die Quelle aber offen, könnte jeder Programmierer den Code nutzen, so weit dies seinen Vorstellungen entspricht und denselben dort optimieren, wo er in der Lage dazu ist, es zu tun, und wo er es als sinnvoll und nützlich ansieht. Ein freier Code ist also eigentlich nie statisch, sondern wächst und verändert sich dynamisch, je nach den Aktivitäten von Nutzern und Programmierern.

Erstmals taucht hier der Begriff des Nutzers auf. Inwieweit hat der Nutzer eigentlich Einfluss auf die Entwicklung eines Programms und wieso kann auch er den Code verändern?

Die Abgrenzung zwischen Nutzer und Programmierer ist schnell gezogen: Ein Programmierer erstellt mit seinem Wissen und mit seiner Kreativität ein Software-Programm (oder Teile davon), ein Nutzer verwendet das Ergebnis dieses Programmierprozesses (das Programm) im Rahmen seiner Tätigkeit, sei es beruflich oder privat. Im Grunde kann es dem Benutzer egal sein, wie das Programm im Hintergrund arbeitet, Hauptsache es liefert das gewünschte Ergebnis, den gewünschten Erfolg. Der reine Nutzer hat also bei erster Sichtweise keinen erkennbaren Vorteil von "Open Source"-Programmen, da er weder in der Lage ist, den Quellcode zu lesen, noch diesen aktiv zu verändern. So weit zur Theorie und zur Abgrenzung.

Praktisch sieht die Welt jedoch anders aus. Erst einmal ist jeder Entwickler auch Nutzer und nicht selten sind es gerade die Bedürfnisse und Anforderungen als "Nutzer", die Programmentwicklungen anstoßen. Weil eben eine bestimmte Aufgabenstellung nicht oder nicht optimal zu lösen ist, weil man sich selbst eine Arbeitserleichterung verschaffen möchte oder – manchmal auch – aus schierem Wettbewerbsdenken heraus eben der "Bessere" zu sein, das sind die Motive, Entwicklungen zu beginnen. Und ist die Lösung erreicht, wird diese auch an andere Nutzer weitergegeben (sei es als "Open Source"- oder als proprietäre Software).

Der "reine" Nutzer dann gibt wiederum "Feedback" – Rückmeldungen – an die Entwickler. Entweder direkt durch Kommunikation –  mündlich, schriftlich, per E-Mail etc. – oder eben indirekt (durch Kauf oder Nichtkauf), auf jeden Fall erhält der Entwickler durch die Nutzer Hinweise über gewünschte oder notwendige Anpassungen oder Verbesserungen und natürlich über auftretende Fehler.

Je enger also ein Kontakt zwischen Nutzer und Entwickler geknüpft werden kann, umso besser wird die Software. Jeder Nutzer hat somit durchaus einen enormen Einfluss auf die Entwicklung und Weiterentwicklung eines Programms, auch wenn er selbst nicht in der Lage ist, Codezeilen zu lesen oder beizusteuern.

Nun sind natürlich "Nutzer" und "Entwickler" die beiden Pole einer breiten Mischzone, und viele Anwender befinden sich irgendwo zwischen diesen beiden Extrempunkten. Systemadministratoren beispielsweise sind zwar selten "Hardcore-Programmierer", müssen aber ihre Arbeitsumgebung dennoch mit Programmanpassungen, Skripten und kleinen Progrämmchen optimieren. Versierte Anwender schreiben schon mal ein kleines Hilfstool, nutzen Skripttechniken oder programmieren sogar ganze Firmenanwendungen. Alle diese profitieren von offenen Quellcodes, da nur dieser freie Zugang es ermöglicht, Anpassungen, Fehlerbehebungen, Ergänzungen oder Veränderungen selbst durchzuführen.

Wie funktioniert Open Source?

"Nachdem die Merkmale quelloffener Software und die ideellen Hintergründe derselben angesprochen wurden, stellt sich natürlich die praktische Frage: Wie funktioniert das denn nun eigentlich?

Open Source-Projekte beginnen meist mit der Erkenntnis irgend eines Nutzers oder Entwicklers, dass er ein Problem hat beziehungsweise einen Missstand beheben möchte. Entweder gibt es kein ideal passendes Produkt zur Problemlösung oder bestehende Varianten haben so viele Einschränkungen und Begrenzungen, dass sie nur suboptimal ist. Dieser Spannungskreis zwischen gewünschter (und vorstellbarer) Problemlösung und existierenden Antworten gibt die Antriebskraft, selbst eine Lösung zu erstellen. Der Startpunkt ist also weder eine Direktive eines Vorgesetzten noch das Ergebnis ausgeklügelter Marktstudien oder Verbraucherbefragungen, sondern das tatsächliche Empfinden eines Missstandes beim Initialentwickler.

So entstand beispielsweise Linux aus der Idee des finnischen Informatikstudenten Linus Torvalds, der das Betriebssystem UNIX auf seinen 386-PC laufen lassen wollte. Das einzige damals verfügbare System war ein "abgespecktes" Unix-System Namens "Minix", das jedoch den Anforderungen von Torvalds nicht genügte. Also begann er selbst ein Betriebssystem zu entwickeln, nannte diese "Linux" und stellte es schon bald im Internet öffentlich zur Verfügung. Heute programmieren viele tausend Entwickler weltweit an Details dieses Systems und es hat sich zu einem ernst zu nehmenden Konkurrenten von Microsofts "Windows" entwickelt.

Open Source-Projekte entwickeln sich also nach der Initialzündung einiger weniger Personen dynamisch und ohne hierarchische Strukturen. Jeder macht genau das, was ihm Spaß macht und/oder er macht das, worin er eine Notwendigkeit oder einen Nutzen sieht. Open Source-Projekte benötigen eine sehr offene Kommunikation, deren Voraussetzungen heute durch das Internet bestens gegeben sind, und ein klares Ziel, um Menschen zum Mitmachen zu begeistern. Open Source-Software entsteht aus eigenmotivierter Tätigkeit, angetrieben von dem Wunsch, ein spezielles Problem zu lösen oder aus dem Ehrgeiz, ein spezielles Ziel (meist ideeller Art ) zu erreichen, wie zum Beispiel "das vollkommen freie Betriebssystem" (GNU-Projekt) oder "die beste Office-Suite" (das OpenOffice-Projekt).

Der Mangel an hierarchischen Strukturen wird bei wachsender Anzahl aktiver Programmierer in der Regel durch ein so genanntes "Core-Team" ersetzt, welches die zentrale Steuerung des Projektes übernimmt. Mitglieder dieses Teams werden gewählt und sind dann Ansprechpartner für eine bestimmte Aufgabengruppe, ohne jedoch leitende oder entscheidende Funktionen auszuüben. Dieses Projektteam kann man auch als "inneren Kern" des Projektes bezeichnen, wobei das Verbleiben im Team einzig und alleine von den Mitgliedern selbst abhängt. Da die Tätigkeit in Open Source-Projekten in der Regel unbezahlt ist und während der Freizeit stattfinden, muss jedes Mitglied für sich selbst entscheiden, wie viel Zeit er investieren kann und möchte. Kann es sich nicht mehr wie gewünscht um das Projekt kümmern, so wird er selbst aus dem inneren Kreis zurücktreten und andere werden nachrücken.

Neben dem eigentlichen Projektteam existiert auch immer noch eine so genannte Community. Die Community umfasst all die Leute, die temporär und in den verschiedensten Bereichen punktuell mitarbeiten. Ohne diese Gemeinschaft" würde ein Open Source-Projekt nicht bekannt und meist auch nicht interessant werden. Die Gemeinschaft steuert kleine Programmhäppchen bei, testet Software und Releases, verfasst Erfahrungsberichte, bietet Hilfe und Support, beantwortet Fragen, kümmert sich um Marketing und Öffentlichkeitsarbeit, kurz um: füllen das Projekt mit Leben!

Sehr interessant ist übrigens, dass genau diese Struktur auch zum Scheitern von Open Source-Projekten führen kann oder zumindest zur Teilung. Wenn nämlich die Richtungen der Weiterentwicklungen zwischen den Hauptentwicklern so weit auseinander liegen und eine Einigung über den zukünftigen Weg nicht zu erreichen ist, dann kommt es zum so genannten "Code-Forking", das heißt das Projekt teilt sich und es bilden sich neue Projekte aus den unterschiedlichen Richtungen.

Gut zu beobachten war dieses Phänomen bei der Entwicklung eines freien Unix-Systems, dem BSD-Projekt. Dieses Projekt teilte sich zweimal und somit haben wir heute drei verschiedene, freie BSD-Projekte (FreeBSD, NetBSD und OpenBSD – siehe auch Kapitel 2, Unix Betriebssysteme). Eine solche Entwicklung ist übrigens nicht unbedingt als negativ anzusehen, erfüllen doch alle drei Varianten in jeweils einem eigenen Spezialgebiet ihre Aufgaben bestens. Es kann aber auch bei zu häufiger Teilung zu einer Atomisierung der Community kommen und damit auch schnell zum Ende des Projektes.

Open Source-Projekte leben von der Kommunikation, von dem Informationsaustausch zwischen allen Mitgliedern der Community und den Entwicklern, den Nutzern und Anwendern. Typischerweise wird heute diese Kommunikation ausschließlich über das Internet geführt. Mailinglisten verteilen die Informationen an alle Beteiligten, Internetseiten geben Auskunft über alle wichtigen Aktivitäten und Features und bieten die aktuellen Software-Releases direkt zum Download an. Archive dienen zum Sammeln von früheren Informationen und Foren zum aktuellen Diskutieren. Ein Wesen der Open Source-Projekte ist ja gerade die möglichst breit angelegte freie Kommunikation, unzensiert, ungefiltert. Jeder kann Fehler melden, Fragen stellen, Anregungen geben, Ideen weitergeben, aber auch Antworten formulieren, Hilfe geben, Codefragente beisteuern. Gerade durch die Breite und offene Kommunikation werden (Programm-, aber auch Verständnis-)Fehler schneller behoben, markt- und anwendungsnahe Applikationen besser erstellt und gleichzeitig aktuellen Trends schneller angepasst.

Open Source-Projekte leben also auch von dem Wandel, und dieser ist oft sehr viel schneller und dynamischer als bei proprietären Systemen. Die sofortige Einarbeitung von Fehlerberichten und die offene Kommunikation bewirken diese Dynamik mit, aber natürlich auch die Kreativität der vielen, unterschiedlich beteiligten Personen. Daraus folgt dann die Aussage:

Freie Software ist kein Produkt, sondern ein Prozess

Open Source-Software wird also heute überwiegend nicht als Produkt gesehen, sondern als Prozess, als ein dynamisches, sich ständig änderndes Gebilde. Anders als ein proprietäres Produkt, dass zu einem bestimmten Termin "fertig" ist und dann auf den Markt kommt – sieht man einmal von meist schon kurz danach folgenden "Fehlerpatches" und "Servicepacks" ab – ist eine Open Source-Software eigentlich nie fertig. Die Entwicklung geht immer weiter und wird das Programm verbessern, verändern. Wenn also von Open Source-Software gesprochen wird, muss immer unterschieden werden zwischen dem Projekt an sich (der Prozess) oder der aktuell eingesetzten lauffähigen Software (Release), die eine Momentaufnahme zu einem bestimmten Zeitpunkt darstellt.

Gerade in den Startphasen von Open Source-Projekten kann es zu sehr häufigen Releases (monatlich, wöchentlich, ja sogar täglich) kommen. In der Regel werden jedoch in regelmäßigen Abständen so genannte stabile "Major-Releases" veröffentlicht, mit denen man produktiv arbeiten kann und die den aktuellen Stand des Entwicklungsprozesses widerspiegeln. Diese Versionen sind dann eigentlich schon wieder mit einem Produkt vergleichbar und bilden die Grundlage für die große Mehrzahl der normalen Nutzer, die diese Software eben als Arbeitsmittel für ihre eigene Arbeit einsetzen und nutzen wollen.

 Nachdem nun ausgiebig über den Quellcode gesprochen wurde, noch ein paar Sätze zu den Kosten. Wenn der Quellcode frei verfügbar ist, dann ist es eigentlich die logische Konsequenz, dass auch das "Programm" kostenfrei erhältlich sein sollte. Hier muss jedoch zunächst auf die Definition des Begriffes der "Kosten" eingegangen werden. Typischerweise verstehen wir heute unter den "Kosten" den Preis eines Produktes, den wir bezahlen müssen, um das Produkt zu erhalten, beziehungsweise, um es benutzen zu können und damit eigen Vorteile zu erzielen (zum Beispiel eine Erhöhung meiner Arbeitsproduktivität). Je wertvoller ein Produkt für mich ist – also je höher mein eigener Vorteil durch das Produkt sein wird oder je höher ich den erwarteten und vermeintlichen Vorteil einschätze – umso höher wird der Preis sein, den ich für das Produkt zu bezahlen bereit bin. Aus dieser Relation entwickelt sich oft auch ein Umkehrschluss: Je teurer ein Produkt ist, umso mehr Vorteile und Nutzen wird es haben. Diese Erwartung der Verbraucher (oder Nutzer) führt dann zu der Erkenntnis, dass Produkte, die nichts kosten auch nichts wert sind. Gerade in Unternehmen wird häufig ungläubig die Frage gestellt, wieso denn ein "so gutes Produkt umsonst zu haben sei" (eine typische Aussage aus meiner Beratungspraxis, wenn ich als Alternative zu dem überall verbreiteten MS Office Paket die freie Office-Suite OpenOffice.org empfehle und vorstelle).

Es ist also durchaus sinnvoll, sich einmal Gedanken zu machen, wie ein Preis beziehungsweise wie sich die Kosten eines Software-Produkts zusammensetzen und wieso Open Source-Software so günstig zu haben ist.

Nehmen wir eine Firma, die proprietäre Software herstellt und diese als Boxversion verkauft. Wie setzt sich der Preis dieser "Box" zusammen:

• Da wären zunächst die Lohnkosten der angestellten Entwickler, die das Programm programmieren.
• Hinzu kommen die Lohnkosten der sonstigen Angestellten der Firma (Administration, Verwaltung, Vertrieb, Buchhaltung ...).
• Dann sind da die typischen Betriebskosten wie Miete, Arbeitsmittel (Computer, Literatur, Programme ...), die Einrichtungsgegenstände, Porto, Telefonkosten und vieles mehr.
• Natürlich kommt auch ein Unternehmensgewinn hinzu, es ist ja ein Wirtschaftsunternehmen.
• Dann die eigentlichen und direkten Herstellkosten, also die Erstellung der CDs oder Disketten, das Handbuch, die Box und was sonst noch dazugehört.
• Dann folgen die Vertriebskosten: Werbung, Händlerprovisionen, Rabatte, Verpackungs- und Versandkosten.
• Und, da es sich um ein "Produkt" handelt, müssen natürlich auch Garantie- und Reklamationskosten mit berücksichtigt werden. Schließlich muss ein Hersteller für seine Produkte geradestehen.
• Noch was vergessen? Natürlich! Wir als Nutzer brauchen bestimmt irgendwann und irgendwie mal Hilfe bei der Bedienung und Nutzung des Programms. Also müssen auch – zumindest anteilig – Supportkosten mit einberechnet werden.
• Und auf all das folgen dann noch die entsprechenden staatlichen Abgaben, sprich Steuern oder Ähnliches.

Sie sehen, da kommt eine ganze Menge zusammen, das den Preis eines (Software-)Produktes ausmacht. Und dabei haben wir einen (wichtigen) Punkt noch gar nicht berücksichtigt: Lizenzkosten. Die vielen oben aufgeführten Punkte bezeichnen überwiegend materielle, sprich greifbare Kosten. Die geistige Arbeit der Entwickler, ihre Kreativität, wurde dabei noch gar nicht als "wertschöpfend" separat erfasst. Und dabei ist ja genau dieses das Kapital der Software-Firmen. Also, vergessen Sie nie, dass neben den direkt zuordenbaren Kosten immer noch die "immateriellen" Kosten kommen, quasi die Nutzungsgebühr für die kreativen Ideen der Entwickler! Genau diese Lizenzgebühr verbietet es Ihnen, proprietäre Software, die Sie einmal als "Box" erworben haben und damit ja eigentlich die direkten Kosten "bezahlt" haben, auf verschiedenen Rechnern zu installieren und zu nutzen. Mit dem Kauf der Box haben sie lediglich das Recht erworben, das Programm auf einem Arbeitsplatz (oder auf einem Rechner) eventuell sogar nur für eine begrenzte Zeit zu nutzen, mehr erlauben die Lizenzbedingungen oft nicht. Die Information, das Wissen, wird somit zum Produkt, limitiert und nicht frei.

Open Source-Software geht hier eben einen anderen Weg. Sie stellt das Wissen und die Information als "frei" zur Verfügung, verzichtet völlig auf Lizenzkosten für genau dieses Wissen und erklärt dasselbe für Allgemeingut. Nicht im Sinne des Eigentums, sondern im Sinne der Nutzung, der Weiterverwendung. Jeder darf sich des Wissens bedienen und es für seine eigenen Zwecke verwerten und gebrauchen. Das Wissen ist quasi "öffentlich". Nun ist ja aus dem "Wissen" noch kein Produkt geworden, das direkt genutzt und verwendet werden kann wie beispielsweise eine proprietäre "Box"-Software, es fehlt also noch ein Schritt.

Man nehme ein beliebiges Open Source-Projekt und erinnere sich an das vorher gesagte: Das Projekt stellt die Quellen der Software frei zur Verfügung, den Quellcode. Nur – mit dem Quellcode kann eigentlich ausschließlich ein Entwickler oder ein sehr fundierter Anwender etwas anfangen. Für den normalen Nutzer ist ein ausführbares Programm (Binary) passend für seine aktuelle Hardware-Umgebung und am besten mit einem (gedruckten) Handbuch von Nöten. Zwar könnte er aus dem vorhanden und verfügbaren Quellcode mit Hilfe entsprechender Compiler den für sein System passenden Programmcode erzeugen, doch das dürfte die Fähigkeiten der meisten Nutzer bei weitem übersteigen. Es bietet sich also an, dass irgendjemand – und der darf durchaus wirtschaftliche Ziele verfolgen – diese Aufgaben übernimmt und dem Endnutzer ein Produkt (eine Box-Version) anbietet. Diese Box-Version wird – und das ist auch Praxis – Geld kosten. Der Preis setzt sich ähnlich zusammen wie vorher aufgeführt, es entfallen jedoch gänzlich die "Lizenzkosten".

Denken Sie zum Beispiel an Linux. Die Quellen von Linux kann man ohne weiteres (kosten-)frei aus dem Internet herunterladen und dann passend zu Ihrer Systemhardware kompilieren. Man kann aber auch Box-Versionen großer Distributoren (wie SuSE, Red Hat oder Caldera) kaufen, die diese Kompilierung schon vorgenommen haben, dem Kunden ein Handbuch mitliefern und ein paar zusätzliche Features eingebaut haben. Man kann das Produkt (und zu einem solchen ist es jetzt geworden) direkt einsetzen und nutzen.

Die folgende Grafik verdeutlicht noch einmal diese Möglichkeiten:

Wege der Software zum Nutzer

"Freie Software" ist also keineswegs per Definition "kostenlos", lediglich – aber das ist ein entscheidender Vorteil – lizenzkostenfrei. Das heißt, man braucht für die Nutzung der Software in keinem Fall an irgendjemanden Lizenzkosten bezahlen, man kann die Software nutzen wie und wo man will, kopieren, verteilen, auf verschiedene Computer installieren und so weiter und so fort.

Je nach gewünschter Komfortstufe des nutzfähigen Produktes kann es aber durchaus zu Transferkosten oder Beschaffungskosten für die erstmalige oder auch wiederholte Beschaffung eines Open Source-Programms kommen. Dies widerspricht nicht dem Wesen freier Software. In der Praxis allerdings ist es durchaus üblich und meist auch praktikabel, dass Mitglieder der Community oder sogar des inneren Kreises eines Projektes in regelmäßigen Abständen auch direkt nutzfähige, übersetzte und kompilierte Codes (Binaries) für die gängigsten Hardwarekombinationen erstellen und diese zum Download frei im Internet anbieten. Dann fallen lediglich Transfer-Kosten (Kosten der Download-Verbindung) an, welche in der Regel vernachlässigbar sind. Allerdings beginnt bereits hier eine juristische Grauzone, die nicht vernachlässigt werden darf.

Nach allgemeiner Rechtsauffassung haftet nämlich der Hersteller eines Produktes auch für dieses. Das heißt, er gewährt einen entsprechenden Nutzen und kann dafür auch in Anspruch genommen werden, sei es durch Gewährleistung, durch Anforderung von Supportleistungen, durch die Notwendigkeit Dokumentationen mitzuliefern oder durch selbst initiierte Nachbesserungen zum Beispiel zur Gefahrenabwehr. Und das ist unabhängig vom Preis des Produktes, also auch unabhängig davon, ob möglicherweise das Produkt überhaupt nichts kostet, also quasi "verschenkt" wird.

Hier steckt eben ein Dilemma der ganzen Open Source-Szene. Auf der einen Seite wird ein Quellcode entwickelt und veröffentlicht, der einen echten Nutzwert für eine große Anzahl von Menschen darstellt beziehungsweise darstellen könnte, und jeder Beteiligte am Projekt ist durchaus daran interessiert, möglichst viele Nutzer der Software zu finden. Auf der anderen Seite ist "Open Source" eben ein Projekt und kein Produkt. Ein Projekt, an dem viele Freiwillige in einer selbstgewählten Kooperation zusammenarbeiten ohne einen entsprechend für alles Verantwortlichen zu haben, in dem niemand die Haftung (im juristischen Sinn) übernehmen kann oder will, in dem auch keine "Gewinne" erzielt werden und die nicht teilhaben im klassischen Wirtschaftsprozess. Erst die Bereitstellung fertiger Programme (Releases) als kompilierte Datei lässt hier eigentlich ein Produkt entstehen, das aber auch wiederum gebraucht wird, um Nutzer überhaupt in signifikanter Anzahl zu gewinnen.

Lösungsansätze bieten hier die verschiedenen Lizenzmodelle (siehe auch folgenden Abschnitt), wobei es nach wie vor unterschiedliche Auffassungen im juristischen Fachkreisen gibt, ob diese Modelle tatsächlich einer strengen rechtlichen Prüfung im Einzelfall standhalten würden. Dies soll aber hier nicht weiter vertieft werden.

Vom Code zum Gedruckten

Einer der wesentlichen Unterschiede zwischen einer Box-Version proprietärer Software (oder auch von Box-Versionen freier Software kommerzieller Distributoren) war lange Zeit das "gedruckte Handbuch", quasi die Gebrauchsanweisung für das Programm. Dieses beschreibt auch für "Laien" verständlich die Schritte zur Installation des (erworbenen) Programms sowie die Arbeitsweise und die Funktionen desselben. Besonders wertvoll ist eine solche "Gebrauchsanweisung" für die Art von Nutzern, die den Computer und die darauf laufenden Programme als reines Arbeitsmittel verstehen und sich weder die Zeit nehmen wollen noch das Wissen hierfür haben, hinter die Kulissen zu schauen und sich intensiv mit der elektronischen Datenverarbeitung und mit Programmierung zu beschäftigen. Sie wollen das Programm einfach nutzen, und da muss es so einfach wie möglich sein. Verständliche Schritt für Schritt-Anleitungen sind hier nicht nur hoch willkommen, sondern unbedingt nötig.

In Open Source-Projekten ist die Dokumentation immer ein "Stiefkind". Echte Programmierer können genialen Code schreiben, Probleme mit wunderbaren Algorithmen lösen, sie tun sich aber schwer, dieses in allgemein verständlicher Form zu dokumentieren. Und da im Projekt jeder nur das tut, was ihm Spaß macht und wozu er gerade Lust hat, fehlen häufig eben die Dokumentationen. Zwar wird eine gut funktionierende Community versuchen, diesen Missstand aufzuarbeiten und nach Möglichkeit entsprechende Unterlagen zu erstellen und diese dann zu veröffentlichen, aber es wird immer dem Nutzer obliegen, sich die entsprechenden Informationen in eigener Initiative zu beschaffen, in der Regel durch Recherche im Internet (-> vergleiche auch: Abschnitt 1.3 Typische Quellen). Hat ein Open Source-Projekt erst einmal eine signifikante Verbreitung erfahren, gibt es auch bald Drittliteratur, die dann die oft dürftigen oder fehlenden Handbücher ersetzen oder zumindest ergänzen. Allerdings sind diese in der Regel kommerziell verlegt und haben somit ihren Preis.

In neuerer Zeit übrigens schrumpft die Differenz von proprietärer Box-Software zu Releases von freien Software-Projekten in Bezug auf die Dokumentation. Auch proprietäre Software verzichtet mehr und mehr auf gedruckte Handbücher. Oft befindet sich in der gekauften "Box" nur noch eine Menge Luft und eine CD, die neben dem Programm selbst auch noch eine elektronische Dokumentation enthält. Begründet wird dies oft mit den zu hohen Kosten für das (gedruckte) Handbuch und der zu kurzen Lebensdauer. Denn auch bei der kommerziellen Software hat sich ein recht kurzer Versions-Zyklus von ca. einem Jahr eingestellt.

Die Akzeptanz und die Verbreitung von Open Source-Software hängt also ganz wesentlich von der Verfügbarkeit von entsprechenden Dokumentationen ab. Einen kleinen Schritt liefert ja auch genau dieses Buch und fördert somit hoffentlich die Verbreitung von freier Software. Ansonsten kann man davon ausgehen, dass eine aktive Community auch ausreichend Dokumentationsmaterial erstellt und dieses öffentlich zugänglich macht.

Ein weiteres leidiges Thema: Hilfe!

Eine gute Dokumentation ist das eine, aber was, wenn ich als Nutzer einmal nicht weiterkomme? Wenn sich das Programm partout nicht installieren lassen will? Wenn irgendeine Funktion nicht so arbeitet, wie angegeben oder erhofft? Als Nutzer soll das Programm mir zu Diensten sein; selbst auf Fehlersuche gehen kann ich kaum. Also – wo und wie bekomme ich Hilfe?

Beim Kauf von proprietärer Software ist in der Regel zumindest ein Installationssupport inklusive, das heißt, es gibt eine Stelle, die dem Nutzer in solchen Fällen mehr oder weniger kompetent weiterhilft. Dem Nutzer (und Käufer) stehen ebenfalls Rechte gegen den Verkäufer und gegen den Hersteller aus dem Wesen des Kaufvertrages zu, das heißt, er kann eine zugesagte Leistung auch einfordern, auch wenn dieses Recht oft ins Leere verläuft. Durch die Komplexität heutiger Computerkonfigurationen und das Zusammenkommen unterschiedlichster Produkte ist es oft nicht einfach, den tatsächlichen Problemkandidaten zu identifizieren. Hersteller schieben gerne die Schwierigkeiten immer auf gerade die anderen Komponenten und können somit nicht oder nur eingeschränkt helfen. Den Ärger (und den Aufwand) hat aber in der Regel immer der Kunde, sprich der Nutzer der Software.

Open Source-Software macht es sich hier viel einfacher: Es gibt keinen Support! Jedenfalls nicht so direkt. Da sich freie Software als Projekt und nicht als Produkt versteht, entfällt auch die Notwendigkeit, Supportleistungen anzubieten beziehungsweise vorzuhalten. Das Projekt bietet den Quellcode, was der Nutzer daraus macht, ist seine Sache. Diese "Freiheit" gewährt das Projekt, und die Nutzer können alle Änderungen vornehmen, die sie brauchen oder haben wollen, sie können alle notwendigen Anpassungen an ihrer aktuellen Hard- und Softwarekonfiguration durchführen, aber bitte, es ist ihre eigene Sache. Sie können niemanden hierfür verantwortlich machen, wenn es dann nicht so funktioniert, wie sie es sich vorgestellt haben, und niemanden zur Rechenschaft ziehen.

Und damit schließt sich wieder der Kreis. Um Änderungen vorzunehmen, müsste der Nutzer selbst versiert genug sein, viele sind dies aber nicht. Dennoch soll der normale Nutzer ja auch vom Programm profitieren und das Projekt wiederum von ihm, denn nur so wird es auch dynamisch fortgeschrieben. Also übernimmt die Community die Supportleistung in einer für sie akzeptablen Form und bietet jedem Interessierten Hilfe im Rahmen ihrer Möglichkeiten – auf freiwilliger Basis natürlich. Die Hilfe wird typischerweise im Internet beziehungsweise über das Internet angeboten und ist in den meisten Fällen sehr schnell und kompetent. Es wird also niemand alleine gelassen und der Support ist – entsprechend dem Wesen der Open Source-Projekte – in der Regel auch sehr breit angelegt. Das heißt, es gibt immer einen Experten und sei die Problematik auch noch so ungewöhnlich und die eingesetzte Hard- und Software noch so exotisch.

Darüber hinaus entwickeln sich natürlich bei entsprechender Verbreitung des Programms in gleichen Maße externe Dienstleister, die professionellen Support für eben diese Open Source-Software anbieten, deren Leistungen dann aber auch entsprechend bezahlt werden müssen.

Die verschiedenen Hilfe- und Supportangebote der freien Software-Projekte bieten auf der anderen Seite ein ideales "Feedback" – Kanäle für die engagierten Entwickler, die so schnell Schwachstellen und Bugs der Software mitbekommen, aber auch Wünsche und Anregungen der "Nutzer".

Ohne Support würde also auch die beste "freie Software" oder das beste Projekt früher oder später einschlafen, würde sich doch der Kreis der Nutzer und der aktiven Entwickler immer weiter verkleinern bis schließlich die verbleibenden Aktivitäten auf den Schultern von einigen wenigen Menschen lasten und irgendwann folgerichtig eingestellt werden.

Zielgruppen von Open Source-Software

Mit all diesen Rahmenbedingungen lassen sich dann auch die typischen Zielgruppen – aus Sicht eines Marketings, eines nutzenorientierten Ansatzes – durchaus identifizieren. Auch, wenn grundsätzlich aus dem Wesen freier Software-Projekte ja gerade so ein Ansatz gar nicht gewünscht und geplant ist, wird er immer dann interessant, wenn diese Projekte eben nicht aus der Sicht der Software-Entwickler betrachtet werden, sondern aus Sicht der Nutzer, der "reinen Konsumenten". Letztendlich hängt der "Erfolg" eines freien Software-Projektes eben doch vom Markterfolg ab, von der Verbreitung und Nutzung der Software und damit von der Größe der Community.

Das Internet ist voll von freien Software-Projekten, die irgendwann von engagierten Entwicklern begonnen wurden aber nie einen stabilen Release-Stand erreichen konnten und deren Weiterentwicklung seit Jahren stagniert, die Informationen auf dem Stand von vor ein paar Jahren verharren und somit – in unserer schnelllebigen Technikzeit – längst überholt und meist auch funktionsuntüchtig sind.

Werden also Open Source-Projekte nicht auch intensiv genutzt, stirbt die Dynamik, der Entwicklungsprozess. Damit aber kommt der Nutzergruppe wieder eine größere Bedeutung zu als dies ursprünglich von der Idee der freien Software her gedacht war. Open Source-Programme müssen also nutzertauglich sein, einfach installierbar und bedienbar und – Support muss gewährleistet sein.

Allerdings, jede Nutzergruppe stellt unterschiedliche Anforderungen, und so ist Open Source-Software für die einen interessanter, für andere eher weniger interessant.

Grundsätzlich gilt: Für alle, die sehr viel Ahnung vom Computern und Programmen (Programmierung) haben, ist "freie Software" immer sehr interessant. Diese Personengruppe zeichnet sich ja gerade dadurch aus, dass sie sowohl in der Lage als auch Willens dazu sind, ihre benutzten Programme optimal anzupassen und Schwachstellen oder Fehler selbst nachzubessern beziehungsweise zu beheben, und in proprietären Softwareprodukten nur Schranken, Barrieren und verbotene Zonen zu sehen. Diese Personengruppe, die oft in Administrationsbereichen von (größeren) Unternehmensnetzwerken zu finden ist, wird mit Open Source-Software immer dann arbeiten, wenn diese für sie eine Arbeitserleichterung darstellt und die entsprechenden oder gewünschten Anpassungen möglich und selbst durchführbar sind. Bestes Beispiel für den Erfolg einer Open Source-Software in diesen Bereich dürfte der Apache Webserver sein, der immerhin alle anderen proprietären Lösungen weit hinter sich gelassen hat und mit weit über 50 % Marktanteil das Internet beherrscht.

Weitere Benutzergruppen mit kurzer Charakterisierung:

Privatnutzer: Nachdem in mehr als 40 % der Privathaushalte (in Deutschland) heute schon ein Computer steht, ist dieses sicher die zahlenmäßig größte Gruppe. Allerdings lassen sich auch die Privatnutzer noch einmal in zwei Gruppen gliedern:  Die "Powernutzer" und die "Normalnutzer". "Powernutzer" können programmieren, passen sich ihren PC an, verstehen überdurchschnittlich viel von der Technik und sind den Administratoren vergleichbar. Der "Normalnutzer" verwendet den PC einfach, sei es zum Briefeschreiben, zum Spielen, zum Internetsurfen oder zu was auch immer.

Für den Privatnutzer muss Software funktionieren, einfach installierbar sein und stabil laufen. Und – am besten - wenig kosten.

Kleine und mittelständige Unternehmen (KMU-Betriebe): In dieser Gruppe wird der Computer als Betriebsmittel für die tägliche Arbeit benötigt. In der Regel ist kein oder nur wenig EDV Know-how vorhanden, ein spezieller Administrator ist nur bei größeren Unternehmen üblich. Die EDV wird meist von externen Dienstleistern (die in der Regel auch kleine Unternehmen sind) geliefert und installiert und diese werden auch bei Problemen kontaktiert. Ansonsten muss einfach alles funktionieren. Der Preis ist wichtig, aber er fällt hinter die Funktionalität zurück.

Große Unternehmen: Große Unternehmen mit vielen Hunderten oder Tausenden von Arbeitsplätzen stellen eine ganz andere Nutzergruppe dar. Hier muss die Software insbesondere funktionell und miteinander kompatibel sein, es werden andere und höhere Anforderungen an die Software in Bezug auf Sicherheit, Dokumentenaustauschbarkeit, Teamfähigkeit und so weiter gestellt und natürlich wird ein professioneller Support gefordert und erwartet. Der Preis (pro Lizenz) ist dabei eindeutig zweitrangig, die anderen Komponenten überwiegen. Planungssicherheit und Ausfallminimierung haben erste Priorität. Diese Unternehmen sind – zumindest was die normalen Arbeitsplätze betrifft – nach wie vor eine Domäne der großen, proprietären Software-Hersteller, denn nur diese können die geforderten Supportleistungen zeitnah und international erfüllen.

Für alle anderen Gruppen ist und wird Open Source-Software immer dann interessant, wenn Informationen darüber bekannt sind, die Funktionalität der Programme stimmt und wenn entsprechende Serviceleistungen (Support, Literatur, Sicherheit etc.) vorhanden sind.

Im Detail aber werden diese Faktoren und die Relevanz zu den Nutzergruppen noch in Abschnitt 1.4 – "Grundlagen der Konfiguration und Anwendungen für die Zielgruppe" besprochen.

Typische Quellen freier Software und Supportmöglichkeiten

Wie freie Software entsteht und was sie auszeichnet, all das wurde bereits erläutert. Hier stellt sich nun aber die Frage, wie kann man selbst sich in ein Projekt einbringen, wie erhält man Informationen und wie kann ich das Programm nutzen beziehungsweise, woher erhalte ich es?

Natürlich, diese Fragen sind nicht pauschal zu beantworten und die Antworten werden bei allen freien Software-Projekten auch mehr oder weniger unterschiedlich sein. Dieses einführende Kapitel soll aber die heute typischen Wege und Medien, die verwendeten Hilfsmittel und notwendigen Voraussetzungen in allgemeiner Form vorstellen, so dass der interessierte Leser das Rüstzeug mitbekommt, wie die praktische Handhabung von freien Softwareprojekten funktioniert und wie er an die entsprechende Software herankommt. Auch gibt es Hinweise, wie man sich selbst oder seine Arbeit in solche Projekte einbringen kann.

Alle großen Open Source-Projekte haben heute eine Gemeinsamkeit: Die Entwicklung und Verwaltung wird von einer Anzahl Personen getragen, die nicht lokal zusammensitzen, sondern oft international agieren und es somit große physische Entfernungen zwischen den einzelnen Mitgliedern gibt. Damit die Kommunikation und die Teamarbeit dennoch funktioniert, wird heute nahezu ausschließlich das Internet verwendet. Dieses bietet die Möglichkeit, weltweit und zeitnah zu kommunizieren, Dateien und Codeschnipsel zu sammeln und zu verwalten und auch wieder zu verteilen.

Gleichzeitig bietet das Internet die Basis, eine aktive, internationale Community aufzubauen und somit alle aktiven Nutzer und Entwickler zu vereinen. Ohne das Internet ist eine größeres Open Source-Projekt heute nicht vorstellbar.

Der typische Beschaffungsweg für freie Software ist somit der Weg ins Internet, dort auf die Homepage des Projektes und dann den Hinweisen und Menüs zum "Download" folgen. Das, was zunächst recht einfach erscheint, kann sich aber als durchaus kompliziert erweisen. Denn nicht immer ist der Download eines Programms so einfach wie das Laden eines fertig kompilierten exe-Programms unter Windows. Oft werden nur gepackte Versionen des aktuellen Quellcode-Standes angeboten, die der Nutzer dann selbst kompilieren und für sein Betriebssystem anpassen kann. Und spätestens hier wird es – zumindest für den typischen Nutzer – recht kompliziert.

Nochmals zum Verständnis:

Programme werden heute in einer so genannten Hochsprache wie beispielsweise C oder C++ geschrieben. Diese Codes sind recht einfach lesbar und entsprechen dem Denkschema von Menschen. Prozessoren (Chips im Computer) arbeiten anders und verstehen diese Hochsprachen natürlich nicht, sie benötigen Maschinenbefehle (Assemblercode) passend zu ihrer Architektur und Bauweise.

Die Übersetzung des Quellcodes in Maschinensprache übernehmen wiederum Software-Programme, die Compiler. Der Compiler wiederum muss wissen, für welche Chiparchitektur er denn den Maschinencode erzeugen soll, sonst wird das Programm später nicht funktionieren. In der Regel erzeugen die Compiler den Code passend für die Architektur, auf denen sie selbst installiert sind. Und dann ist natürlich auch noch das Betriebssystem von entscheidender Bedeutung (falls sie nicht gerade ein solches erst erzeugen bzw. kompilieren), denn der Compiler erstellt den Maschinencode auch passend zu dem verwendeten Betriebssystem.

Beispiel:

Sie haben zwei Computer, einer mit einem Pentium-Prozessor von Intel (i386) und einen mit einem Alpha PowerPC Prozessor. Auf dem ersten Rechner läuft ein Windows NT Betriebssystem (z. B. Win XP), auf dem zweiten ein Linux. Nun möchten Sie auf beiden Rechnern das Officepaket "OpenOffice.org" installieren und laden sich den Quellcode des aktuellen Programms herunter. Das Programm ist überwiegend in C++ geschrieben, sie benötigen also sowohl auf dem Windows- als auch auf Linux-System einen C-Compiler, um entsprechende ausführbare Codes für die jeweiligen Systeme zu erzeugen. Ein leistungsfähiger GNU C-Compiler (GCC) war eines der ersten freien Software-Projekte überhaupt und ein solcher ist heute für viele gängigen Kombinationen aus Betriebssystem und Chip-Architektur erhältlich, ja er ist sogar im Unix und Linux Betriebssystemen Bestandteil derselben. Unter Windows benötigen Sie entweder einen kommerziellen Compiler (z. B. von Microsoft) oder Sie installieren und laden eben auch einen freien Compiler, dann allerdings separat. Mit Hilfe der Compiler können Sie dann den Quellcode von OpenOffice.org passend zu Ihren Umgebungsvariablen (Prozessorarchitektur, Betriebssystem) kompilieren und das Programm anschließend installieren. Das Programm arbeitet auf beiden Rechnern nahezu identisch, selbst die Oberfläche ist (entsprechend dem gewählten Fenstermanager) vergleichbar, die erzeugten Dateien sind austauschbar. Und doch können Sie die kompilierte Variante eines Rechners nicht auf dem anderen installieren und umgekehrt. Der Aufwand, eine Open Source-Projekt zu installieren, darf also nicht unterschätzt werden.

Glücklicherweise kennen auch die Mitglieder der Communities der meisten Projekte diese Problematik und übernehmen die Erzeugung eines ausführbaren Programmcodes für die wichtigsten Systeme und Kombinationen in regelmäßigen Abständen. Dann braucht man nur noch die passende Variante auszuwählen und kann sich die fertigen, ausführbaren Dateien herunterladen und installieren. Dies ist in der Regel auch ausführlich auf den Internetseiten beschrieben.

Allerdings, und das sollte nicht vergessen werden, der "richtige" Weg zum Erhalt eines Open Source-Programms ist der lange – Kompilierung aus dem Quellcode.

Verwaltung des Quellcodes im Internet

Wenn viele verschiedene Personen räumlich getrennt durch viele Kilometer nahezu gleichzeitig den Code eines Programms bearbeiten, so benötigen sie Werkzeuge, Änderungen und Erweiterungen zu verwalten. Typischerweise werden heute mächtige CVS-Server hierfür eingesetzt. Das Concurrent Versions System (CVS) – übrigens auch ein freies Software-Projekt – ist ein mächtiges Werkzeug für die Verwaltung von Software-Projekten und Internetauftritten, die es den Mitarbeitern und Entwicklern erlaubt, gleichzeitig an denselben Dateien zu arbeiten. Das CVS-System übernimmt die Koordination und Dokumentationen der Änderungen und verhindert eine inkonsistente Codebasis. In freien Projekten kann normalerweise jeder lesend auf die Quellcodebasis zugreifen und sich die jeweils aktuelle Version auf seine Festplatte herunterladen. Um den Code zu ändern und somit aktiv mitzuarbeiten im Projekt, muss man sich in der Regel zunächst registrieren, um somit ansprechbar für alle anderen Entwickler zu werden (ansprechbar heißt, kommunikativ erreichbar, und da die Kommunikation hauptsächlich per E-Mail abgewickelt wird, benötigen Sie zumindest eine gültige E-Mail Adresse). Die Details eines schreibenden Zugriffs sind dann regelmäßig auf den Homepages der Open Source-Projekte zu finden.

Das allgemeine Verfahren wird im Folgenden kurz erläutert:

CVS verwaltet alle Dateien auf dem Server in einem gemeinsamen Verzeichnis, dem Repository. Dort ist ein direkter Zugriff nicht möglich. Möchte man die Dateien bearbeiten, kopiert man zunächst alle diese Dateien auf die lokale Festplatte, man führt ein Checkout durch. Um überhaupt Zugriff auf einen CVS-Server zu erhalten, benötig man im Übrigen ebenfalls einen Teil eines CVS-Systems auf dem heimischen Rechner, in der Regel reicht ein Front-End. Durch den Checkout-Befehl kopiert das CVS die letzte Fassung der Dateien auf den lokalen Rechner, dort können diese dann verändert und weiterentwickelt werden. Nach den Anpassungen wird ein build erstellt. Der Entwickler prüft das Ergebnis, und wenn er damit zufrieden ist (geschieht bisher alles lokal), dann schreibt er die geänderten Dateien mit dem Commit-Befehl in das Repository zurück. Mit Hilfe des CVS wird dabei verhindert, dass verschiedene Entwickler an den gleichen Dateien arbeiten und somit verschiedene Versionen geänderter Dateien im Quellcode auftauchen. In diesen Fällen müssen sich die beteiligten Entwickler untereinander zunächst verständigen und eine lauffähige Variante erstellen, bevor die verschmolzenen Dateien dann in den CVS-Baum zurückgeschrieben werden.

In regelmäßigen Abständen werden die Zweige des Entwicklungsbaums "eingefroren" und ein stabiles Release erstellt, welches dann eine neue Versionsnummer erhält.

Da CVS ebenfalls ein "freies Projekt" und doch so wichtig bei allen anderen freien Projekten ist, hier eine kurze Übersicht der wichtigsten Internet-Adressen:

Versionsnummern

Auch, wenn es hierfür keine festen Regeln gibt, hat sich doch zumindest bei freien Software-Projekten eine gewisse Systematik durchgesetzt. Da Open Source-Projekte recht häufig neue Entwickler-Builds veröffentlichen (teilweise täglich), wäre es nicht sinnvoll, diese jeweils als neue Version einer breiten Anwendermasse entsprechend zur Verfügung zu stellen. Entwicklerversionen sind meist instabil und weisen oft nur marginale Änderungen zur Vorgängerversion auf. Aus diesen Gründen werden in regelmäßigen Abständen offizielle Versionen fixiert und dann freigegeben.

Diese offiziellen Freigaben erhalten Versionsnummern, wobei die erste Nummer immer einen fundamentalen Schritt und massive Änderungen zur Vorgängerversion markieren (z. B. Version 3. auf Version 4.), während nachfolgende Ziffern kleinere Wechsel oder Patchversionen markieren. Patchversionen sind dabei Versionen, bei denen kleinere Fehler gefixt oder kleine Anpassungen vorgenommen wurden (Beispiel: Version 1.2 als stabile Version wird ein paar Wochen später durch die Version 1.2.1. ersetzt, die einige Fehlerbehebungen enthält).

Eine Besonderheit gibt es im Linux-Kernel-Projekt. Dort wird zwar die Haupt-Versionsnummer auch entsprechend großer Veränderungen hochgezählt, die zweite Nummer jedoch hat eine zusätzliche Bedeutung: Gerade Zahlen (also z. B. 2.0.n, 2.2.n, 2.4.n, 2.6.n etc.) weisen auf einen stabilen Anwender-Kernel hin, mit diesem also können Sie bedenkenlos produktiv arbeiten. Ungerade Nummern hingegen (z. B. 2.1.n, 2.3.n, 2.5.n und so weiter) klassifizieren eine Entwicklerversion, einen so genannten Hacker-Kernel. Dieser kann wesentlich instabiler sein und ist nicht für produktives Arbeiten gedacht. Diese Version ist für Entwickler und Anwender vorgesehen, die sich aktiv an der Kernel-Weiterentwicklung beteiligen und den neusten Code testen und verändern möchten.