Offene Systeme und Standardisierung im Internet

Inhalt

Abkürzungsverzeichnis

1 Fragestellung

2 Open Source Software
2.1 Entwicklungsprozess
2.2 Qualitätssicherung
2.3 Einsatzmöglichkeiten bei der Impuls-Schuh-AG

3 Kompatibilität von Informations- und Kommunikationstechnologien
3.1 Wie wird Kompatibiltät gewährleistet?
3.2 Standardisierungsorganisationen
3.3 Praktische Bedeutung für die Impuls-Schuh-AG

4 Zusammenfassung

Literatur

Anhang 1: Open Source Ressourcen

Anhang 2: Anforderungen an Open Source Software

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Fragestellung

Im Rahmen von IT-Projekten stehen Entscheider häufig vor der grundsätzlichen Fragestellung, ob Software fremdbezogen oder eigenentwickelt werden soll. Diese Entscheidung muss nicht notwendigerweise eine klassische „Make or Buy“ Entscheidung sein, denn über das Internet sind eine Vielzahl von Softwareprodukten im Rahmen von Open Source (OS) Projekten kostenfrei zu beziehen.

Entscheidet man sich für den Einsatz von OS Software, stellt sich häufig die Frage der Integration in bestehende bzw. im Aufbau befindliche Informations- und Kommunikationstechnologien (IuK).

Die vorliegende Fallstudie erläutert am Beispiel der im Kurs referenzierten Impuls-Schuh-AG Entwicklungsprozess, Qualitätssicherung und konkrete Einsatzmöglichkeiten von OS Software. Darüber hinaus wird aufgezeigt, wie mittels Normen und Standards die Kompatibilität der Komponenten gewährleistet wird, welche Organisationen dafür zuständig sind und wo sich konkrete Auswirkungen für das IT-Projekt der Impuls-Schuh-AG ergeben können.

2 Open Source Software

Die Geschichte der OS Bewegung reicht bis in die Anfänge der 70er Jahre zurück, doch erst 1998 wurde OS als Markenzeichen definiert und offiziell eingetragen.^[1] OS Software ist, wie der Name bereits vermuten lässt, Software, deren Quellcode öffentlich verfügbar ist. Doch „Open source doesn't just mean access to the source code.”^[2] Insgesamt verlangt die Open Source Initiative die Erfüllung einer Reihe von weiteren Anforderungen bzgl. Modifikations- und Distributionsrechten, die eine stetige Weiterentwicklung und rasche Verbreitung der Software garantieren sollen.^[3]

OS Software ist zwar eine kostenfrei verfügbare Software, unterliegt aber im Gegensatz zu Public Domain Software Lizenzbedingungen. Grundsätzlich lassen sich drei Arten von OS Lizenzmodellen unterscheiden.

Die General Public License (GPL)^[4] ist das OS Lizenzmodell schlechthin. Oberstes Ziel dieser Lizenz ist die Sicherstellung des Fortbestehens der OS Software indem sie alle Einschränkungen bezüglich Weitergabe und Nutzung untersagt. GPL Software kann folglich nicht gemeinsam mit proprietärer Software, für die Lizenzeinschränkungen gelten, vertrieben werden, was eine kommerzielle Nutzung nahezu unmöglich macht.

Eine Library / Lesser General Public License (LGPL)^[5] ist ausschließlich auf Softwarebibliotheken (eng: libraries) anwendbar und beinhaltet weniger (eng. lesser) Beschränkungen bezüglich der kommerziellen Nutzung, indem es die Distribution der Software-Bibliotheken in Zusammenhang mit proprietärer Software erlaubt.

Das älteste und mitunter liberalste Lizenzmodell ist die Berkeley Software Design License (BSD),^[6] die auch eine freie, kommerzielle Verwendung der Software ermöglicht. Jede Weiterentwicklung muss lediglich den Copyright Hinweis des ursprünglichen Entwicklers beinhalten. Durch die freie, kommerzielle Nutzbarkeit besteht jedoch die permanente Gefahr, dass Weiterentwicklungen als Closed Source Software (s. unten) kommerzialisiert werden.

Will sich die Impuls-Schuh-AG bestimmte, kommerzielle Verwertungsrechte für OS Software basierte Entwicklungen sichern, sollten nur Komponenten verwendet werden, die unter der BSD bzw. LGPL Lizenz stehen. Alternativ kann gleich auf Public Domain Software zurückgegriffen werden, die keinerlei Lizenzeinschränkungen unterliegt.

Zu unterscheiden ist OS Software von Closed Source Software und Shared Source Software. Erstere wird meist von einer kommerziellen Entwicklergruppe oder einem Unternehmen entwickelt, das den Source Code nicht veröffentlicht, um das geistige Eigentum zu sichern. Shared Source Software ist die Antwort des Softwaregiganten Microsoft (MS) auf die Open Source Bewegung. Im Grundsatz regelt der Shared Source Ansatz^[7] den genehmigungspflichtigen Zugang zu MS Quellcodes, insbesondere der Windows Plattform. Die Modifikation oder das Kopieren des Codes ist jedoch untersagt. Mit dieser Maßnahme will Microsoft v.a. Gerüchten entgegen treten, nach denen Windows durch ein sog. Backdoor unautorisiert persönliche Daten an einen Microsoft Server kommuniziert. Mit den Zielen der OS Bewegung hat dies wenig zu tun. Unabhängig davon gibt Microsoft nach eigenen Angaben seit vielen Jahren Quellcodes zu Forschungszwecken an akademische Einrichtungen weiter.^[8]

