Plone und Drupal

Subjektive Entscheidungshilfen

Der Vergleich von Drupal und Plone gestaltet sich schwieriger; funktional spielen beide Systeme eher in derselben Gewichtsklasse, der technische Unterbau unterscheidet sich jedoch (Python/ZOPE bei Plone, PHP/MySQL bei Drupal). Während Jooma für mich - vergleichen mit Drupal eine Vielzahl objektiver Defizite zeigte, die sich auch klar benennen lassen, ist meine Entscheidung gegen Plone schwerer zu fassen.

Plone habe ich vor Drupal kennengelernt; meine erste ersthafte Installation baute auf Version 1.0.4 auf, und ich hielt das System für die eierlegende Wollmilchsau, die alle meine Anforderungen erfüllen konnte. Auf dem Papier - sprich: in der vollmundigen Selbstdarstellung auf plone.org - tat es das auch, doch die Praxis sah ganz anders aus. All die tollen Funktionen, die Plone angeblich haben sollte, waren keinesfalls so nützlich, durchdacht, leistungsfähig und robust wie versprochen.

Nicht zuletzt bekamm ich die Administration von ZOPE nicht hinreichend in den Griff, und bis heute habe ich nicht vollständig verstanden, wie die Abhängigkeiten zwischen Objektdatenbank, "Middleware" und Webanwendung tatsächlich ineinandergreifen; ich empfang es auch als extrem undurchsichtig, ständig zwischen der Plone-internen Administration und dem Zope Management Interfache (ZMI) wechseln zu müssen. Meine ersten Plone-Installationen waren jedenfalls alles andere als stabil, und die angeblich so komplexe Administration von Drupal mit PHP/MySQL-Unterbau halte ich für eine Banalität verglichen mit Python/ZOPE.

Plone wurde fleißig weiterentwickelt, und jede nue Version wartete mit immer fantastischeren Funktionen auf - solchen, die man weder im Drupal Core noch in in 3rd-party-Modulen findet. Dazu zählen beispielsweise ein Asset- und Link-Management, was beides in Drupal schlichtweg nicht existiert. Sporadisch setzte ich daher in den folgenden immer wieder Plone-Testumgebungen auf, fütterte das System mit Testdaten und wandte mich immer wieder enttäuscht ab: So schön das Link-Management in der Theorie auch sein mag, in der Praxis wird das Interface eine einer großen Anzahl von Verweisen unbenutzbar. In vielen Bereichen fehlten mir auch einfach Funktionen, die in Drupal selbstverständlich sind - die ich vielleicht einfach nur nicht finden konnte. Ab und an werfe ich zwar noch einen neidlosen Blick auf die Entwicklung von Plone, in meinem Toolbaukasten kommt es jedoch nicht mehr vor.

Welche Merkmale sind halbwegs objektivierbar? Während Drupal mittlerweile von einer ganzen Reihe von Schwergewichten eingesetzt wird, beschränkt sich die Verwendung von Plone wohl stärker auf Intranets; die Sichtbarkeit von Plone-Sites ist jedenfalls, verglichen mit Drupal, deutlich geringer. Auch funktional wendet sich Plone wohl eher an klar strukturierte Intranets-Umgebungen: Dokumente lassen sich in verzeichnisartigen Strukturen ganz ordentlich ablegen und auch in ihrem Kontext präsentieren. So lange die Website nicht zu groß wird und nicht zu viele Benutzer darauf zugreifen, scheint Plone auch eine brauchbare Performance aufzuweisen; auch ein solches Umfeld fidnet sich am ehesten in Intranets. Bei Plone-Sites im öffentlichen Internet muss man wohl mächtig mit Reverse Proxies (Aquid), sonstigen Caches und vorgeschalteten Webservern (Apache, Lighty) tricksen - mit dem internen Server kommt man nicht weit.

Community-Portale wie solche, für die Drupal konzipiert ist, setzen auch eine weit reichende Personalisierung voraus; Plone ermöglicht das durchaus, es ist jedoch vergleichsweise kostspielig, sprich: kostet Rechenzeit. Bei einer größeren Anzahl nicht-anonymer Benutzer muss man bei Plone von Anfang an tunen und so viele wie möglich individuelle Portletinhalte deaktivieren. Ähnliches gilt auch für Mediendateien wie Bilder: Hier wird man mit Plone nicht glücklich, bis man massiv mit Proxys wie Squid zu optimieren beginnt - was wiederum die Komplexität der Administration erhöht. Außerdem hatte ich den Eindruck, dass der Speicherbedarf der ZODB weit über den (hochoptimierter) MySQL-Datenbanken hinausgeht; in Tutorials liest man immer wieder von empfohlenen Frontend-Ausstattungen mit 12 GB und mehr Arbeitsspeicher - das empfinde ich als unverhältnismäßig. Auf meinen Testsystemen mit bescheidenen ein bis zwei GB RAM (und ohne Proxying) kam Plone jedenfalls nie so recht aus dem Knick.

Mein Fazit: Plone ist und bleibt ein spannender Mitbewerber zu Drupal. Ich konnte mich mit dem System jedoch nie anfreunden, weshalb ich die Entwicklung mittlerweile mit interesse, aber neidlos mitverfolgen kann. Als echte Alternative zu Drupal 6.x sehe ich Plone jedoch nicht mehr an.

Netmarks

  • Google Trends - Vergleichende Darstellung der Suchanfragen zu Drupal, Mambo, Joomla, Mediawiki und Tikiwiki