Open Source Jahrbuch 2008 - Business Linux Hanse Network

���� ������ ������� ���������� � ���� ��������� �����������
gen und der Realisierung im Vordergrund. Funktionalitäten werden bei Bedarf in der
Implementierungsphase entwickelt.
Bei den Herstellern der meisten kommerziellen CMS sind die Programmierer des
Systems auch Mitarbeiter des Unternehmens. Das CMS an sich ist bei manchen Anbietern
kostenlos, es entstehen nur Implementierungskosten. Andere Anbieter verlangen
die erste Zahlung, wenn dem Unternehmen das noch nicht angepasste CMS zur
Verfügung gestellt wird. Das heiÿt die Anfangskosten müssen neben den Implementierungskosten
auch mit in die CMS-Anschaffungskosten einkalkuliert werden.
Bei OS-CMS kann das Unternehmen den Entwickler am Markt frei wählen. Durch
die freie Verfügbarkeit des OS-CMS entstehen für das CMS an sich keine eigenen
Kosten. Allerdings können die Kosten für das Erweitern des Systems je nach Anforderungen
und Dienstleister stark schwanken. Deswegen sollte die Suchphase weder
zeitlich noch nanziell unterschätzt werden. Unbedingt in die Kalkulation mit aufgenommen
werden sollten die Schulungskosten. Gerade bei OS-CMS-Projekten wird
hier oft am falschen Ende gespart. Die Ef zienz im CMS-Einsatz sinkt deutlich, wenn
Redakteure und Administratoren nicht ausreichend geschult sind.
2.2 Lock-In und Unabhängigkeit
Wechselkosten entstehen, wenn ein Kunde den bisherigen Produktanbieter, Dienstleister
oder das bisherige Produkt wechselt (Hess und Anding 2003). Diese Kosten
entstehen unabhängig davon, ob ein kommerzielles oder OS-CMS verwendet wird.
Allerdings gibt es deutliche Unterschiede in der Höhe der Wechselkosten.
Sehen wir uns als erstes Szenario den freiwilligen Wechsel des Produktanbieters
bzw. Dienstleisters an: Bei einem kommerziellen Produkt ist die Abhängigkeit von dem
bereitstellenden Unternehmen hoch. Das Know-how liegt nur bei dem Unternehmen,
das das System entwickelt hat. Oft liegt der Quelltext nicht offen und Informationen
über die Struktur der Daten sind schwer zu gewinnen. Dies erhöht die Wechselkosten
und erzwingt meist einen Wechsel auf ein anderes System.
Bei einem Open-Source-CMS liegt das Wissen über das System in der jeweiligen
Community offen. Je nach Marktanteil und Gröÿe des Projekts gibt es u. U. sehr viele
Anbieter, die das System erweitern und administrieren können. Das heiÿt auch, dass
mit einem Dienstleisterwechsel nicht sofort ein Produktwechsel verbunden ist.
Nun zum zweiten Szenario, dem erzwungenen Produktwechsel: Es gibt in der
Projektstruktur von Open-Source-Projekten unkalkulierbare Risiken. Beispielsweise
könnten sich die wichtigsten Entwickler streiten und die Entwicklung des Systems
einstellen bzw., wie bei Mambo geschehen, das Projekt aufspalten. Dies führt zu
gröÿeren Unsicherheiten; beispielsweise war einige Zeit unklar, ob man weiter bei
Mambo bleiben oder auf das abgespaltene Projekt Joomla! setzen sollte. Diese Risiken
sind in etwa vergleichbar mit den Risiken des Konkurses eines kommerziellen
CMS-Anbieters. Allerdings kann in einem solchen Fall die Wissensgewinnung über die
201
Entscheiden