Argumente für Open-Source-CMS

[Robert Kehl]

Hallo Stef!

Am 07.07.2014 17:32, schrieb Stef:
> bei meinem Arbeitgeber steht möglicherweise irgendwann eine
> Entscheidung über ein neues Content Management System an. Da über ein
> proprietäres Produkt nachgedacht wird, möchte ich ihn davon
> überzeugen, Open-Source-Alternativen zumindest in Erwägung zu ziehen.

Über welches wird denn nachgedacht? Nur aus Neugierde...

> Mein Hauptargument wäre die Vermeidung von Vendor-Lock-In: Bei Open
> Source könnte man mit verschiedenen Dienstleistern zusammenarbeiten,
> In-House-Personal zur Unterstützung anheuern (bei einer Organisation
> mit über 500 Mitarbeitern sicherlich eine realistische Alternative),
> eigene Features nach Wunsch entwickeln lassen etc.

Guter Ansatz, aber: Das kannst Du meist auch bei proprietären Systemen.

> Ich würde mich sehr freuen, wenn Ihr mich mit weiteren Argumenten
> unterstützten oder auch das Thema Vendor-Lock-In im Zusammenhang mit
> CMS noch weiter detaillieren könntet. Hilfreich wären auch kurze
> Erfahrungsberichte!

Eine Gefahr bei proprietären Systemen ist diese:

Der Hersteller "schenkt" Dir sein Produkt für, sagen wir 750 €. Wow -
unschlagbar, dafür bekommst Du noch nicht mal einen Externen, der Dir
ein OpenSource-System aufsetzt pro Tag. Der Haken an der Sache: Du
brauchst vom selben Hersteller noch einen Datenbankserver, natürlich auf
Hardware, mit 10 GBit/s angebunden, gedoppelt und an einem zweiten
Standort noch mal vervierfacht inklusive der dafür notwendigen Lizenzen.

Für den Client-Zugriff empfiehlt der Hersteller dann ein
Client-Access-Array aus gedoppelten Webservern, die direkt an das
Verzeichnissystem der Firma angebunden werden können. Ach, es gibt noch
kein wirklich etabliertes Verzeichnis? Das muss schon sein, oder sollen
die Logins doppelt gepflegt werden? Zum Einsatz kommt: Das
Verzeichnissystem desselben Herstellers, meist ein "aktives".

Selbstredend ist auch das doppelt und vierfach ausgelegt, denn eine
Downtime auch noch 18:00 Uhr kann sich heute niemand mehr erlauben.

Zur Überwachung bietet sich ja Nagios & Co. an - wäre da nicht das
fertig ver/geschnürte ManagementPack für das herstellereigene
Überwachungssystem, für das alleine noch mal zwei bis vier DB-Server und
Minimum zwei ClientAccess-Server fällig werden. Da das
Überwachungssystem bereits eingeführt ist und die zwei bis fünf
bisherigen Applikationsserver versucht zu überwachen, ist diese Lösung
gegen ein neu einzurichtendes Nagios o. ä. natürlich "die bezahlteste".

Da das neue CMS die neuesten Features von AktivZ, SilberLicht & Co. des
Herstellers erfordert, um vernünftig funktionieren zu können (was
niemand vorher testet), gerät die Nutzung eines OpenSource-Browsers ins
Hintertreffen - warum sollten die Nutzer auf einen anderen Browser fürs
Internet ausweichen, wenn sie den ganzen Tag mit dem einen sich im CMS
umtun.

Und so wird aus dem billigen CMS plötzlich ein unglaublich breites
Monster, das nicht mehr wegzudenken ist: Too big to go away.

Jemand erzählte mir mal ein ganz realistisches Beispiel eines anderen
Systems:

OpenSource-Lösung:
Server: 2 x DB, nicht dediziert, 1(2) x WebServer (HA)
Storage: 2 x 40 GB (DB), 1 x 2 GB (Webserver)
Verzeichnisdienst: vorhanden (LDAP)
Überwachung: vorhanden (Nagios)

proprietäre Lösung:
Server: 4 x DB, dediziert, 4 x WebServer (Cluster), 2 x Management
Storage: 700 GB all in
Verzeichnisdienst: 1 Server r/o, dediziert, div. GB
Überwachung: 1 Server, deiziert

Mit fröhlichem Gruß

Robert Kehl