Proprietär oder OpenSource?
Neben kommerzieller proprietärer Software wie dem Betriebssystem und der Office-Suite von Microsoft oder der Adobe-Produktfamilie gibt es inzwischen eine Reihe von weit verbreiteter OpenSource-Software wie zum Beispiel den Linux-Kernel, Open-/Libreoffice, Inkskape, WordPress, MySQL, Apache und viele mehr. Gemeinsam haben diese Projekte, dass der Quellcode unter einer freien Lizenz stehen. Eine freie Lizenz ist eine Lizenz, die es Dritten erlaubt, den Code zu beliebigen Zwecken zu verwenden und somit zum Beispiel das Projekt weiterzuentwickeln oder Einzelheiten anzupassen. Strengere Lizenzen wie die GPL erzwingen sogar, dass nach einer Anpassung der Code offen bleiben muss, also alle Verbesserungen den Benutzern der Software bereitgestellt werden müssen. Für den Anwender hat das den Vorteil, dass eine Software nicht „eingestellt“ werden kann, sondern er notfalls die Software weiterpflegen kann. Ebenfalls macht man sich damit von einztelnen Herstellern unabhängig und kann Support von beliebigen Firmen, wie zum Beispiel bei der Softwareschmiede Launix kaufen.
Prinzipien
Doch wenn jeder an dem Code arbeiten kann, wie funktioniert dann die Zusammenarbeit? Ist es wie im Wiki, dass jeder dazuschreibt oder weglöscht, wie er gerade Lust hat? Weit gefehlt! In der OpenSource-Welt wird Qualitätskontrolle ganz groß geschrieben. Die Grundpfeiler des OpenSource-Entwicklungsmodells sind folgende:
- Benutzung eines Versionskontrollsystems
- Maintainer und Forks
- Code Review
- Distributoren
- Anwender
Benutzung eines Versionskontrollsystems
Ein Versionskontrollsystem ist ein Stück Software, das es Entwicklern erlaubt, eine gemeinsame Sicht auf alle Dateien des Projekts zu haben. Ein Versionskontrollsystem ist zum Beispiel Mercurial, welches in diesem Artikel näher erläutert wird. Ein weiteres, beliebtes Versionskontrollsystem ist Git.
Das Versionskontrollsystem unterstützt die Entwickler bei der Verwaltung von Dateien, sowie dem Austauschen von Änderungen an dem Projekt und dem Code Review. Versionskontrollsysteme sind in heutigen Projekten nicht mehr wegzudenken. Ohne sie müsste man sich ZIP-Dateien per E-Mail hin- und herschicken.
Maintainer und Forks
Eine Schlüsselrolle in einem OpenSource-Projekt spielt der Maintainer. Ein Maintainer ist entweder eine Einzelperson, eine Personengruppe, eine Firma oder ein Zusammenschluss von Firmen. Der Maintainer hat die Verantwortung für das Projekt. OpenSource basiert darauf, dass jeder mitmacht. Ohne eine Hierarchie funktioniert es allerdings nicht. Der Maintainer führt die Arbeit, die die einzelnen, verstreuten Mitarbeiter machen, zusammen. Sämtliche Änderungen an der Software, die von Mitarbeitern gemacht werden, müssen vom Maintainer abgesegnet werden.
Im Linux-Kernel sieht das zum Beispiel so aus, dass Linus Torvalds der oberste Maintainer des Projektes ist. Die 3 Millionen Entwickler am Kernel allerdings unter einen Hut zu bekommen, ist für eine Person schlicht zu aufwendig. Aus diesem Grund gibt es weitere 100 Maintainer, die sich um einzelne Teilbereiche kümmern. Diese Maintainer tragen dann die Änderungen an Linus Torvalds heran, der diese endgültig absegnet.
Ein Maintainer ist eine Art „wohlwollender Diktator“ – er hat volle Entscheidungsgewalt über das Projekt und kann entscheiden, welche Änderungen aufgenommen werden und welche nicht. Es ist schon oft passiert, dass Änderungen aufgrund der Befindlichkeit des Maintainers nicht aufgenommen wurden. Aus diesem Grund gibt es noch die Möglichkeit des forkens. Ein Fork (engl. Gabel) ist eine Abzweigung des Projekts. Eine Person oder eine Gruppe von Personen sind mit der Arbeit des Maintainers nicht zufrieden und entscheiden sich, das Projekt selbst weiterzuführen. Dazu nehmen sie den Quellcode in der neuesten Version und veröffentlichen die Software anschließend auf eigene Faust und entwickeln sie weiter. Was auf den ersten Blick wie ein Diebstahl aussieht, ist aufgrund der verwendeten freien Lizenzen eine legitime Aktion. Ein prominentes Beispiel ist das OpenOffice-Projekt, für das Oracle der Maintainer ist. Die ursprünglichen Entwickler von OpenOffice waren mit Oracle nicht mehr zufrieden und haben die Document Foundation gegründet, die das Projekt nun unter dem Namen LibreOffice herausgibt.
Durch Forking entstehen aus einem Projekt mehrere Projekte, von denen in der Regel das weniger aktive früher oder später aufgegeben wird oder beide Projekte später wieder fusionieren. Es kann sogar passieren, dass gewissen Anwendern eine ältere Version der Software besser gefällt und sie einen veralteten Stand der Software forken und anschließend nur noch Fehler beheben. Forks beleben die OpenSource-Szene, da sie eine stetige Weiterentwicklung garantieren, auch wenn sich gewisse Menschen in dem Prozess querstellen.
Code Review
Die zwei Hauptaufgaben des Maintainers ist die Paketierung des Projekts (Anbieten von Downloads) und der Code Review. Beim Code Review geht es darum, Änderungen, die an den Maintainer herangetragen werden, zu akzeptieren oder abzulehnen. Die Plattform Github beispielsweise unterstützt diesen Prozess aktiv: Ein Entwickler kann das Projekt kopieren, weiterentwickeln und anschließend einen sogenannten Pull Request schicken. Der Maintainer wird informiert, dass jemand das Projekt weiterentwickelt wollte. Er schaut sich die Änderungen an, die in sogenannten Changesets angelegt sind. Changesets sagen genau, in welcher Datei welche Zeilen geändert werden mussten, um zum Beispiel eine neue Funktion in das Programm einzubauen. Der Maintainer, der gleichzeitig ein erfahrener Programmierer ist, entscheidet dann, ob der Entwickler sauber gearbeitet hat. Macht der Bittsteller selbst kleinste Fehler, wird die Abnahme abgelehnt und er muss nachkorrigieren. Ein Grund für eine Ablehnung kann zum Beispiel sein, dass der Entwickler die Codezeilen falsch eingerückt hat oder einen Rechtschreibfehler gemacht hat. Doch auch bösartige Änderungen, wie zum Beispiel eingeschleuste Viren, werden abgelehnt.
Sieht der Code gut aus, testet der Maintainer noch, ob der Code auch wirklich die Funktion erfüllt, die er verspricht. Er testet das Programm auch, ob es noch die ursprüngliche Funktion behält. Eine Änderung, die zwar eine Verbesserung bringt, dafür aber verschiedene Funktionen am Programm zerstört oder dort Fehler einschleust, wird ebenfalls abgelehnt. Ist die Änderung dann endgültig getestet, wird sie in den Hauptzweig, das Offizielle Projekt aufgenommen. Hat ein Entwickler eine größere Änderung eingebracht, wird er meistens auch gebeten, diesen Code weiterhin zu pflegen. So müssen zum Beispiel im Linux-Kernel die Hardware-Hersteller auf Probleme mit ihren beigesteuerten Treibern per E-Mail erreichbar sein, ansonsten wird ihr Beitrag zum Kernel wieder entfernt.
Distributoren
Eine weitere, untergeordnete Rolle spielen die Distributoren. Sie laden sich den Quellcode der Projekte regelmäßig herunter, erstellen daraus Softwarepakete und überprüfen, dass die Software noch mit anderer Software zusammenarbeitet und verteilt Updates an Anwender. Ein sehr erfolgreicher Distributor ist Canonical, welcher die Linux-Distribution Ubuntu betreut. Distributoren sind im losen Kontakt mit den Maintainern und tauschen sich darüber aus, wann wie oft neue Versionen der Software veröffentlicht werden sollen. Auch sammelt meist der Distributor Informationen über Fehler in den Programmen und reicht sie an den Maintainer weiter. Kümmert sich der Maintainer nicht schnell genug um die Behebung eines Fehlers, kann es auch passieren, dass der Distributor den Fehler selbst behebt und die korrigierte Version an den Maintainer einreicht. Manchmal veröffentlicht der Distributor die fehlerbereinigte Version sogar eher als der Maintainer, da die Kunden des Distributors den Fehler meist so schnell wie möglich behoben haben wollen.
Anwender
Zu guter letzt darf man die Anwender der Software nicht vergessen. Sie sind der Grund, weshalb die Software überhaupt existiert. Sie benutzen die Software für ihre tägliche Arbeit und ihnen wird als erstes ein Fehler in der Software auffallen. Die Anwender haben im OpenSource-Bereich auch eine Aufgabe. Sie müssen Fehler, die sie an der Software entdecken, an ihren Distributor oder den Maintainer melden. Nur so besteht eine Chance, dass Fehler auch behoben werden. Außerdem entscheiden die Anwender bei Forks, welcher Fork der beliebtere ist und zwingen so einen ungeeigneten oder restriktiven Maintainer zur Aufgabe.
Fazit
OpenSource-Software bietet aufgrund des fortschrittlichen Entwicklungsmodells einen Qualitätsvorsprung gegenüber proprietärer Software. Durch die Möglichkeit, dass jeder mitentwickeln darf, wird genauer auf die Bedürfnisse der (meist programmierfähigen) Anwender eingegangen. Proprietäre Softwareschmieden sollten ihre Entwicklungsprozesse anpassen und die Methoden, die sich in der OpenSource-Szene etabliert haben, kopieren. An die endgültige Bandbreite eines Projektes wie des Linux-Kernels wird allerdings kein proprietärer Hersteller herankommen. Die beste Lösung für Anwender ist immer noch, freie Software zu benutzen und bei Bedarf selbst anzupassen und die Verbesserung an den Maintainer einzureichen, damit jeder etwas davon hat.
German 
English
Comments are closed