In unserem Online Wörterbuch erklären wir nicht nur die Bedeutung der Wörter aus IT und Wirtschaft, sondern versuchen auch
immer einen Bezug zum eBusiness herzustellen und Ihnen Tipps zu geben, wie Sie Produkte, Systeme und Techniken nutzen, um
Ihr eBusiness zu verbessern.
Software-Engineering und Software-Qualität in Open-Source Projekten
Folgender Artikel wurde von Herrn
Jan Tobias Mühlberg
in der Kategorie "Softwaretechnik"
bereitgestellt.
Ausgehend von vorläufigen Ergebnissen einer Metastudie zu Open-Source-Software (OSS), befasst sich die vorliegende Arbeit mit der Frage, inwieweit die bei der Entwicklung größerer OSSProjekte eingesetzten Entwicklungsmechanismen Auswirkungen auf die Qualität ihrer Produkte haben. Der Autor kommt zu dem Ergebnis, dass OSS in der Regel als mit Closed-Source-Software vergleichbar oder besser angesehen wird und qualitative Defizite insbesondere den Bereich der Weiterentwickelbarkeit der Software betreffen. Im Folgenden werden das Zustandekommen dieser Defizite analysiert und Möglichkeiten zu deren Vermeidung aufgezeigt. Die Arbeit ist primär als Grundlage für eine weitere Diskussionen der Thematik Open-Source-Software-Engineering gedacht.
Diese Arbeit unterliegt den Bedingungen einer
creative commons-Lizenz. Sie darf vervielfältigt,
verbreitet, öffentlich aufführt, bearbeitetet und
kommerziell genutzt werden, sofern die resultierenden
Arbeiten unter identischen Lizenzbedingungen
weitergegeben und eine Nennung des Autors
der Ursprungsarbeit erfolgt.
|
Kritik am Open-Source-Ansatz
Der vorangestellte Abschnitt zeigt, dass Open- Source-Software in der Regel mit ähnlichen Problemen wie Closed-Source-Software zu kämpfen hat. Letztlich stellen weder Closed-Source noch Open-Source das Patentrezept für sichere, verlässliche und wartbare Software dar. Wie beispielsweise die Arbeit von Madanmohan und De ([18]) zeigt, wird Open-Source-Software dennoch in beachtlichem Umfang in kommerziellen Produkten eingesetzt; beispielsweise in Anwendungen aus dem Bereich der Netzwerksicherheit, einem Anwendungsgebiet in dem die qualitativen Eigen- schaften der verwendeten Einzelkomponenten eine besonders wichtige Rolle spielen. Tatsächlich besteht aus der Sicht eines Angreifers kein großer Unterschied zwischen einer Closed-Source- und einer Open-Source-Anwendung. In beiden Fällen hat er zumindest die Möglichkeit den Objekt- Code9 einer Software zu untersuchen und erhält damit in jedem Fall Einblick in alle implementierungsspezifischen Details eines Software-Systems – auch wenn das im Fall der Closed-Source- Software etwas umständlicher ist. Der Closed- Source-Ansatz ist grundsätzlich ein Mechanismus aus der Geschäftswelt, der auf die Durchsetzung von Rechtsvorschriften angewiesen ist. Mit Sicherheit und Qualität hat er nichts zu tun (vgl. Witten et al., [31]). In gleicherWeise kann auch die Open- Source-Bewegung als eine eher philosophisch orientierte Strömung ohne jeden kommerziellen Hintergedanken verstanden werden (vgl. bspw. Stallman, [25]). Entscheidend ist jedoch, dass das bereits weiter oben erwähnte viele-Augen-Prinzip der Open-Source-Software das Potenzial gibt, ein weitaus höheres Niveau an Funktionssicherheit zu erreichen, als dass bei Closed-Source-Software der Fall wäre. Witten et al. ([31]) stellen in ihrer Arbeit fest, dass die Offenheit des Quelltextes dazu beiträgt, die Sicherheit eines Software-Systems zu erhöhen und dass Open-Source-Software hinsichtlich bestimmter Klassen von Fehlern tatsächlich weniger anfällig ist. Auch bieten sie über die Verwendung öffentlich zugänglicher Datenbanken für Fehler dem Anwender eine höhere Transparenz bezüglich der Existenz und dem Bearbeitunsstatus bekannter Schwachstellen in dem jeweiligen Software-System (vgl. Koru und Tian, [17]). Vor allem in Einsatzgebieten, in denen der Anwender ein sehr hohes Maß an Sicherheit benötigt, wird ihm gar nichts anderes übrig bleiben als vorrangig Open-Source-Software zu verwenden: In einem großen und komplexen Szenario würde erst die Offenlegung des Quelltextes eine „rekursive“ Prüfung und Zertifizierung aller Einzelkomponenten und des Gesamtsystems ermöglichen. Dagegen erhöht die Geheimhaltung des Quelltextes jedoch in keiner Weise die Sicherheit einer Anwendung. Um so tragischer stellt sich in diesem Zusammenhang das schlechte Abschneiden von Open- Source-Produkten bei der Analyse des Quelltextes hinsichtlich seiner Weiterentwickelbarkeit dar. In einem Entwicklungsprojekt, dessen expliziter Fokus darauf liegt, Dritten den freien Zugang zu den internen Strukturen der Software zu ermöglichen, sollte die Wartbarkeit des Quelltextes immer oberste Priorität haben. Die Integration einer großen Anzahl von Entwicklern in ein Software-Projekt ist anders nicht durchführbar. Insbesondere weil Neulinge andernfalls beim Einstieg in ein Projekt sehr viel Zeit in die Einarbeitung in dessen komplexe Struktur investieren müssen, die sie besser in das Design und die Umsetzung der anvisierten Erweiterungen des Projektes investieren möchten und sollen. Tatsächlich werden von vielen Autoren insbesondere Versäumnisse in der Designphase der Software-Entwicklung bei Open-Source-Projekten kritisiert. Beispielsweise weist Jørgensen in [16] darauf hin, dass eine der entscheidenden Hemmschwellen in dem von ihm untersuchten Open- Source-Projekt darin besteht, dass es für Entwickler die sich mit Designfragen befassen, sehr schwer ist, konstruktive Kritik bezüglich ihrer Vorschläge zu erhalten. In [30] formuliertWilson das Problem folgendermaßen: „Great programmers can work effectively without explicit design or coordination, but when average programmers try to emulate that improvisation, the results are rarely pretty.“10 Er erläutert ferner, dass Problemstellungen aus dem Bereich des Software-Designs und der Software-Architektur in Open-Source- Gemeinschaften oft nicht oder nur widerwillig diskutiert werden. Die weiter oben aufgeführten Analysen von Quelltexten aus Open-Source-Projekten haben gezeigt, dass beispielsweise die dem Linux-Kernel zugrundeliegende Modularisierung durchaus tragfähig ist. Um so wichtiger ist es daher, Designfragen auch für weitaus speziellere Probleme im Software-Entwurf zu stellen und zu diskutieren. Ein Open-Source-Projekt, das sich Herausforderungen der Gegenwart stellt und seinen Entwicklungsfokus auf eine strikte Trennung der Einzelkomponenten und deren Wartbarkeit richtet – selbst wenn das unter Umständen den Verzicht auf die schnelle Umsetzung neuer Funktionalität bedeutet – wird es wesentlich leichter haben, mit den Herausforderungen der Zukunft umzugehen. Beispielsweise wird der Einsatz formaler Methoden zur Verifizierung einer komplexen Anwendungssoftware oder gar eines ganzen Betriebssystems hohe Anforderungen an die Qualität des Quelltextes des betreffenden Projektes stellen. Open-Source-Software, die für den Einsatz in sicherheitskritischen Anwendungsbereichen geeignet sein soll, wird früher oder später den Bedürfnissen der Anwender nach Verifizierung und Zertifizierung nachkommen müssen. Kostenfaktoren sind hierbei erst einmal zweitrangig; viel wichtiger ist es, dass Open-Source-Entwicklungen ihre diesbezüglichen Vorzüge durch ein gezieltes design for maintainability, ausbauen. Das bedeutet insbesondere einen erhöhten Einsatz softwarearchitektonischer Maßnahmen, die explizit auf eine Erhöhung der Wartbarkeit des Quelltextes abzielen und in allen Phasen des Entwicklungsprozesses Anwendung finden. |
