Open Source im Unternehmen/ Betriebswirtschaftliche Betrachtung von Open-Source-Software
Der Untersuchungsgegenstand
[Bearbeiten]Berichte über den Einsatz von OSS in Behörden und öffentlichen Verwaltungen erscheinen in der jüngsten Vergangenheit häufiger in den Medien. Aktuellstes Beispiel ist die Grundsatzentscheidung der Stadt München zur Migration auf quelloffene Software. Es hat den Anschein, als würden sich Unternehmen im Allgemeinen weniger mit diesem Gedanken beschäftigen. Dies liegt aber eher an der Schwerpunktsetzung der Berichterstattung. Aktivitäten beispielsweise von Bundesministerien können für den IT-Sektor einen richtungsweisenden Charakter haben und sind daher eher von öffentlichem Interesse.
OSS wird in vielen Fällen direkt mit dem freien Betriebssystem GNU/Linux in Verbindung gebracht. Quelloffene Software ist aber mehr. So gibt es viele Programme, die keine Bindung an ein bestimmtes Betriebssystem haben. Der weit verbreitete Webserver Apache, die Officesuite OpenOffice und das Datenbanksystem MySQL sind herausragende Beispiele. OSS kann daher auch mit proprietärer Software im Anwendungsportfolio eines Unternehmens gemischt werden.[1] Dies erhöht die Flexibilität und die Wahlmöglichkeiten für Anwender.
Individualsoftware ist von den nachfolgenden Betrachtungen nicht betroffen. Sie ist in dem Sinne auch nicht vergleichbar, da sie auf einen bestimmten Nutzer zugeschnitten wird. Auch Embedded Software gehört nicht zum Untersuchungsgegenstand. Dieser Softwaretyp wird in Kombination mit PC-Hardware und elektronischen Geräten verkauft. Sie ist für Unternehmen im Sinne der Migration – wie sie hier betrachtet wird – nicht von Interesse.
Die hier betrachteten Anwender sind Unternehmen, die keine Software zum Verkauf entwickeln. Kleinere Eigenentwicklungen kann es jedoch geben. Know-How über Softwareentwicklung und die notwendigen Ressourcen sind aber nicht vorhanden. Die Unternehmensgröße ist nicht relevant.
Pauschal kann nicht behauptet werden, dass quelloffene oder proprietäre Software immer die eindeutig bessere Lösung für eine gestellte Anforderung darstellt.[2] In Diskussionen und Studien zum Einsatz von OSS in Unternehmen werden unterschiedliche Kriterien für und wider quelloffene Software aufgeführt, wie zum Beispiel Kosten, Sicherheit oder Anwenderfreundlichkeit. Diese Kriterien werden bei OSS maßgeblich durch die Merkmale Lizenzmodell und Entwicklungsform beeinflusst. Im Folgenden werden die Kategorien quelloffene und proprietäre Software anhand solcher Kriterien verglichen, die häufig in Veröffentlichungen genannt werden. Diese Vergleiche sind unabhängig von einzelner Software oder deren Einsatzbereiche, wie Desktop oder Server.
Abwägung von Chancen und Risiken
[Bearbeiten]Kriterien aus dem Lizenzmodell
[Bearbeiten]Eine der zentralen betriebswirtschaftlichen Fragestellungen betrifft die Kosten. Bei der Migration von Software fallen direkte Kosten für den Lizenzerwerb und Folgekosten, z. B. für die Anpassung von Hardware, Mitarbeiterschulung etc. an. Ein erheblicher Kostenvorteil steht auf Seiten von quelloffener Software wegen der entfallenden Lizenzkosten, bedingt durch die Möglichkeit des freien Vervielfältigens und Kopierens. Damit kann ein Unternehmen bei entsprechend großer Anzahl von notwendigen Lizenzen erhebliche Kosteneinsparpotenziale realisieren. Theoretisch kann mit einer einzigen CD-ROM für EUR 19,95 ein ganzer Konzern mit GNU/Linux inklusive OpenOffice auf dem Desktop ausgestattet werden.[3]
Der Wegfall der Lizenzkosten ist ein großes Plus von quelloffener Software. Die Einsatzentscheidung eines Unternehmens alleine auf Grundlage dieser Einsparungen zu treffen, greift jedoch zu kurz. Folgekosten bei der Einführung von OSS können nämlich diese Einsparungen komplett zunichte machen.
Mit dem Ansatz der Total Cost of Ownership (TCO) können die Gesamtkosten einer Migration abgeschätzt werden. Da dieses Kriterium weder durch die Lizenz noch durch die Entwicklungsform geprägt ist, wird sie im Abschnitt Weitere Kriterien diskutiert.
Flexibilität ist die Möglichkeit, den Quellcode eines Programms an die eigenen, unternehmensspezifischen Bedürfnisse anpassen zu können. Softwareentwickler und begeisterte Anhänger von quelloffener Software schätzen das hohe Maß an Flexibilität, bedingt durch die Verfügbarkeit des Quellcodes als sehr wichtig ein.[4] Veränderungen im Quellcode sind mit weiteren Kosten verbunden. Entweder müssen unternehmensintern Entwicklungskapazitäten vorhanden sein oder es wird nach Bedarf ein Softwaredienstleister für die Programmierung der Anpassungen beauftragt. Proprietäre Software hingegen gewährt – beschränkt durch die Lizenzbestimmungen – diese Freiheiten in der Regel nicht. Hier muss der Hersteller bzw. Eigentümer der Software direkt mit den Änderungen beauftragt werden, wobei auch hier Kosten anfallen. Der Eigentümer wird aber letztlich entscheiden, ob er diese Änderungen überhaupt zulassen will.
Ein Unternehmen, für das Flexibilität im o. g. Sinne von Bedeutung ist, muss bei einer Migrationsentscheidung berücksichtigen, dass aktuell oder zu einem späteren Zeitpunkt Entwicklungskapazitäten bereitgestellt oder eingekauft werden müssen. Bei quelloffener Software hat das Unternehmen jedoch mehr Freiheiten zur Veränderung und muss nicht mit einem Eigentümer verhandeln, der Änderungen ablehnen kann.
Die Qualität einer Software spiegelt sich in der Stabilität während der Laufzeit wider. Je stabiler eine Software ist, desto geringer ist der Administrationsaufwand und desto kürzer sind die Ausfallzeiten. Beides wirkt sich direkt auf die laufenden Kosten des Anwenders aus. Dementsprechend groß ist bei Unternehmen das Interesse an qualitativ hochwertiger Software.
Es erscheint logisch und zwingend, dass die Qualität von der Anzahl der beteiligten Entwickler abhängt, die den Code auf Fehler überprüfen. Die von Raymond im Zusammenhang mit dem Entwicklungsprozess von quelloffener Software aufgestellte Behauptung „Given enough eyeballs, all bugs are shallow“[5] könnte daher auch auf proprietäre Software angewendet werden. Raymond wendet jedoch gegen diese Argumentation ein, dass Entwickler von proprietärer Software Programmierfehler oder Entwicklungsprobleme eher als komplexe Erscheinung betrachten. Nur durch hohen internen Ressourceneinsatz und in entsprechender Zeit sind diese auffindbar und behebbar.[6] Die Konsequenz ist, dass bis zur nächsten Veröffentlichung der neuen Software entsprechend viel Zeit vergeht. Bei Open-Source-Projekten herrscht hingegen die Meinung vor, dass Fehler eher triviale Erscheinungen sind und bleiben, wenn begeisterte Mit-Entwickler permanent neue Releases erhalten, um diese zu testen. Es existiert, im Gegensatz zur Entwicklung von proprietärer Software, eine Kultur der häufigen Releases.[7] Aufgrund verschiedener, spät entdeckter Sicherheitslücken in unterschiedlichen Projekten, ist der Vorteil der vielen kritischen Augen jedoch zu relativieren.[8][9]
Wie es sich mit Fehlern und Qualitätssicherung bei proprietärer Software im allgemeinen verhält, ist unbekannt. Softwareunternehmen halten sich zu diesem Thema wegen möglicher negativer Auswirkungen auf den Produktabsatz meist bedeckt. In vielen Fällen schließen Softwarehersteller auch Geheimhaltungsabkommen, sogenannte Non Disclosure Agreements mit den Anwendern ab, um die Veröffentlichung von Fehlern zu verhindern.[10]
Für die Qualität ist neben der Anzahl der prüfenden Augen jedoch auch ein sorgfältiger Entwicklungsprozess und die gewählte Architektur der Software von Relevanz. Weiterhin ist bei Gegenüberstellungen entscheidend, welche Softwareversionen miteinander verglichen werden.[11] Grundsätzlich entscheidend ist bei diesem Kriterium die Softwarereife. Bei quelloffener wie bei proprietärer Software sind der Existenzzeitraum auf dem Markt sowie die Fehlermeldungen und -behebungen zwei wichtige Indizien. Beide sind meist nur durch intensive Recherchen im Internet oder durch möglichst unabhängige Softwareberater in Erfahrung zu bringen.
Die Qualität von Software ist ein wichtiges, jedoch nur schwer nachprüfbares Kriterium für Unternehmen. Dies gilt jedoch im allgemeinen für quelloffene und proprietäre Software gleichermaßen.
Das Kriterium Sicherheit ist von zwei Seiten zu beleuchten. Zum einen können Entwickler im Vorfeld trojanische Pferde in die Software implementieren und sich hierdurch Hintertüren im Programm aufbauen. In der Laufzeit kann der versteckte Zugang genutzt werden, um den Nutzer und seine Daten auszuspionieren. Bei der Beschaffung von proprietärer Software läuft das auf die Frage des Vertrauens gegenüber dem Hersteller hinaus. Quelloffene Software kann ohne die Zustimmung eines Herstellers einer Sicherheitsprüfung unterzogen werden. Das Vertrauen in einen Hersteller kann so durch eigenes Wissen ersetzt werden.[12]
In den Medien wurde dieses Kriterium bei der Ankündigung des Betriebssystems Windows 2000 öffentlich diskutiert. Es wurde bekannt, dass das in Windows 2000 integrierte Defragmentierungsprogramm Diskeeper von einer Scientology-nahen Firma entwickelt wurde. Die Software wurde von den Kirchen in Deutschland als höchst bedenklich eingestuft. Ein unabhängiger Test der Zeitschrift c´t konnte jedoch den Verdacht, dass diese Komponente den Anwender ausspioniert, nicht erhärten. Absolute Sicherheit, so die Tester, ist nicht möglich.[13]
Auch unbeabsichtigte Lücken in der Software können die Sicherheit des Nutzers und seiner Daten schwächen. Hier besteht eine Verbindung zum Kriterium Qualität. Fehler, die die Stabilität während der Laufzeit beeinflussen, können auch bewusst zur Schädigung des Nutzers verwendet werden.
Lücken in einer Software können unterschiedliche Ursachen haben. Am häufigsten sind Programmierfehler, auch Bugs genannt. Weiterhin können Design und Aufbau der Software oder fehlerhafte Spezifikationen Ursachen von Lücken und Schwächen sein.[14] Angreifer nutzen diese Fehler durch Viren, Würmer oder auch durch die nachträgliche Implementierung von trojanischen Pferden aus.
Ob die Offenheit des Quellcodes zur Lösung dieses Problems beiträgt, kann nicht abschließend beantwortet werden. Für die geschlossene Form proprietärer Software spricht, dass Angreifer Fehler und Schwächen nicht direkt erkennen können, sondern u.U. auf langwierige Tests oder auch Zufälle angewiesen sind. Dass dies alleine nicht schützt, zeigt die große Anzahl an Verwundbarkeiten der verschiedenen Versionen des proprietären Betriebssystems Windows von Microsoft.[15]
Auf der anderen Seite erleichtert jedoch ein offener Quellcode dem potenziellen Angreifer die Suche nach Schwachstellen. Um dem entgegenzuwirken, haben Nutzer die Möglichkeit, unsichere Programmteile, die nicht benötigt werden, zu entfernen. Beim Betriebssystem GNU/Linux wird in diesem Zusammenhang auch von „Härten“ gesprochen.[16]
Wenn keine absolute Sicherheit im Hinblick auf Fehlerfreiheit von Software gegeben werden kann, so ist es von höchster Wichtigkeit, dass ein Fehler schnellstmöglich behoben werden kann.[17] Open-Source-Distributoren ergänzen dies mit dem Hinweis, dass sicherheitskritische Fehler schneller behoben werden müssen als weniger kritische Fehler.[18]
Ein anderer wichtiger Sicherheitsaspekt bei unbeabsichtigten Lücken in der Software betrifft kryptographische Algorithmen, wie sie beispielsweise bei digitalen Signaturen eingesetzt werden. Die Algorithmen können durch verborgene oder offene Verfahren in Software implementiert werden. Nach dem Prinzip von Kerckhoff sollte die Sicherheit aber nicht von der Geheimhaltung des Algorithmus abhängig sein, sondern vom generierten Schlüssel.[19] Vergleichbar ist dies mit einem Vorhängeschloss (Algorithmus) mit Zahlenrädern (Schlüssel). Ist das Schloss nicht stabil genug gebaut, kann es durch mechanische Gewalt zerstört werden. Die Anzahl der Zahlenräder spielt dann für die Sicherheit kaum keine Rolle. Analog dazu kann ein entsprechend einfacher Algorithmus leicht durchschaut werden, auch wenn er verborgen ist. Der Zugang eines Eindringlings erfolgt dann über diesen Mangel.
Der Anreiz für ein Softwareunternehmen verborgene Verfahren in einer Software einzusetzen ist groß. Verborgene Verfahren können meist mit weniger Aufwand und geringeren Kosten als offene Verfahren realisiert werden. Der Schaden für den Anwender ist jedoch ungleich größer, wenn der Algorithmus geknackt werden kann.
Eine unternehmerische Bewertung des Kriteriums Sicherheit ist wegen beidseitiger Vor- und Nachteile nicht abschließend möglich. Vor der Beschaffung sollte die Software und die Fehlerbehandlung im Internet beobachtet und analysiert werden. Doch selbst bei einem eindeutigen Ergebnis für eine bestimmte Software kann nicht ausgeschlossen werden, dass nach der Beschaffung ein Fehler mit hoher Sicherheitsrelevanz entdeckt wird.
Ein gerne angeführtes Argument gegen den Einsatz von OSS ist die fehlende Rechtssicherheit, also die Frage nach Gewährleistung und Haftung.
Viele Open-Source-Lizenzen versuchen eine Haftung auszuschließen. Nach deutschem Recht ist jedoch ein genereller Haftungsausschluss nicht zulässig. Bei Haftungsfragen greift deshalb deutsches Recht, das quelloffene Software als Schenkung einstuft. Als Konsequenz folgt, dass der Entwickler als Schenker nur dann haftet, wenn ihm Fehler bekannt sind und er sie vorsätzlich verschwiegen hat.[20] Dies ist auch unabhängig davon, ob ein kommerzielles Softwarehaus seine Software unter Open-Source-Lizenz gestellt hat oder an einem Open-Source-Projekt mitarbeitet.
Hersteller von proprietärer Software versuchen gleichfalls die Gewährleistung einzuschränken. Auch hier greift die deutsche Gesetzgebung.[21] Der Hersteller haftet für nachweisbare Fehler im Produkt.
Falls für die Installation und die Pflege von Software unternehmensintern keine ausreichenden Ressourcen zur Verfügung stehen, werden oft externe Dienstleister verpflichtet. Die Leistung wird zwischen Unternehmen und Dienstleister vertraglich fixiert. Der Dienstleister haftet dann bei grober Fahrlässigkeit oder Vorsatz.[22] Zwischen OSS und proprietärer Software gibt es hier keinen Unterschied.
Vor der Einsatzentscheidung muss das Unternehmen bei proprietärer Software die spezifischen Lizenzbedingungen und die Haftungsausschlüsse prüfen. Bei quelloffener Software hingegen sollte dem Unternehmen die Haftungsbegrenzung durch den Schenkungscharakter bewusst sein. Für Installation und Support eignen sich für beide Softwarekategorien Werkverträge, sofern nicht ausreichend interne Ressourcen zur Verfügung stehen.
In der aktuellen öffentlichen Diskussion steht seit geraumer Zeit das Thema Softwarepatente. So sehen politische Parteien die Migration der Stadtverwaltung von München auf quelloffene Software bereits durch solche Patente gefährdet.[23] Aber auch proprietäre Software kann gegen Patente verstoßen. OSS hat jedoch den strategischen Nachteil, dass eine Überprüfung auf Patentverletzungen durch die Offenheit des Quellcodes sehr viel einfacher ist. Nach einer ersten Abschätzung verstößt alleine das Betriebssystem GNU/Linux gegen 283 Patente.[24]
Ein Unternehmen muss aufgrund der momentan nicht abschätzbaren Folgen der Softwarepatente einem Einsatz von quelloffener Software vorsichtiger gegenüber stehen als dem von proprietärer Software. Global gesehen muss u.U. damit gerechnet werden, dass sich Softwarepatente soweit negativ auf OSS auswirken, dass deren Existenz bedroht ist.[25] Hier wird sich erst in absehbarer Zeit, nach entsprechenden politischen Entscheidungen, eine sichere Vorgehensweise ergeben.
Zusammenfassend lässt sich sagen, dass von den untersuchten Kriterien zwei für quelloffene sprechen und eine für proprietäre Software. Drei Kriterien sind dagegen abhängig von der jeweiligen Ausprägung einzelner Programme bzw. bei beiden Softwarekategorien gleichwertig.
| Kriterium | spricht für quelloffene Software | ist für beide Kategorien gleichwertig | spricht für proprietäre Software |
|---|---|---|---|
| Lizenzkosten | x | ||
| Flexibilität | x | ||
| Qualität | x | ||
| Sicherheit | x | ||
| Rechtssicherheit | x | ||
| Softwarepatente | x |
Kriterien aus der Entwicklungsform
[Bearbeiten]Die Existenz von Anwendungen für den jeweiligen Bedarf ist natürlich die Voraussetzung, um über weitere Kriterien diskutieren zu können. Für das mit dem Betriebssystem Windows konkurrierende GNU/Linux stehen beispielsweise rund 1.000 Applikationen von der Datensicherung über Serverfunktionen bis hin zu Internetdiensten zur Verfügung. Für Buchhaltung, Rechnungswesen und andere Bereiche von Branchen-Software sind die Produkte hingegen meist noch nicht ausgereift.[26] Der Grund liegt oft im mangelnden Wissen und Interesse von Entwicklern an diesen spezifischen Themen.[27] Der ursprüngliche Weg, dass ein Entwickler ein technisches Problem lösen möchte, greift daher nicht. Hier ist eher abzuwarten, dass ein Softwarehaus sein bisher proprietäres Produkt unter eine Open-Source-Lizenz stellt.
Oftmals sind Fachanwendungen für den Einsatz eines bestimmten Betriebssystems konzipiert. Aus Kostengründen und wegen der besseren Wartung werden jedoch zunehmend Desktopanwendungen browserbasiert erstellt, was den flexiblen Einsatz unabhängig von Betriebssystemen ermöglicht.[28][29][30]
Für Unternehmen, die migrieren wollen oder auch müssen, ist es ein normaler Schritt, sich auf dem Softwaremarkt zu informieren. Dass es für bestimmte Bereiche keine oder kaum adäquate Anwendungen bei quelloffener Software gibt, spricht jedoch nicht generell gegen diese Softwarekategorie.
Neben der Eignung einer Software für spezifische Anwendungen, ist die Anwenderfreundlichkeit aus zwei Gründen ein wichtiges Moment für den Softwareeinsatz im Unternehmen. Software, die verständlich und einfach bedienbar ist, stößt grade bei technisch nicht so versierten Nutzern eher auf Akzeptanz. Diese Akzeptanz ist Voraussetzung für den effizienten Einsatz der Software. Gleiches gilt für die Einarbeitungszeit. Je kürzer diese ist, desto eher kann ein effizienter Einsatz sichergestellt und damit auch die Umstellungskosten reduziert werden. Eine intuitive Nutzbarkeit mit vertrauten Elementen, wie z. B. Tastaturkombinationen für bestimmte allgemeine Zwecke, ist dabei von erheblichem Vorteil.
Wie anfangs bereits erläutert, wurde in der Vergangenheit quelloffene Software in erster Linie zur Lösung von persönlichen technischen Problemen der Entwickler erstellt. Meistens handelte es sich um Systemsoftware. Anwenderfreundlichkeit war dabei kein entscheidendes Merkmal. Später wurde auch mehr Anwendersoftware entworfen. Die Anzahl der Nutzer, die nicht in die Programmentwicklung involviert sind bzw. damit auch nichts zu tun haben wollen, steigt seither an.[31] Mittlerweile gibt es für viele Programme weitaus mehr Nutzer als Entwickler. Der Bedarf an einfach zu bedienender Software steigt.
Mit der Anwenderfreundlichkeit tut sich die Entwicklergemeinschaft von quelloffener Software noch schwer.[32] Für die überwiegende Anzahl an nicht-technisch orientierten Nutzern stellt dies eine Zugangsbarriere dar und erschwert damit die Verbreitung von OSS. Projekte zur Verbesserung der Anwenderfreundlichkeit zeigen, dass dieses Problem erkannt wurde.[33] Auch kommerzielle Distributoren, wie SuSE, Red Hat u. a. arbeiten an der Behebung dieser Problematik.
Die Diskussion darf jedoch nicht darüber hinwegtäuschen, dass sich jede Software dieser Anforderung stellen muss. Softwareunternehmen können im Wettbewerb nur dann bestehen, wenn sie kundenorientiert agieren. Es ist daher davon auszugehen, dass proprietäre Software entsprechend konzipiert wird.
Nicht nur für Unternehmen, die sich mit dem Einsatz von quelloffener Software beschäftigen, ist die Prüfung auf Anwenderfreundlichkeit eines Programmes wichtig. Proprietäre Software hat hier generell keinen Vorsprung; es hängt immer vom betrachteten Produkt ab.
Der Erfolg und der Preis einer Software orientiert sich am möglichen Nutzen für den Anwender. Darum werden Marktanalysen durchgeführt, in denen Kundenwünsche und -bedürfnisse erfragt werden. Diese gehen dann in die Gestaltung der Software ein.[34] Die meiste quelloffene Software entstammt der Kultur, dass Entwickler technische Probleme selbst lösen wollten. Die Folge ist eine Entwicklerorientierung, die im Gegensatz zur Kundenorientierung steht. Mit diesem Vorurteil kämpfen auch heute noch alle Open-Source-Projekte.[35] Folge der Entwicklerorientierung ist – so das Vorurteil –, dass mehr Zeit darauf verwendet wird, Features zu entwickeln, die die Entwickler wünschen und nicht unbedingt die Anwender.[36] Solange die Entwickler auch gleichzeitig Kunden bzw. Anwender sind, wirkt sich dies nicht auf die Verbreitung der Software aus. Programme, die Kundenanforderungen nicht erfüllen, finden hingegen keine Nutzer.
Abhängig von der Einbeziehung von kommerziellen Softwarehäusern in Open-Source-Projekte ist dieses Kriterium ähnlich zu differenzieren wie die Dokumentation. Mittlerweile sind quelloffene Programme und Programmpakete erhältlich, die sich sehr stark am Kundenbedarf orientieren.
Für ein Unternehmen gilt, dass es potenziell in Frage kommende Software an den eigenen Anforderungen überprüfen muss. Ob es quelloffene oder proprietäre Software ist, spielt auch hier keine Rolle.
Anwender benötigen zur Installation und während des Einsatzes von Software eine entsprechende Dokumentation. Sie enthält Informationen über die systemtechnische Betreuung des Programms – wie beispielsweise zur Installation – und Bedienungsanleitungen. Für quelloffene Software existiert in den meisten Fällen darüber hinaus auch eine Dokumentation des Quellcodes. Diese ermöglicht es einem Unternehmen, den Code nachzuvollziehen und eigene Veränderungen einzuarbeiten.
Nach wie vor steht quelloffene Software in der Kritik, dass sie schlecht beschrieben ist. Dies kommt meist von der Annahme, dass die Entwickler weder Zeit haben noch motiviert sind, eine Dokumentation zu erstellen.[37] Da sie darüber hinaus keine vertraglichen Verpflichtung mit Nutzern haben, gibt es oft nur allgemeine Beschreibungen, aber kein komplettes Handbuch.[38]
Diese Argumentation greift zu kurz und trifft meist auch nicht zu. Eine differenzierte Betrachtung ist notwendig. Als erstes sind Programme unter einer Open-Source-Lizenz zu betrachten, die fast ausschließlich von Softwareunternehmen entwickelt werden, wie der Webapplicationsserver JBoss der JBoss Group.[39] Dem Kundenwunsch nach einer adäquaten Dokumentation können sich diese Softwareunternehmen im Hinblick auf eine maximale Kundenbindung nicht verschließen, selbst wenn Einnahmen nur durch Support und nicht durch Lizenzen generiert werden. Als zweites sind populäre Programme wie GNU/Linux, Apache, KDE etc. zu analysieren. Dokumentationen hierfür werden oft durch kommerzielle Distributoren wie Red Hat oder SuSE erstellt und den Distributionen beigefügt. Auch hier ist der Motivationsgrund der Wunsch nach optimaler Kundenbindung.
Drittens können Dokumentationen zu quelloffener Software verkauft werden. Spezialisierte Verlage, wie SuSE Press oder O’Reilly, haben sich bereits in dieser Marktnische positioniert.
Als letztes ist der Bereich von neu entwickelter oder kaum verbreiteter Software zu betrachten. Hier trifft die Kritik eher zu. Den Entwicklern geht es zu Beginn bekanntermaßen um die eigene Anwendung und die Bewertung durch die Entwicklergemeinde, in der diese Vorgehensweise akzeptierte Kultur ist.
Eine mangelhafte Programmdokumentation kann den effizienten Einsatz einer Software gefährden, unabhängig ob sie quelloffen oder proprietär ist. Für Unternehmen ist es deshalb wichtig, im Vorfeld einer Migrationsentscheidung sorgfältig zu recherchieren. Für oder gegen OSS spricht dieses Kriterium jedoch generell nicht.
Das Kriterium der Entwicklungskonstanz stellt die Stabilität des Weiterentwicklungsprozesses in Abhängigkeit von den Entwicklern und bei proprietärer Software auch vom Softwareunternehmen dar.
Die meist freiwillige Teilnahme an einem Open-Source-Projekt macht dessen Entwicklungsprozess latent instabil. Die Betreuung des Projektes und damit die Entwicklungskonstanz hängen sehr stark vom individuellen Engagement und der Anzahl der Entwickler ab. Wenn diese das Projekt verlassen, kann der weitere Projektfortschritt stark gefährdet sein. Das anwendende Unternehmen verfügt jedoch immer über den Quellcode. Damit existiert zumindest prinzipiell die Möglichkeit, das Programm selbst weiter zu pflegen oder einen externen Dienstleister damit zu beauftragen.[40]
Verlassen einzelne Entwickler oder auch der Projektleiter ein Softwareunternehmen, so kann dieses den Verlust durch den Einkauf von Know-How am Arbeitsmarkt kompensieren. Der Betreuung und Weiterentwicklung einer proprietären Software ist dadurch kaum in Gefahr. Ein Konkurs des Anbieters hingegen kann für den Anwender jedoch kritisch werden. Bei auftauchenden Fehlern ist der Anwender nämlich nicht in der Lage, Korrekturen selbst vorzunehmen oder einen Dienstleister damit zu beauftragen. Gibt das in Konkurs gegangene Softwareunternehmen den Quellcode nicht weiter, oder findet sich kein Softwarehaus, das diesen übernehmen will, sind die Anwender in kurzer Zeit mit dem Fehlen des Herstellersupports konfrontiert. Auch dann, wenn eine Übernahme durch ein drittes Softwareunternehmen stattfindet, kann es vorkommen, dass dieses die Produktreihe einstellt.
Ein Unternehmen muss sich bei beiden Kategorien mit der Möglichkeit auseinander setzen, dass eingesetzte Software nicht weiter betreut oder entwickelt wird.
Ein Open-Source-Projekt birgt noch eine weitere Form der Instabilität, die des Fork (Gabelung). Wegen unterschiedlicher Projektziele kann sich die bestehende Entwicklergemeinschaft auftrennen.[41] Konsequenz ist die Aufteilung der Entwickler auf die einzelnen Projekte und differierende Entwicklungsrichtungen bei der Software. Der Anwender wiederum sieht sich unfreiwillig mit einer Entscheidung zwischen den Programmen aus den jeweiligen Entwicklungsrichtungen konfrontiert.
Ein Fork bietet auch jedoch eine Chance. Entwicklungen von aufgespaltenen Projekten zeigen, dass ein Fork ein Reinigungsprozess sein kann. Übergroße Programme können hierdurch wieder in handhabbare Größen aufgeteilt werden.[42]
Das Beispiel von OS/2 belegt, dass ein Fork auch bei proprietäre Software möglich ist. Ab 1988 arbeiteten IBM und Microsoft gemeinsam an der Nachfolgeversion von OS/2 1.x. 1991 gingen die Partner auseinander. IBM setzte seine Arbeit fort, Microsoft hingegen entwickelte das neue Betriebssystem Windows NT.[43]
Da ein Fork häufiger bei OSS vorkommt, spricht dieses Kriterium eher für proprietäre Software.
Software kann in einem einzigen Block oder in einzelnen, aufeinander abgestimmten Modulen erstellt werden. Die Technik der Modularität wird sowohl bei der Erstellung von proprietärer als auch quelloffener Software angewendet. Bei Letzterem – bedingt durch die weltweite Verteilung der Entwickler – ist dies stärker ausgeprägt.[44]
In der Praxis stellt die Modularität eine besondere Qualität von OSS dar und wird von Unternehmen höher eingeschätzt als die Möglichkeit, den Quellcode zu ändern. So können Zusatzmodule entwickelt werden, ohne in den Quellcode der vorhandenen Module eingreifen zu müssen. Jederzeit können neue Programmteile hinzugefügt oder andere gelöscht werden, ohne dass die ursprüngliche Software oder das Betriebssystem negativ beeinträchtigt würde.[45]
Hiermit verfügt der Anwender über die Möglichkeit, nicht benötigte Module ohne Auswirkungen auf die gewünschte Funktionalität des Programms aus dem Quellcode zu entnehmen. Beispielsweise kann das Betriebssystem GNU/Linux aufgrund dieser Eigenschaft an vorhandene, auch ältere Hardware optimal angepasst werden. Dies eröffnet Kostensenkungspotenziale, die proprietäre Software in der Form nicht bietet.
Die Modularität von quelloffener Software macht es einem Unternehmen leichter, größere Veränderungen selbst vorzunehmen. Um diesen Vorteil nutzen zu können, müssen der Bedarf und die hierzu notwendigen eigenen Ressourcen im Vorfeld geklärt sein. Gegebenenfalls kann später auch ein externer Dienstleister mit den Anpassungen des Quellcodes beauftragt werden.
Damit unterschiedliche Programme und Anwendungen miteinander kommunizieren und interagieren können, werden Standards eingesetzt. Für den Datentransport im World Wide Web wird beispielsweise das Hypertext Transfer Protokoll (HTTP), für die Beschreibung von Internetseiten die Hypertext Markup Language (HTML) und für Datenbankanwendungen überwiegend die genormte Abfragesprache Structured Query Language (SQL) eingesetzt.
Von offenen Standards wird dann gesprochen, wenn sie für jeden zugänglich sind. Für das Bundesamt für Sicherheit in der Informationstechnik ist die Offenheit eines Standards dann gegeben, wenn seine Implementierung in eine quelloffene Software möglich ist.[46]
Sollten für technische Anforderungen vorhandene Standards nicht genügen, entwickeln Softwareunternehmen oft eigene. Diese herstellerspezifischen Standards sind in der Regel nicht frei zugänglich. Es entsteht eine Form von Exklusivität, die zwei Nebeneffekte hat. Zum einen ermöglicht sie einen gewissen Grad an Sicherheit vor dem Zugriff Unbefugter. Diese Sicherheit kann jedoch nicht als sehr hoch eingestuft werden, da auch hier das Prinzip von Kerckhoff gilt. Zum anderen bindet diese Exklusivität den Nutzer an den Hersteller. Programme von anderen Herstellern, die vergleichbare Funktionen haben, können die vorhandenen Daten nicht verwenden. Es entsteht eine Abhängigkeit vom Hersteller. Dies wird auch als Lock-in bezeichnet.
Bei der Entwicklung von OSS werden in den meisten Fällen offene oder weit verbreitete Standards angewendet. Dies ist wegen der oft modularen Bauweise für den Erfolg des Entwicklungsprozesses auch zwingend notwendig.
Um in seinen Entscheidungen weiterhin frei zu bleiben, empfiehlt es sich für ein Unternehmen, Software mit offenen Standards zu verwenden.[47] Entscheidet sich ein Anwender jedoch, Beschränkungen durch nicht-offene Standards hinzunehmen, sollte ihm dadurch auch ein entsprechender Zusatznutzen entstehen.
Ein oft genannter Vorteil von quelloffener Software ist die Herstellerunabhängigkeit. Die UN merkt hierzu an: „What seems clear is that FOSS can help a business or public institution avoid getting locked into a vicious circle of hardware and software upgrades and changes in data formats that require investing in new license fees and significant retraining and can provoke major down time.“[48]
Ein aktuelles Beispiel für die Auswirkungen einer solchen Abhängigkeit ist die Beendigung des Supports von Windows NT durch den Hersteller Microsoft.[49] Die Anwender stehen vor der Wahl, auf weitere Fehlerbehebung und Support zu verzichten oder ein Update auf Windows 2000 vorzunehmen. Das Update ist zunächst mit direkten Kosten – Erwerb neuer Lizenzen – verbunden. Es fallen aber auch noch Folgekosten an. Zum Beispiel stellt der Betrieb von Windows 2000 höhere Anforderungen an die Hardware, die noch zu beschaffen ist. Weiterhin sind strukturelle Anpassungen, durch die Umstellung vom NT-Domänenkonzept auf Windows 2000 / Active Directory notwendig. Hierzu sind Ressourcen notwendig, die Kosten verursachen.[50] Ob ein Anwender ein Update ablehnen kann, hängt von vertraglichen Vereinbarungen und von den Lizenzbestimmungen ab.
Quelloffene Software zeigt aber ähnliche Effekte. Durch kontinuierliche Fehlerbehebung, Implementierung neuer Funktionen bis hin zu neuem Design – wie zum Beispiel beim Versionswechsel der Bildbearbeitungssoftware zu Gimp 2.0 – gibt es ständig Veränderungen.[51] Ein Anwender kann beim alten Programm bleiben und sich diesen Neuerungen verwehren. Dann ist aber damit zu rechnen, dass der eingesetzte Releasestand nicht mehr gepflegt wird.
Das Beispiel des Update zu Windows 2000 zeigt u. a. die Notwendigkeit, Hardwareanforderungen im Vorfeld zu überprüfen und gegebenenfalls Nachrüstkosten einzukalkulieren. Diese ist jedoch auch bei der Migration zu OSS zu berücksichtigen. Auch können bei quelloffener Software verwendete Standards verändert werden.
Alle Punkte, die Anwender an den Hersteller und sein Programm binden, greifen auch bei OSS. Der einzig wirkliche Unterschied bei dem Kriterium Herstellerunabhängigkeit sind mögliche neue Lizenzkosten für proprietäre Software, die bei quelloffener Software natürlich entfallen. Ein Unternehmen muss dieses allgemeine Argument der Herstellerunabhängigkeit genau analysieren. Vorhersagen über mögliche Entwicklungen der potenziell zur Anwendung kommenden Software können nicht gemacht werden.
Zusammenfassend lässt sich hier sagen, dass von den untersuchten Kriterien je zwei für quelloffene und proprietäre Software sprechen. Die verbleibenden fünf Kriterien sind dagegen auch hier von der jeweiligen Ausprägung einzelner Programme abhängig bzw. bei beiden Softwarekategorien als gleichwertig anzusehen.
| Kriterium | spricht für quelloffene Software | ist für beide Kategorien gleichwertig | spricht für proprietäre Software |
|---|---|---|---|
| Anwendungen | x | ||
| Anwenderfreundlichkeit | x | ||
| Kundenorientierung | x | ||
| Dokumentation | x | ||
| Entwicklungskonstanz | x | ||
| Fork | x | ||
| Modularität | x | ||
| Standards | x | ||
| Herstellerunabhängigkeit | x |
Weitere Kriterien
[Bearbeiten]Neben den oben ausgeführten Kriterien gibt es weitere, die nicht der Lizenz oder der Entwicklungsform zugeordnet werden können. Dies sind die (Gesamt-) Kosten einer Migration, das Kriterium des Supports und Hardwareunterstützung.
Für das anwendende Unternehmen sind die bei der Migration anfallenden Kosten das wohl wichtigste Kriterium. Da durch Open-Source-Lizenzen das Recht auf freie Vervielfältigung vergeben wird, entfallen damit direkte (Lizenz-) Kosten, die bei proprietärer Software dem Lizenzgeber zu entrichten sind. Jedoch sind weitere Folgekosten zu berücksichtigen. Um alle Kosten zu erfassen, hat die Gartner Group Inc. das Konzept der Total Cost of Ownership (TCO) entworfen. Es stellt eine Weiterentwicklung der reinen Anschaffungskostenperspektive dar und berücksichtigt auch Kosten, die im laufenden Betrieb entstehen.[52] Dies sind beispielsweise Kosten für Schulungen, Hardwareanpassungen oder Ersatzkapazitäten bei Systemausfall. Dieses Konzept hat sich bei Migrationsbetrachtungen mittlerweile durchgesetzt.
Wegen der Wichtigkeit des Kostenaspekts für Unternehmen erscheinen regelmäßig neue Studien zu TCO.[53] In den meisten Fällen vergleichen sie als bekannteste Vertreter von quelloffener und proprietärer Software die Betriebssysteme GNU/Linux und unterschiedliche Versionen von Windows. Sie treffen jedoch keine Aussagen zu anderen betrieblich relevanten Programmen aus den zwei Softwarekategorien. Hinzu kommt, dass die Ergebnisse dieser Studien vom Geld- und Auftraggeber abhängig sind. Objektive Ergebnisse, die ein einzelnes Unternehmen für sich verwenden kann, entstehen durch diese Studien nicht.
Bei näherer Betrachtung der unterschiedlichen Studien fällt auf, dass es in erster Linie um die Frage geht, welche Veränderungskosten durch die Migration verursacht werden. So sind beispielsweise Problemstellungen bezüglich Hardwareanpassung oder Schulungen keine spezifischen Frage von quelloffener Software. Wie das Beispiel Windows 2000 zeigt, kann auch ein Update innerhalb einer Produktreihe erheblichen Aufwand und damit indirekte Kosten verursachen.
Für jedes Unternehmen ist deshalb eine differenzierte Betrachtungsweise notwendig.
Lange Zeit gab es kaum professionellen Support für quelloffene Software. Die große Quelle war und ist auch heute noch das Internet mit seinen Mailing-Listen und Newsgroups. Hinzugekommen sind aber mittlerweile Unternehmen, die verschiedene Support-Dienstleistungen anbieten.[54]
Beim Herstellersupport muss wieder in die drei Entwicklerkategorien unterteilt werden. Softwareunternehmen, die ihre Software unter Open-Source-Lizenz gestellt haben, könnten nach wie vor Support anbieten, also Veränderungen und Anpassungen des Quellcodes sowie Beratungsleistung. Ähnliches gilt auch für Projekte, an denen Softwarehäuser beteiligt sind. Auch diese können Herstellersupport anbieten. Für OSS die nur von freiwilligen Entwicklern getragen wird gibt es hingegen keinen Support. Wenn eine solche Unterstützung gewünscht ist, steht es jedem Unternehmen offen, einen Dienstleister zu beauftragen. Mittlerweile gibt es für die meisten Open-Source-Programme ausreichenden Support.
Für Unternehmen kann jede Softwaremigration den potenziellen Wechsel beim Supportdienstleister bedeuten. Hohe Zufriedenheit mit den bisherigen Leistungen des Dienstleisters kann dabei ein Hemmnis zum Softwarewechsel sein. Gleiches gilt auch, wenn der Dienstleister großes Know-How über die Unternehmensspezifika aufgebaut hat.
Als letztes Kriterium ist die Hardwareunterstützung zu nennen. Hersteller von Hardware bieten oftmals keine Treiber für quelloffene Betriebssysteme an. Zum Schutz des Technologievorsprungs wird der Quellcode nicht veröffentlicht. Entwickler aus der weltweiten Gemeinschaft versuchen dann, quelloffene Treiber selbst zu entwickeln. Meist werden Lösungen geschaffen, die oft aber nicht die gesamte Funktionalität der Hardware nutzen können.
Will ein Unternehmen absehbar neue oder spezielle Hardware auf quelloffenen Betriebssystemen einsetzen, muss es vorher prüfen, ob Treiber zur Verfügung stehen.
Zusammenfassend lässt sich hier sagen, dass nur einer der drei Kriterien eher für proprietäre Software spricht. Kosten und Support sind abhängig von der gewünschten Software.
| Kriterium | spricht für quelloffene Software | ist für beide Kategorien gleichwertig | spricht für proprietäre Software |
|---|---|---|---|
| Folgekosten | x | ||
| Support | x | ||
| Hardwareunterstützung | x |
Quellen
[Bearbeiten]Die zitierten Quellen sind im Literaturverzeichnis zu finden.
- ↑ Vgl. auch Dravis, P.: Developement, 2003, S. 23.
- ↑ Vgl. Berlecon Research GmbH: Strategien, 2004, S. 12.
- ↑ Vgl. Berlecon Research GmbH: Strategien, 2004, S. 25.
- ↑ Vgl. auch Berlecon Research GmbH: Strategien, 2004, S. 27.
- ↑ Vgl. auch Raymond, E. S.: Cathedral, 2000, o. S.
- ↑ Vgl. auch Hissam, S. A. u. a.: Perspectives, 2001, S. 10.
- ↑ Vgl. auch Raymond, E. S.: Cathedral, 2000, o. S.
- ↑ Vgl. auch Raymond, E. S.: Cathedral, 2000, o. S.
- ↑ Vgl. Heise News: Mehr Sicherheit, 2003, o. S.
- ↑ Vgl. Bundesamt für Sicherheit in der Informationstechnik: Freie Software, 2004, o. S.
- ↑ Vgl. Berlecon Research GmbH: Strategien, 2004, S. 34.
- ↑ Vgl. Bundesamt für Sicherheit in der Informationstechnik: Trojanische Pferde, 2003, o. S.
- ↑ Vgl. Göhring, H.-P.: Windows, 1999, S. 58.
- ↑ Vgl. auch Hissam, S. A. u. a.: Perspectives, 2001, S. 35.
- ↑ Vgl. CERT Coordination Center: Advisories, 2004, o. S.
- ↑ Vgl. auch Bundesministerium für Wirtschaft und Technologie: Leitfaden, 2001, o. S.
- ↑ Vgl. United Nations, Developement, 2003: S. 102.
- ↑ Vgl. auch Pro-Linux News: Erklärung, 2004, o.S.
- ↑ Vgl. auch Köhntopp, K./Köhntopp, M./Pfitzmann, A.: Grenzen, 2000, S. 8.
- ↑ Vgl. auch Metzger, A.: Haftung, 2002, o.S.
- ↑ Vgl. Berlecon Research GmbH: Strategien, 2004, S. 31–32.
- ↑ Vgl. auch Wieland, T.: Unternehmen, 2002, S. 10.
- ↑ Vgl. Heise News: München, 2004, o. S.
- ↑ Vgl. Pro-Linux News: Konflikt, 2004, o.S.
- ↑ Vgl. Brügge, B. u. a.: Ökonomische Analyse, 2004, S. 146.
- ↑ Vgl. Edelmann, G.: Popularität, 2004, o. S.
- ↑ Vgl. auch Schmidt, K. M./Schnitzer, M.: Public Subsidies, 2002, S. 14.
- ↑ Vgl. Berlecon Research GmbH: Strategien, 2004, S. 39.
- ↑ Vgl. Pro-Linux News: Bibliotheken, 2004, o. S.
- ↑ Vgl. Heise News: Polizei, 2003, o. S.
- ↑ Vgl. auch Nichols, D. M./Twidale, M. B.: Usability, 2003, o. S.
- ↑ Vgl. auch Levesque, M.: Issues, 2004, o. S.
- ↑ Vgl. openusability.org: openusability, 2004, o. S.
- ↑ Vgl. auch Schmidt, K. M./Schnitzer, M.: Public Subsidies, 2002, S. 14.
- ↑ Vgl. auch Kooths, S./Langenfurth, M./Kalwey, N.: Bewertung, 2003, S. 4.
- ↑ Vgl. auch Levesque, M.: Issues, 2004, o.S.
- ↑ Vgl. Hissam, S. A. u. a.: Perspectives, 2001, S. 11.
- ↑ Vgl. auch Levesque, M.: Issues, 2004 o. S.
- ↑ Vgl. Linux-Magazin: JBoss, 2003, S. 18.
- ↑ Vgl. auch Wieland, T.: Unternehmen, 2002, S. 9.
- ↑ Vgl. United Nations: Developement, 2003, S. 102.
- ↑ Vgl. auch Grassmuck, V.: Gemeineigentum, 2002, S. 240–241.
- ↑ Vgl. Heise News: NT, 2003, o. S.
- ↑ Vgl. Berlecon Research GmbH: Strategien, 2004, S. 28.
- ↑ Vgl. auch Bundesministerium für Wirtschaft und Technologie: Leitfaden, 2001, o. S.
- ↑ Vgl. auch Bundesamt für Sicherheit in der Informationstechnik: Freie Software, 2004, o. S.
- ↑ Vgl. auch Berlecon Research GmbH: Strategien, 2004, S. 39.
- ↑ United Nations: Developement, 2003, S. 103.
- ↑ Vgl. Heise News: Support NT, 2004, o. S.
- ↑ Vgl. Wieland, T.: Unternehmen, 2002, S. 9.
- ↑ Vgl. Pro-Linux News: GIMP, 2004, o. S.
- ↑ Vgl. auch Brügge, B. u. a.: Ökonomische Analyse, 2004, S. 116.
- ↑ Vgl. auch United Nations: Developement, 2003, S. 102–103.
- ↑ Vgl. auch Bundesministerium für Wirtschaft und Technologie: Leitfaden, 2001, o. S.