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.
|
Software-Qualität bei Open-Source-Software
Betrachten wir zunächst den Ablauf und die Organisation von Open-Source-Projekten: Die meisten Projekte beginnen damit, dass ein Einzelner oder eine Gruppe von Entwicklern eine erste Version der Software schreibt und sie im Netz frei zur Verfügung stellt. Damit werden sowohl Benutzer als auch weitere Entwickler „eingeladen“, die Software zu verwenden oder Beiträge zu ihrer Entwicklung zu leisten. Wie auch Raymond in [21] darstellt, sind insbesondere die Anwender von großer Wichtigkeit für die weitere Entwicklung des Projektes. Sie werden in Open-Source- Projekten vielmehr als Mitentwickler denn als bloße Verbraucher angesehen. Auch die Entwickler werden nicht einfach in Strömen auf das Projekt aufspringen (vgl. O’Reilly, [19]). Ausgehend von Raymonds und O’Reillys Aussagen ist eher von einem zumWachstum des Benutzerstammes proportionalen Wachstum der Entwicklergemeinde aus- zugehen. Die weitere Entwicklung des Projektes wird normalerweise von dessen Gründern oder den aktivsten Entwicklern gesteuert. Die Aufgaben dieser Projektleitung bestehen vorrangig darin, offene Aufgabe und deren Prioritäten festzulegen, zu entscheiden welche Quelltextbeiträge in das Projekt aufgenommen werden und die Planung für die Freigabe neuer Versionen vorzunehmen (vgl. Samoladas et al., [23] und Fielding et al., [13] in [11]). Tatsächlich fällt der Führungsgruppe damit eine Machtposition zu, die dem Entwicklungsprozess nach außen hin ein fast traditionelles Aussehen verleiht. Sehr charakteristisch für Open-Source-Projekte ist jedoch, dass offene Aufgaben in der Regel nicht direkt vergeben werden sondern vielmehr die Entwickler ihren Fähigkeiten und Interessen entsprechende Aufgaben auswählen. Im Gegensatz zu der Arbeit von Bauer und Pizka (vgl. [3] in [2]) geht der Autor in dem vorliegenden Text also sehr wohl von einem „geordnet-chaotischen“ Entwicklungsprozess in Open-Source-Projekten aus. Wie später gezeigt wird, sind nämlich insbesondere die „Chaos- Prozesse“ auf eine hoheWartbarkeit des Produktes und seines Quellcodes angewiesen – unabhängig von der Mitwirkung und dem finanziellen Engagement von Unternehmen aus der Wirtschaft. Die offensichtlichen Mechanismen zur Sicherstellung hoher qualitativer Ansprüche an ein Open- Source-Projekt stellt die bereits weiter oben erwähnte Auswahl der Beiträge der Entwickler durch die Projektleitung und die Priorisierung der offenen Aufgaben des Projektes dar. Wie Garcia und Steinmueller in [14] darlegen, laufen die Projektleiter dabei jedoch Gefahr, durch den „Fork“ eines neuen Tochterprojektes5 „bestraft“ zu werden. Sie weisen jedoch darauf hin, dass dies nur sehr selten vorkommt und geben als Gründe hierfür vor allem die Art der hierarchischen Strukturen innerhalb eines Projektes an: Open-Source-Projekte sind wissensbasierte Gesellschaften, in denen vor allem technisch überlegenen Entwicklern die Projektlei-tung obliegt. Deren Schiedssprüche werden von andere Entwickler möglicherweise eher als rein managementorientierte Entscheidungen akzeptiert. Das Wohlwollen der Masse der Entwickler ist aus der Sicht des Autors von ganz entscheidender Bedeutung für die Durchsetzung qualitativer Ansprüche und Richtlinien in einer Entwicklergemeinde, deren Mitglieder nicht mit finanziellen Mitteln motiviert werden können6. Wie Warsta und Abrahamsson (vgl. [29] in [10]) feststellen, entsprechen die in Open-Source- Projekten anzutreffenden Entwicklungsprozesse weitestgehend dem aus der Agilen Software- Entwicklung7 bekannten Vorgehensweisen. Verschiedene Autoren, beispielsweise Voightmann und Coleman (vgl. [28]), erklären, dass die hierbei entscheidenden Entwicklungsparadigmen – (1) Prüfung des Quelltextes durch viele Entwickler; (2) häufige Veröffentlichung des Quelltextes, auch in frühen Stadien des Entwicklungsprozesses; (3) gute, vorrangig autodidaktische Weiterbildung der Entwickler – insbesondere bei der Herstellung von Software für Anwendungsbereiche, in denen eine besonders hohe Funktionssicherheit gefragt ist, entscheidende Vorteile aufweisen. „Given enough eyeballs, all bugs are shallow“ (Raymond, [21]), die viel und kontrovers zitierte goldene Regel der Open-Source-Entwicklung; gewiss ist sie richtig, jedoch hat wohl bislang noch niemand wirklich ausreichend Augäpfel auf ein einzelnes Stück Quelltext angesetzt. Trotz aller Kritik an dieser sehr pragmatischen Behauptung (vgl. bspw. Bezroukov, [6]) ist es wichtig, darauf hinzuweisen, dass die Offenlegung von Quelltexten überhaupt erst die unabhängige Analyse und das schnelle Beheben von Fehlern einer Software ermöglicht. Thomas weist beispielsweise darauf hin (vgl. Thomas, [27]), dass viele Open-Source-Projekte auf- grund geringer Anwender- und Entwicklerzahlen ohne einen auch nur ansatzweise hinreichenden Einsatz von Test- und Verifikationstechniken auskommen müssen. Eine Orientierung an Methoden der Agilen Software-Entwicklung impliziert also keinesfalls eine konsequente Anwendung damit verbundener Testmethoden8. Resultierend daraus besteht bei vielen Projekte ein hoher Bedarf an zusätzlichem Einsatz von Entwicklungsmethodik und der konkreten Durchführung von Test- und Verifikationstätigkeiten ([ebd.]). Um die Qualität, insbesondere die Weiterentwickelbarkeit von Open-Source-Software messbar zu machen, bedienen sich verschiedene Arbeiten der direkten Analyse des Quelltextes. In [24] analysieren Schach et al. 365 Versionen des Linux-Kernels hinsichtlich der gegenseitiger Abhängigkeiten zwischen 17 ausgewählten Komponenten und dem gesamten Kernel. Ein hohes Maß an gegenseitigen Abhängigkeiten sollte in Software-Systemen insbesondere deshalb vermieden werden, weil sie die Wahrscheinlichkeit negativer Auswirkungen eines Fehlers in einer Software-Komponente auf andere Komponenten erhöhen. Auch machen sie die Software dadurch, dass Änderungen in einem Modul häufig auch Änderungen in anderen Modulen erzwingen, schlechter weiterentwickelbar. Des Weiteren verlangen derartige Abhängigkeiten einem Entwickler sehr viel Verständnis für das Gesamtsystem der Software ab. Sie erlauben es ihm nicht, sich auf eine Komponente mit klar abgegrenzter Funktionalität zu konzentrieren und verstärken damit die genannten Probleme (vgl. Page-Johnes, [20]). Schach et al. kommen zu dem Schluss, dass der Linux- Kernel ein gut definiertes modulares Design aufweist – der Indikator hierfür ist das lediglich lineare Anwachsen des Quelltextes über den betrachteten Versionen. Jedoch schließen sie aus dem exponentiellen Anwachsen gegenseitiger Abhängigkeiten, dass der Betriebssystemkern ohne ein grundlegendes Redesign in zukünftigen Versionen nur noch sehr schwer erweiterbar sein wird. Leider gibt es keine neueren Arbeiten, in denen die von Schach et al. untersuchten Merkmale für gegenwärtige Kernel-Versionen ausgewertet werden. Zu ähnlichen Ergebnissen kommen Samoladas et al. in [23]. In der Arbeit vergleichen sie verschiedene Open-Source-Projekte und partiell sogar Open-Source- mit Closed-Source-Software anhand eines „Wartbarkeitsindexes“. Dieser ergibt sich aus der Betrachtung verschiedener aus dem Quelltext bestimmbarer Werte wie dessen Größe, Komplexität und Selbsterklärungskraft durch Kommentare. Bei der Untersuchung von insgesamt neun Projekten in jeweils verschiedenen Entwicklungsstufen stellen sie fest, dass Open- Source-Projekte mit ähnlichen Problemen bezüglich der Weiterentwickelbarkeit zu kämpfen haben wie Closed-Source-Produkte, Open-Source- Entwicklungen der nicht-quelloffenen Software in dieser Hinsicht jedoch mindestens ebenbürtig ist und teilweise bessere Bewertungen erhält. Insbesondere die Arbeit von Samoladas et al. weist konkret darauf hin, dass die anfangs erwähnte Pareto-Verteilung auf die jeweils untersuchten Software-Projekte zutrifft und es tatsächlich nur etwa 20% des Quelltextes sind, die zu schwerwiegenden Problemen bei der Funktionssicherheit der Produkte führen. Offensichtlich wird das große Potenzial, das quelloffene Software einzig durch ihre Quelloffenheit besitzt, oftmals nicht hinreichend genutzt. |
