Das große CMS-Dilemma

08.10.2008 Webwork 2 Kommentare

Die beiden Artikel von Gerrit und Peter sowie die jeweils daran anschließenden Diskussionen veranschaulichen wieder einmal das Dilemma im Zusammenhang mit der Auswahl und Nutzung von Content Management Systemen. Insbesondere bei kleineren Websites, die durch Benutzer (also nicht Entwickler oder Designer) mit Inhalten versehen werden sollen, driften die identifizierten Anforderungen und die durch die verfügbaren CMS realisierten Möglichkeiten oft stark auseinander. Erschwerend kommt hinzu, dass die schiere Menge der verfügbaren CMS jeden Normalsterblichen vor eine unlösbare Evaluationsaufgabe stellt.

Diskrepanz zwischen Anforderungen und Features

Generell soll das gesuchte CMS einfach zu bedienen sein, gleichzeitig aber genügend Freiheiten bieten um die geplante Struktur sowie Design und Layout der Website umsetzen zu können. Die verfügbaren CMS sind aber einerseits schwergewichtige und komplexe Gebilde mit vielfältigen, meist nicht benötigten Features, die auch gestandene Webentwickler abschrecken. Auf der anderen Seite existieren vielversprechende Ansätze mit übersichtlichen und einfach zu bedienenden Backends. Diese in der Regel schlanken Vertreter der Spezies CMS befinden sich allerdings meist in einem frühen Stadium der Entwicklung und weisen damit nicht alle benötigten Features auf oder sind noch nicht für den produktiven Einsatz geeignet. Hinzukommt dass sich bei jungen Projekten schlecht abschätzen lässt, wie aktiv diese in Zukunft gepflegt werden, was für einen langfristigen Einsatz ein K.O.-Kriterium darstellen sollte. Es stellt sich die Frage warum der Bereich der schlanken, leicht zu bedienenden und darüber hinaus ausgereiften CMS so dünn besetzt ist.

Vom schlanken Projekt zur überladenen Bloatware

Die Ursache für dieses Dilemma liegt meiner Meinung nach an dem Verlauf der Entwicklung eines CMS-Projektes. Initialzündung vieler in den letzten Jahren entstandener CMS-Projekte ist die Erkenntnis, dass die verfügbaren CMS viel zu überladen und die Backends zu umständlich sind. Die ersten und wichtigsten Features sind dann dank der Verfügbarkeit ausgereifter Frameworks schnell implementiert. Danach entscheidet sich dann ob das Projekt wieder einschläft oder aufgrund des Anklangs bei anderen Usern aktiv weiter entwickelt wird. Und genau hier liegt auch die Ursache des Dilemmas: Damit das Projekt erfolgreich bleibt, müssen die Entwickler auf die Wünsche der User eingehen, also Features die von einer Vielzahl der Nutzer gewünscht werden hinzufügen. Außerdem besteht bei einer aktiven Nutzerschaft ein Anreiz weiterzuentwickeln und möglichst regelmäßig neue Versionen herauszubringen, da dies verstärkt mit hoffentlich positivem Feedback belohnt wird. Letztendlich führt dieser Entwicklungs- und Implementierungsdrang aber dazu, dass das CMS immer komplexer wird. Diejenigen User, die die Entwicklung des CMS schon seit einem frühen Stadium mitgemacht haben, werden von der Komplexität nicht abgeschreckt, da sie sich mit dem System auskennen. Für die meisten anderen erscheint es jedoch im schlimmsten Fall wie überladene Bloatware. Dieser Trend zur „Featuritis“ bei zunehmendem Projektalter, lässt sich gerade bei populären CMS oder Blogsystemen – wie etwa WordPress – sehr gut beobachten.

Konsequente Beschränkung auf Kernfunktionalität

Diesem Problem ist sicherlich nur mit einer sehr disziplinierten Konzentration auf zuvor festgelegte Kernfeatures und einer konsequenten Modularisierung beizukommen. Wobei sich hier über die Kernfeatures sicherlich vortrefflich streiten lässt und zudem eine einfache Bedienbarkeit nicht automatisch aus der Beschränkung auf das Wesentliche resultiert. Darüber hinaus dürfte das eine oder andere CMS-Projekt mit genau diesen Vorsätzen an den Start gegangen sein. Die Tatsache, dass es das allseits beliebte leicht zu bedienende CMS (noch) nicht gibt, legt die Vermutung nahe, dass sich dem dargestellten Dilemma nicht entkommen lässt.

Wer möchte den Gegenbeweis antreten und der Welt das gefühlte milliardste CMS bescheren?

Kommentare

» Anne am 15. Oktober 2008

Klingt alles sehr plausibel.

Da fallen mir sofort zwei Schlagworte ein: Team und Geschäftsmodell. Okay, letzteres klingt wenig nach Open Source, bzw. wenig nach „umsonst und total günstig“.
Aber ich denke, neben dem mangelnden gemeinsamen Teamgeist bzw. Strang (der Joomla Effekt?) ist auch ein fehlendes Geschäftsmodell (in der gut und günstig Variante darf man auch sagen „ein fehlendes Konzept“) der Killer jeder großen Anwendung bzw. deren Nachhaltigkeit.

Dann lässt es sich auch viel leichter mal NEIN sagen.
Übrigens ist die Lizensierung qualitativ hochwertiger Open Source Software ja durchaus kein so schlechtes Denkmodell…

» Karsten am 16. Oktober 2008

Eine konsequente „Konzentration auf zuvor festgelegte Kernfeatures“ entspricht ja in gewisser Hinsicht einem Konzept oder Geschäftsmodell. Sich anschließend auch wirklich daran zu halten dürfte aber die Herausforderung darstellen.

Dein Kommentar

Zum Seitenanfang