2.1 Entwicklungsprozess

Konventionelle Methoden und Vorgehensmodelle der Softwareentwicklung^[9] sind auf OS Projekte nicht oder nur eingeschränkt anwendbar. Bei der Vielzahl der aktuellen Projekte^[10] dürfte kaum ein Entwicklungsprozess dem anderen gleichen. Dennoch lassen sich grundsätzliche Strömungen unterscheiden. Am Beispiel des erfolgreichen Open Source Projektes fetchmail stellt Eric S. Raymond Unterschiede der von ihm diagnostizierten Entwicklungsmodelle dar:^[11]

Die Kathedrale: Dieses Modell wird häufig im kommerziellen Umfeld eingesetzt. Ähnlich dem mittelalterlichen Kathedralenbau arbeitet eine kleine, geschlossene Gruppe zentralistisch und nahezu isoliert an der Software und entscheidet autonom über Weiterentwicklung und Implementierung. Die Distribution von Zwischenreleases zu Test- und Reviewzwecken ist i.d.R. nicht vorgesehen.

Der Bazar: Bei diesem netzwerkähnlichen Modell kann theoretisch jeder mitarbeiten, der sich dazu berufen und in der Lage fühlt. Der Entwicklungsprozess folgt dem Paradigma „release early, release often“. Im Vergleich zum Kathedralen Modell sieht Raymond hier den Vorteil einer beschleunigten Weiterentwicklung und gesteigerten Qualität durch stetige Tests und Reviews einer Vielzahl von Programmierern und Testpersonen. Dadurch lassen sich die eigentlichen Vorteile eines Open Source Projekts kapitalisieren.

Dies mag insofern erstaunen, als dass man annehmen könnte, dass ab einem bestimmten Komplexitätsgrad eine zentrale Instanz notwendig sei, die das Gesamtprojekt koordiniert und klare Entscheidungsstrukturen besitzt. Das Bazar Modell hat sich jedoch mittlerweile selbst in großen Open Source Projekten, z.B. der Entwicklung des Betriebssystems Linux, des Webservers Apache oder dem zzt. größten Open Source Projekt K Desktop Environment, bewiesen. Selbst Microsoft gibt in einem an die Öffentlichkeit gelangten internen Strategiepapier zu, „that commercial quality can be achieved / exceeded by OS Software projects“.^[12]

2.2 Qualitätssicherung

Für den kommerziellen Einsatz ist insbesondere die Qualität der Software entscheidend. Dazu werden i.d.R. produktbezogene Qualitätsmerkmale wie Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit, Übertragbarkeit.^[13] und prozessbezogene Merkmale herangezogen. Darüber hinaus setzt sich mehr und mehr die Wahrnehmung durch, dass „eine wirksame Qualitätssicherung nur durch [...] ein umfassendes („totales“) Qualitätsmanagement zu erreichen ist.“^[14]

Diese produkt- und prozessbezogenen Qualitätsmerkmale werden in konventionellen Softwareentwicklungsprojekten beispielsweise durch Verwendung eines geeigneten Vorgehensmodells einschließlich Testprozeduren gegen Ende des Entwicklungsprozesses sichergestellt. Wenn im Rahmen von Anwendertests Fehler oder Abweichungen von der Spezifikation entdeckt werden, versucht der Entwickler diese zu reproduzieren und zu beheben. Raymond sieht hierin das Grundproblem konventioneller Softwareentwicklungsprojekte: “Underlying problem here is a mismatch between the tester's and the developer's mental models of the program.”^[15] Dies führt häufig zu Missverständnissen zwischen Anwendern und Programmierern, die eine effiziente Zusammenarbeit und Fehlerbeseitigung erschweren.

Bei OS Projekten hingegen werden Fehler und Abweichungen als „triviale Phänomene“, sozusagen unumgängliche Begleiterscheinungen des Entwicklungsprozesses, betrachtet.^[16] Durch ein umfassendes Netzwerk von Softwareentwicklern und Anwendern mit unterschiedlichen Kompetenzen, welche die Software kontinuierlich weiterentwickeln sowie stetigen, entwicklungsbegleitenden Tests unterziehen, können diese Fehler relativ schnell identifiziert und behoben werden.

Die Qualitätskontrolle in einem solchen heterogenen Netzwerk führt letztendlich zu einen mindestens genauso hohen Qualitätsniveau, wie konventionelle Softwareentwicklungsprozesse. Raymond geht sogar davon aus, dass die Qualitätssicherung in OS Projekten deutlich effizienter und effektiver gelöst wird, da sowohl Tester, als auch Entwickler auf Basis des öffentlichen Quellcodes eine gemeinsame Verständigungsbasis finden. „Thus, source-code awareness by both parties greatly enhances both good communication and the synergy between what a beta-tester reports and what the core developer(s) know.”^[17]

[...]

^[1] vgl. für Details [OSD2003a]

^[2] [OSD1997]

^[3] vgl. Anhang 2: Anforderungen an Open Source Software

^[4] [OSD2003d]

^[5] [OSD2003e]

^[6] [OSD2003f]

^[7] vgl. [MSSS2003]

^[8] vgl. [Krem2002]

^[9] vgl. [Stah2002], S. 218ff

^[10] vgl. für eine Übersicht http://www.opensource.org/licenses/

^[11] vgl. [Raym1999]

^[12] [OSD2003c]

^[13] vgl. [Stah2002], S. 314

^[14] vgl. [Stah2002], S. 318

^[15] [Raym2000]

^[16] vgl. [Baue2003]

^[17] [Raym2000]