Risiko OSS: Indikatoren für das Scheitern von Projekten
Projekt
Prozessverbesserung für Freie und Open Source ProjekteArt
10% Theorie, 70% Quellenarbeit, 20% Evaluation
Bei speziellen eigenen Interessen ist eine Anpassung der Arbeit leicht möglich.
Beschreibung
Eines der Risiken, die sich v.a. für institutionelle und kommerzielle Anwender von Open Source Software stellen ist die Möglichkeit, dass das eingesetzte Projekt die Weiterentwicklung der Software aufgibt. Die Argumentationskette lautet folgendermaßen: OSS wird auf freiwilliger Basis ohne Kompensation entwickelt, deshalb besteht immer die Möglichkeit, dass die Entwickler von heute auf morgen die Arbeit einstellen. Dann habt der Anwender ein gescheitertes Produkt ohne Support und ohne Zukunft. Ärgerlich!
Dieser plakativen Schlusskette stellen die OSS Befürworter entgegen, dass sich immer ein interessierter Entwickler finden wird, der das Projekt übernimmt und weiterentwickelt. Im Zweifelsfall muss der Anwender selbst die Arbeit übernehmen.
Beide Standpunkte lassen empirische Argumente vermissen, die wir mit dieser Arbeit erarbeiten wollen. Es geht also darum:
- Fallbeispiele zu finden, an denen sich beide Seiten ausführlich beschreiben lassen, d.h. Projekte die wirklich aufgegeben wurden und solche, die eine Krise überstanden haben.
- Beschreibung der genauen Mechanismen der Aufgabe eines Projektes: Wieso passierte es? Was waren die Auslöser? Gibt es Muster in diesen Auslösern (z.B. die Zeit nach dem ersten Release ist immer kritisch)? Was unterscheidet Projekte, die nicht aufgaben von solchen, die heute nicht mehr existieren?
- Einen Leitfaden zu entwickeln, mit dem Firmen, öffentliche Stellen und auch Endanwender entscheiden können, ob ein Projekt Zukunft hat oder vielleicht demnächst nicht mehr existiert. Dieser Leitfaden kann verbunden werden mit einem Prüfsiegel, für welche sich Projekte zertifizieren lassen können.
Aufgabe
Diese Arbeit lässt sich in 4 Teile zerlegen:
- Sammeln von Fallgeschichten zum Thema Scheitern, Aufgabe, Generationenwechsel. Mit diesen werden wir Hypothesenbildung betreiben. Dies bedeutet viel in Mailinglisten stöbern, Leute befragen, etc.
- Empirische Stichprobensammlung auf Sourceforge zur Validierung unserer Hypothesen.
- Modellbildung und Leitfadenentwurf, Anwendung in einem Fallbeispiel (z.B. beim Diskussion um den Einsatz einer OSS-Software in einem Betrieb oder einer Schule). "Der nützliche Teil der wissenschaftlichen Arbeit".
- Ausarbeitung und Vortrag.