Entlarvung der Open-Source-Mythen um Entwicklung und Support

Kritische Untersuchung üblicher Missverständnisse rund um Open-Source-Software

Autor des englischen Originaltextes:
N. Drakos für Gartner Group

URL des Originals:
http://gartner3.gartnerweb.com/public/static/hotc/hc00088469.html

Deutsche Übersetzung:
Christian Hartmann (mailto:christian.hartmann@berlin.de)

Deutsche Veröffentlichung:
Pro-Linux (http://www.pro-linux.de/)

Einleitung

Viele Unternehmen sind bei der Einführung von Open-Source-Software wie Linux, Apache oder Perl in ihren IT-Umgebungen sehr besorgt. Diese Sorgen sind zumeist unbegründet, sind sie doch die Folge weitverbreiteter Missverständnisse in Bezug auf die Entwicklung und den Support von Open-Source-Software.

Definition: Open-Source Software

Im Kontext dieses Artikels ist OSS solche Software, die der Open-Source-Definition der Open-Source-Initiative entspricht. Die wichtigsten Voraussetzungen für die Eignung als OSS sind die freie Weitergabe, die Verfügbarkeit des Quelltextes und die Erlaubnis zu Modifikationen und abgeleiteter Arbeit.

Mythos 1: Niemand kontrolliert die Entwicklung

OSS-Produkte unterliegen ohne Ausnahme der strengen Kontrolle einer einzelnen Person oder einer kleinen Gruppe von Entwicklern. So hat zum Beispiel Linus Torvalds immer das letzte Wort bei der Entwicklung des Linux-Kernels, während die Verantwortlichkeit für andere Aspekte der technischen Entwicklung bei ungefähr hundert Personen liegt. Die Entwicklung von Apache wird angetrieben von dem unbedingten elitären Anspruch der Apache Group, den leistungsfähigsten Webserver überhaupt zu entwickeln, während Perl von der Einzelperson Larry Wall kontrolliert wird.

Mythos 2: Software, die jeder Beliebige ändern kann, verliert letzten Endes an Stabilität

Änderungen zum Zwecke der eigenen Nutzung sind jederzeit jedermann möglich. Hingegen ist das Hinzufügen solcher Änderungen zur offiziellen Distribution oder die Gemeinschaft der Benutzer dazu zu bewegen, zu einer derart geänderten Distribution zu wechseln, ein ganz anderes Vorhaben. Bei praktisch allen OSS-Projekten haben tatsächlich nur eine kleine Anzahl an Personen das Recht, Programmcode von dritter Seite zu integrieren oder neue Versionen herauszugeben. Ein ganz anderes Element der Qualitätssicherung liegt in den häufigen Interim-Releases, die das Debuggen parallel zur Entwicklung innerhalb einer großen User-Gemeinschaft ermöglichen. Endgültige Releases, deren Stabilität als gesichert gilt, werden gemeinhin von neueren, weniger getesteten Versionen deutlich getrennt. Unternehmen sollten sich dieser Trennung bewusst sein und für sich eine gut informierte Entscheidung zu Gunsten von mehr Funktionalität oder mehr Stabilität treffen.

Mythos 3: Ein Projekt stirbt, wenn der führende Entwickler aufhört

Ein populäres OSS Produkt hat nach dem Weggang von Schlüsselpersonen eine viel bessere Chance auf Fortsetzung von Entwicklung und Support als das proprietäre Produkt eines kommerziellen Herstellers nach einer Änderung der Besitzverhältnisse oder der Produktstrategie. Der uneingeschränkte Zugang zum Quellcode sichert die Möglichkeit, genau dort weiterzumachen, wo andere aufgehört haben, da dem keine lizenzrechtlichen Beschränkungen im Wege stehen. Das bekannteste Beispiel dafür ist die Entwicklung des Webservers Apache. Die Apache-Gruppe gründete sich aus Anwendern des NCSA-Webservers, nachdem dessen Entwickler mehrheitlich das Unternehmen Netscape gründeten, das heute zu AOL gehört. Apache begann als ein Set von Patches für den NCSA Webserver, daher auch der Name: "A Patchy Server" (Ein gepatcher Server). Die Innovationsgeschwindigkeit innerhalb eines OSS-Projekts hängt vom Erreichen einer kritischen Masse an Entwicklern ab, die es erlaubt, von "Netzwerk- Effekten" zu profitieren.

Mythos 4: Es gibt keine Ansprechpartner für Support

Als Konsequenz des uneingeschränkten Zugangs zu Quellcode und Dokumentation liegt die Hürde für kommerzielle Organisationen sehr niedrig, den Einstieg in ein Service- und Supportmodell zu wagen. Für alle populären OSS-Produkte (z.B. Linux, Apache, PERL, TCL, Sendmail oder BIND) ist kommerzieller Support - einschließlich 24x7 Stunden Hotline - verfügbar. Für weniger bekannte Produkte ist Support über andere Kommunikationswege verfügbar: Entwickler-Mailinglisten, Usenet-Newsgruppen oder auf Basis gegenseitiger Hilfe unter Anwendern. Diese Art des Supports aber erscheint Unternehmen, die nach Verläßlichkeit, Wartung und technischem Support suchen, zumeist wenig akzeptabel. Díeses bleibt also die wichtigste Herausforderung für solche Unternehmen, die OSS-Produkte unterstützen und künftig - über ihre angestammten Kunden aus Entwickler-, Ausbildungs- und Forschungsumgebungen hinaus - auch Kunden aus dem kommerziellen Umfeld gewinnen wollen.

Mythos 5: OSS-Projekte werden - wie Unix - in getrennte Linien zerfallen

Obwohl allgemein ungewöhnlich, ist es theoretisch jedermann möglich, eine eigene Version eines OSS-Produktes zu erstellen und zu verteilen - man nennt dies das Erzeugen eines neuen Astes im Quellcode. Wenn eine solche neue Version wirkliche Vorteile bietet, die für Anwender attraktiv sind, so hindert die bisherigen Entwickler nichts daran, die Änderungen in die ursprüngliche Version einzubauen und so die Zersplitterung zu "heilen". In einem anderen Szenario wird die originale Version langsam baufällig und in einem solchen Fall wäre das Erscheinen einer neuen weiterentwickelten Version äußerst begrüßenswert. Aber in beiden Fällen ist der Anwender der Nutznießer einer solchen Entwicklung. Mit Open-Source-Software - und das ist der entscheidende Unterschied zur Entwicklung von Unix - kann niemand durch die Entwicklung einer solchen neuen Version des Produktes einen Wettbewerbsvorteil für sich erlangen und behalten. Genau das verhindert die dem Quellcode obliegende Verpflichtung, jede Änderung am selbigen erneut unter eine Open-Source-Lizenz zu stellen und öffentlich verfügbar zu machen.

Fakten

OSS-Projekte werden ausnahmslos von einem Einzelnen oder einer kleinen Gruppe entwickelt.
Die Verfügbarkeit des Quellcodes verringert die Abhängigkeit von einer einzelnen Person erheblich.
Für viele OSS-Produkte ist kommerzieller Support erhältlich.
Die Verfügbarkeit des Quellcodes reduziert das Risiko der Zersplitterung und Balkanisierung.

Nachsatz

Im Gegensatz zu einer allgemeinen Auffassung unterliegt die Entwicklung von Open-Source-Software einer strengen Kontrolle. Die freie Verfügbarkeit des Quellcodes und die Verpflichtung, Änderungen daran ebenfalls zu veröffentlichen, fördern das längerfristige Überleben einer Software, reduzieren die Hürden für solche Unternehmen, die Support und Service anbieten und hemmen die Balkanisierung. Wir empfehlen allen Unternehmen, die bislang Open-Source-Software in ihren Beschaffungsplänen nicht berücksichtigt haben, genau diese Politik zu überdenken.