Open Source Jahrbuch 2008 - Business Linux Hanse Network

��� ������ �������
ne, informelle und intransparente Entscheidungsprozesse neben den öffentlichen
entstehen. 2
3 Chancen und Risiken von Eigenentwicklungen
Jedem Anwender steht es frei, selbst aktiv zu werden und Open-Source-Software seinen
individuellen Bedürfnissen anzupassen, indem er die Software umschreibt oder bei
fehlenden Programmierkenntnissen beziehungsweise mangelnden Kapazitäten einen
Dienstleister damit beauftragt. Dies hat Vor- und Nachteile. Er kann zwar, je nachdem,
um welche Art von Anwendung oder Software es sich handelt, die Funktionen
seiner Individualsoftware selbst bestimmen. Er riskiert aber, seine eigene Entwicklung
abseits des Hauptentwicklungsstrangs in einem so genannten Fork 3 zu betreiben,
sodass die Gefahr besteht, dass er von der allgemeinen Entwicklung der Software abgekoppelt
wird. Er tut daher gut daran, seine individuelle Lösung in generischer Form
wieder in die Community zurück ieÿen zu lassen, um die Chance zu wahren, dass
seine Veränderungen in den Hauptentwicklungsstrang aufgenommen werden oder
sich andere Benutzer nden, die ähnliche Aufgabenstellungen haben und die Lösung
weiterp egen. Der Aufwand, einen eigenen Fork zu p egen und nachhaltig mit dem
Hauptstrang der Entwicklung zu synchronisieren, ist hoch. Leichter ist es, wenn man
modular aufgebaute Software wie Python, Zope oder Plone einsetzt oder Software mit
Plugin-Schnittstellen, sodass man statt eines Forks des Gesamtsystems lediglich ein
individuelles Modul oder ein Plugin p egen muss. Modulare Software bietet dem Anwender
die Möglichkeit, einen Mittelweg zwischen der aufwändigen Entwicklung von
reiner Individualsoftware und der passiven Nutzung generischer Open-Source-Software
zu wählen. Er beginnt zwar, mit einem gewissen Aufwand ein eigenes Modul
zu entwickeln, kann aber den nachfolgenden P egeaufwand mit der Zeit senken,
wenn sein Modul von der Community angenommen wird. Das lässt sich allerdings
nicht steuern, da die Akzeptanz, die ein Modul in der Community erfährt, von vielen
Faktoren abhängt. Wie integriert es sich in den Gesamtzusammenhang? Löst es
allgemeine Probleme auf ef ziente Weise? Entspricht es den qualitativen Maÿstäben
der Community? Hinzu kommen kommunikative Ein üsse: Wie stark ist die Stellung
des Anwenders beziehungsweise Entwicklers in der Community? Wie gut kann der
Anwender beziehungsweise Entwickler sein Modul innerhalb der Community vermarkten
? Im besten Fall wird das selbst entwickelte Modul Teil der Gesamtsoftware
und der Anwender kann seinen P egeaufwand auf Null reduzieren. Im schlimmsten
Fall muss er sich dauerhaft allein um die P ege des Moduls kümmern. Festzuhalten
bleibt jedoch, dass Open-Source-Software den Aufwand für Eigenentwicklungen senken
kann, insbesondere dann, wenn die Community die individuelle Lösung annimmt
und fortan unterstützt. Eine Garantie dafür kann jedoch niemand geben.
2 Weitere Ein ussfaktoren werden in Stürmer und Myrach (2006) beschrieben.
3 Mit Forking bezeichnet man das Abspalten eines neuen Software-Projekts aus einem gegebenen Projekt.
10