Re: Content Management System

[daniel _at__ roedding.de (Daniel Roedding)]

Hallo,

Thomas Kiser schrieb:

>  - Open Source auf jeden Fall einzige Wahl (!) fuer Bibliotheken, da wir
> verpflichtet sind, unsere Informationsvermittlungstaetigkeit auf lange Zeit
> unabhaengig wahrzunehmen.

Da ich das Gefühl habe, daß hier ein klein wenig Dogmatismus
mitschwingt, möchte ich nur kurz noch folgendes gegenüberstellen:

- Szenario "Open Source Software" (OSS)
  pro: Der Anwender kann über lange Zeit unabhängig von Dritten das
       System völlig frei anpassen. (der von Ihnen geforderte Punkt)
  con: Er muß es möglicherweise selbst und ganz allein tun. Er hat
       auch keinen, der für ein OSS-basiertes System eine langfristige
       Gewährleistung erbringen kann - Support ja, Garantie nein

- Szenario "proprietäres Produkt"
  pro: Der Anwender kann mit dem Lieferanten einen Vertrag aushandeln
       und damit auch über einen erwarteten Nutzungszyklus eine
       Betriebsgewähr bekommen
  con: abhängig vom (CMS-)Produkt mehr oder weniger starke
       Lieferanten-/Dienstleisterbindung

Bezüglich der entstehenden Kosten möchte ich mal ganz frech behaupten,
daß OSS nicht zwangsläufig preisgünstiger ist (unter TCO-Gesichtspunkten).
Der Umkehrschluß ist aber genauso unzulässig. Hier helfen nur
Einzelbetrachtungen unter Alternativen, die man selbst aus einer
Vorauswahl übrig behalten hat.

Unabhängig vom eingeschlagenen Weg sollte man sich folgende Punkte
vor Augen halten:

1. ein heute installiertes Softwaresystem läuft nicht "unendlich lange"
   und wird auch nicht "unendlich lange" gepflegt werden *wollen*.
   Systeme haben typischerweise Nutzungszeiträume, nach denen sie
   irgendwie dann doch wieder überholt sind. Die in einigen Bereichen
   während des New-Economy-Booms stark zusammengeschrumpften
   Nutzungszeiträume werden zwar gerade wieder länger, mehr als
   6-10 Jahre weit würde ich aber dennoch nicht planen wollen.

2. Während des Nutzungszeitraumes ist wichtig, daß "irgendwie"
   (ob durch Vertrag mit Dienstleister, durch OSS-patchende
   studentische Hilfskräfte oder eigene nächtliche Sitzungen) das
   System sowohl nach innen wie auch nach außen auf einem sinnvollen
   Stand gehalten werden kann. Faktisch bedarf es dazu einer
   Unterstützung durch Fachkräfte, die in beiden Szenarien von
   extern kommen müssen.
   Der Tausch von Layouts an der Oberfläche ist dabei eigentlich
   durchgängig bei allen ernstzunehmenden Systemen das geringere
   Problem. Wichtig sind Fragen wie z. B. Security-Updates,
   Datenbank-Stabilität usw. Die echten Probleme entstehen in der
   Regel da, wo man von außen überhaupt keine Brennpunkte vermutet.
   Die bei OSS suggerierte "Vollkontrolle über das System" hört
   da auf, wo es um Dinge geht, die nicht mehr sichtbar sind.
   Da wird sie nämlich zum Hypothetikum: Einflußverhindernd wirkt
   dann nicht mehr die Software, sondern Zeit und Qualifikation
   des Administrators, der in die Tiefen des Systems hinabsteigt.

3. Während und insbesondere am Ende des Nutzungszeitraumes ist
   wichtig, daß offene Schnittstellen zu allen Bereichen bestehen,
   wo mit eigenen Daten umgegangen wird. Im OSS-Umfeld ist das
   implizit der Fall, bei proprietären, nicht vollständig offen-
   gelegten Systemen kann so etwas vertraglich vereinbart werden
   (z. B. Anforderung der vollständigen Entwickler-Doku des
   Softwareherstellers). Das ist dann zwar weniger offen als OSS,
   für die Realbedürfnisse aber auch hinreichend.

>  - Bei Open Source ist die Wahl eines geeigneten Dienstleisters, der die
> Open Source Loesung implementiert genauso wichtig wie die vorgaengige Wahl
> des Systems. Es ergibt sich hier demnach ein groesserer Evaluationsaufwand
> als bei einem Closed Source System (CSS), bei dem (meist) der Anbieter der
> Software identisch ist mit dem Implementierungsdienstleister.
> Bei CSS ist man dann aber eben (leider) auf Gedeih und Verderben
> ausgeliefert...

Die meisten modernen CMSe sind intern noch mal schichtenmäßig
aufgeteilt: Eine Basisschicht stellt Elementarfunktionen bereit,
darauf aufgesetzt wird quasi das eigentliche CMS realisiert.
Unter der Annahme, daß abgesehen von etwaigen Fehlerbehebungen
bei derartigen Systemen kein Eingriff in die unteren Schichten
erforderlich ist, lassen sich Projekte auf nicht-OSS-CMSen bei
vielen Dienstleistern so aufsetzen, daß nach der Erstrealisierung
eine Übergabe von Pflege und Betriebsverantwortung an den Anwender
möglich sind, wenn er dies wünscht.

Merke: CMS-Anbieter wissen (mittlerweile), daß viele Kunden ihre
Systeme selbst unter Kontrolle halten wollen, und können für dieses
Szenario auch passende Lösungen liefern. Das ist nicht mehr nur
ein OSS-Privileg. Rest siehe Hypothetikum aus 2.

> NB: Sehr entscheidend ist, welche spezielle Anforderungen gestellt werden.
> Einzig Open Source Systeme koennen von den Funktionen her detailliert
> angepasst werden - das geht aber sehr schnell ins Geld

Den ersten Teil dieser Aussage halte ich offengestanden
für ziemlich dogmatisch.


Zum Abschluß noch kurz ein paar Zeilen zur Motivation dieser
Antwort:

Als freiberuflicher Software-Entwickler kenne ich beide Welten.
Wir sind einerseits in OSS-Projekte involviert. Zum anderen ist
hier über die Zeit eine Menge Software entstanden (insbesondere
auch im Bereich dynamischer Webanwendungen und damit letztend-
lich auch im Bereich CMS), die nicht in das klassiche OSS-Raster
paßt. Von daher sehe ich - sowohl aus Dienstleister- wie auch
aus Kundenperspektive - beide Welten mit ihren Vor- und Nachteilen.
Einem Kunden, der eine Betriebsgarantie haben möchte, würde ich
niemals einen OSS-Flickenteppich (z. B. irgendwelche Perl/PHP/
MySQL/Java-Hybrid-Matschlösungen, wie erschreckend häufig in
dem Zoo da draußen zu finden) andrehen, sondern lieber ein
gekapseltes System mit Betriebsgarantie und kostenfreiem Update-
service für Basiskomponenten auf n Jahre anbieten. Dafür kann
nämlich bei Festlegung minimaler Rahmenparameter tatsächlich eine
Betriebsgarantie gegeben werden - und auch sichergestellt werden,
daß zukünftige Erweiterungen mit verbindlichen Aufwänden
realisierbar sind. Auch das ist im OSS-Bereich teilweise
problematisch - haben Sie ja auch schon angedeutet.

Viele Dinge sind dank der Vorarbeit der Open-Source-Gemeinde sehr
einfach, aber manchmal bringen gerade Kleinigkeiten auch große
Systeme ins Wanken. Insbesondere die "Update-Kaskaden" in
hochgradig verflochtenen, aber nicht homogenen Systemen können
da schnell Meta-Aufwände zu anderen Meta-Aufwänden entstehen.
Natürlich hat man - OSS sei dank - natürlich die volle Kontrolle
über alles, aber in solchen Momenten wären geschlossene, sauber
gegenüber dem Restsystem gekapselte Produkte bisweilen deutlich
praxistauglicher. Man kann eben nicht beides haben.

Viele Grüße,
Daniel Rödding


-- 
Daniel Roedding                                       phone: +49 5252 9838 0
daniel _at__ roedding.de                                      fax: +49 5252 9838 20