Die Presseabteilung der damals noch unabhängigen Star Division GmbH beklagte sich irgendwann darüber, dass das Unternehmen durch die regelmäßige Präsenz im Bug Report unfair behandelt würde. Das lag aber einfach daran, dass StarOffice eine unversiegbare Quelle für die kuriosesten Fehler war. Persönlich habe ich StarOffice nur unter OS/2 genutzt, weil es dort kaum alternative Office-Programme gab. Auch nach der Übernahme von StarOffice durch Sun und dem Erscheinen der Open-Source-Version OpenOffice habe ich die Software nur hin und wieder angeschaut, um ihren Entwicklungsstand zu verfolgen.

Als ich kürzlich ein neues Notebook einrichtete, hielt ich die Zeit für gekommen, auf MS Office zu verzichten und stattdessen OpenOffice zu wählen. Für meine relativ überschaubaren Anforderungen an ein Office-Paket sollte die freie Alternative ausreichen. Zudem war ich zuversichtlich, dass das mit zahlreichen Preisen dekorierte Projekt mittlerweile eine stabile Alternative zur Monopol-Software aus Redmond anbieten könne.

Der praktische Einsatz von OpenOffice 2.4.1. belehrte mich allerdings eines Besseren und ließ alte Erinnerungen an den Bug Report der PC-Welt wach werden. Nachdem ich einen relativ einfach formatierten, nicht allzu langen Beitrag als RTF-Datei abgespeichert hatte, erlebte ich beim Öffnen des Textes am darauf folgenden Tag eine böse Überraschung. Anstatt den Inhalt der Datei anzuzeigen, präsentierte mir OpenOffice eine lapidare Fehlermeldung über einen angeblichen Formatfehler.

Nachdem es sich bei RTF um ein Klartextformat handelt, müsste eine fehlertolerante Implementierung des Importfilters zumindest die unformatierten Benutzerdaten anzeigen können. Nachdem die Textverarbeitung das Problem in der letzten Zeile und letzten Spalte des Textes ortete, war mir klar, dass ich von OpenOffice keine Hilfe beim Reparieren des Dokuments erwarten konnte. Über mühseliges Experimentieren konnte ich den defekten Abschnitt aufspüren, nachdem sich die Demoversionen mehrere Reparatur-Tools auf das Anzeigen meines Text beschränkten und das Wiederherstellen verweigerten.

Gerade bei Software, für die man nichts bezahlen muss, nimmt man die eine oder andere Macke in Kauf. Wenn ein Programm jedoch meine Daten verliert, dann überschreitet es eine kritische Grenze. Eine Textverarbeitung, die nicht richtig speichern kann, zerstört jedes Vertrauen und hat bei mir keinen Auftritt mehr.

Bisher behalf ich mir damit, dass ich die Option “Leere Seite anzeigen” wählte, und die Startseiten beim Aufruf als Argumente an Firefox übergab, also nach dem Muster “firefox.exe website1.de|website2.de|..|website5.de“. In der Version 3 akzeptiert Firefox jedoch die Übergabe von mehreren URLs, die in eigene Tabs geladen werden sollen, so nicht mehr. Die ganze Zeichenkette landet im Adressfeld des ersten Tabs und führt erwartungsgemäß zu einem 404.

Die bisher beste Lösung schien mir, die Zeichenkette, die der Browser vorher als Parameter erhielt, in den Einstellungen als Startseiten festzulegen. Der Browser lädt aber mit einer leeren Seite, danach klicke ich auf das Homepage-Symbol, um die Startseiten zu laden. Das ist zwar nur eine Behelfslösung, aber sie klappt und kostet mich nur einen zusätzlichen Mausklick. Eleganter wäre es, wenn Firefox bei der Festlegung der Startseiten flexibler wäre.

Das Angebot an (freien) Wiki-Engines ist fast unüberschaubar. Wer ein Wiki einrichten will, hat also die Qual der Wahl. Ich habe mich in den letzten Wochen ein bisschen umgeschaut, um die passende Software für mich (und ein CW-Projekt zu finden). Hier ein kurzes Resümee:

Wie bei jeder anderen Software hängt die Wahl eines Wikis von den Anforderungen und der Systemumgebung ab. In meinem Fall sollte sich das Tool auf die Wiki-Kernfunktionen konzentrieren und nicht alle Features eines ausgewachsenen CMS bieten. Da für mein Web-Hosting-Paket nur Perl und PHP in Frage kommen, scheiden diverse Implementierungen in .NET, Python oder Ruby aus. Im Wizard von WikiMatrix kann man neben diesen grundlegenden technischen Aspekten auch weitere Kriterien wählen, um die Zahl der potenziellen Kandidaten weiter einzugrenzen. Dabei waren mir noch folgende Faktoren wichtig:

• Eine halbwegs einfache Installation der Software. Ich will keine Datenbanktabellen manuell anlegen müssen oder ewig in Konfiguationsdateien herumeditieren.
• Unterstützung für Themes, so dass man relativ einfach zwischen verschiedenen Layouts wählen kann. Vor allem möchte ein typisch Wiki-mäßiges Aussehen vermeiden.
• Das Rechte-Management sollte erlauben, dass Seiten entweder von jedem Besucher bearbeitet werden können oder dass sie nur Benutzer editieren dürfen, die ihre Mail-Adresse eingeben oder die ein Benutzkonto haben und sich authenfizieren.
• Die Software sollte frei sein. Dabei achte ich darauf, ob die Entwickler-Community einigermaßen aktiv ist und die Software regelmäßig aktualisiert (man beachte beispielsweise, wie schnell pkwiki2, der neue Stern am Wiki-Himmel verloschen ist). Zudem erleichtert eine große Auswahl an Themes und Plugins die Anpassung des Systems an die eigenen Bedürfnisse.

Unter den genannten Gesichtspunkten habe ich mehrere Tools untersucht. Meine Auseinandersetzung mit den einzelnen Engines reichten von der Recherche hinsichtlich meiner Anforderungen bis zur Installation einiger Programme. Die folgende Einordnung ist also kein Vergleichstest, sondern beruht auf unterschiedlich intersiver Auseinandersetzung mit den jeweiligen Wiki-Implementierungen. Einige hier nicht aufgeführte Systeme schloss ich relativ schnell aus, weil mir das Projekt (intuitiv) keinen überzeugenden Eindruck machte.

• Bei der Suche nach einer Wiki-Software kommt man kaum an Mediawiki vorbei. Schließlich läuft darauf die Wikipedia und das ist natürlich eine eindrucksvolle Referenz. Darin besteht aber gleichzeitig ihre größte Beschränkung:
  

  The program is primarily developed to run on a large server farm for Wikipedia and its sister projects. Features, performance, configurability, ease-of-use, etc are designed in this light; if your needs are radically different the software might not be appropriate for you.

  Die Installation ist weitgehend Handarbeit, Plugins muss man in dieser unübersichtlichen Tabelle zusammenklauben und die Unterstützung für Themes ist mager – sowohl was das Angebot angeht als auch die technischen Voraussetzungen dafür. Man kann sich anhand dieser oder jener Anleitung selbst ein Layout schnitzen.

• Wikka Wiki ist nach Angaben des Projektteams eine leichtgewichtige Wiki-Engine auf Basis von PHP und MySQL. Es handelt sich dabei um einen selbständigen Entwicklungszweig (”fork”) von WakkaWiki. Die Installation geht einfach vonstatten, man kopiert die Dateien per FTP auf den Server, richtet eine Datenbank ein und startet das Installationsskript. Danach sollte das Wiki lauffähig sein, bei meinem Test fehlte aber in der URL der Schrägstrich zwischen Hostnamen und Seite, weil das Setup den Wiki-Pfad ohne abschließenden ‘/’ in die Config-Datei eingetragen hatte.
  
  Wikka kennt ein fein abgestuftes Rechte-Management, das bis auf Seitenebene festlegen lässt, welcher Benutzer was tun darf (die Benutzernamen müssen in CamelCase geschrieben werden). Es eignet sich daher auch zum Betreiben “normaler” Websites, im Wikka-Jargon ist von Invisible Wiki die Rede. Das Aussehen lässt sich über Skins verändern, es handelt sich dabei aber um keine Templates, sondern bloß um CSS-Dateien. Die meisten Skins (etwa die im Skin Selector angebotenen) unterscheiden primär in Farbe und Positionierung der Wiki-Aktionen. Das Angebot an ansprechenden Oberflächen ist insgesamt ziemlich mager.
  
  Die Wikka-Community ist recht aktiv, für das System gibt es eine Reihe von Erweiterungen (”Actions” im Wikka-Jargon). Allerdings kann Wikka diesbezüglich mit PmWiki oder DokuWiki nicht mithalten. Gegenüber den beiden genannten Konkurrenten hat es zudem für den internationalen Einsatz einen gravierenden Mangel: es existiert nur in einer englischen Fassung, Lokaliserungen für andere Sprachen gibt es bis dato nicht.
• Tikiwiki versteht sich trotz seines Namens nicht als bloßes Wiki-Tool, sondern als Groupware und CMS, um alle Arten von Web-Anwendungen zu realisieren: Sites, Portale, Intranets und Extranets. Offenbar hatte das System in der Vergangenheit größere Sicherheitsprobleme, denn es wurden zuletzt eine Reihe von Security-Updates veröffentlicht. Die Kritiken in der kanonischen Liste für Wiki-Engines sind offenbar nicht mehr ganz frisch, fallen zum Teil aber nicht gerade positiv aus. Die letzte Version, die noch einige Neuerungen brachte, ist die 1.9.4 und wurde vor rund einem Jahr freigegeben. Seither gab es im Wesentlichen nur mehr Fehlerbereinigungen.
• Bitweaver ist ein Abkömmling von TikiWiki und verfolgt den gleichen CMS/Groupware-Ansatz. Trotz der besonderen Betonung von Performance, die im Vergleich zu TikiWiki erheblich verbessert worden sein soll, nähren solche Tuning-Anleitungen (every directory is scanned on every page load) meine Zweifel an der Ausführungsgeschwindigkeit der Software. Die aktuelle Version 1.3.1, die als Bugfix-Release angekündigt wurde, kam im Juni 2006 raus.
• ErfurtWiki ist eine von mehreren Wiki-Engines deutscher Provinienz. Sie wurde ebenfalls in PHP geschrieben und kann vollständig in einem einzigen Script (”monsterwiki script”) zusammengefasst werden. Daher lässt sie sich relativ einfach in (PHP-basiernde) Websites einbinden. Die Software unterstützt Themes (”Skins”), die Auswahl dafür ist indes relativ gering. Allerdings finden sich in der Liste auf Sourceforge einige gelungene Layouts. Die Anforderung einer differenzierten Rechtevergabe erfüllt die Software standardmäßig nicht, ihr muss dafür mit Erweiterungen auf die Sprünge geholfen werden:
  

  If you’d like to use authentication, you’ll probably want to chain some plugins which enable you to use the user database from yoursite.php (…) The easiest way to cripple a Wiki setup to be browseable-only for the larger public, and to allow only a small subset of users to edit pages is to write two wrapper scripts around the ewiki.php library.

  Bei meinen Besuchen der Sourceforge-Präsenz von EWiki zeigte sich diese von Vandalen übel zugerichtet. Die Dokumentation der Software besteht nur aus einer Klartext-Readme-Datei.

• PmWiki gehört zu den beliebtesten Wikis auf PHP-Basis. Im Unterschied zu Bitweaver oder TikiWiki konzentriert es sich auf der eigentlichen Wiki-Features. Allerdings lassen sich über Plugins viele Funktionen nachrüsten, die in den beiden genannten Systemen mitgeliefert werden. Unter den zahllosen Addons finden sich etwa solche, um PmWiki als Weblog-Software oder Diskussionen nutzen zu können. Die von mir gestellten Anforderungen kann PmWiki durchgängig erfüllen: Die Installation geht relativ unkompliziert vonstatten, das Layout lässt sich über Skins austauschen und ein differenziertes Rechte-Management kann den Zugriff bis auf die Ebene einzelner Seiten regeln. Zu den Eigenheiten von PmWiki zählt, dass es für die Speicherung keine SQL-Datenbank verwendet, sondern die Texte im Dateisystem ablegt.
• DokuWiki verfolgt einen ganz ähnlichen Ansatz wie PmWiki und erfüllt alle von mir gestellten Anforderungen: Open Source (GPL), einfache Installation, fein abgestuftes Rechte-Management, Themes und zahlreiche Plugins. Wie pmwiki verzichtet auch DokuWiki auf eine Datenbank und speichert die Texte in Dateien. Eine Spezialität von DokuWiki sind Namensräume, mit denen man seine Texte organisieren kann.

Unter den sechs von mir näher betrachteten PHP-Wikis kamen PmWiki und DokuWiki in die engere Wahl. Die Entscheidung fällt nicht leicht, weil beide Systeme einen sehr guten Eindruck hinterlassen und von aktiven Communities weiterentwickelt werden. Für den Einsatz bei der Computerwoche habe ich DokuWiki den Vorzug gegeben, nicht zuletzt aufgrund der Einschätzung von Harry Fuecks. Er hält die Speichermethode von DokuWiki für effizienter als jene von PmWiki, was bei einer großen Zahl von Dokumenten in punkto Performance von Bedeutung sein könnte. Ein weiterer Pluspunkt für DokuWiki war zudem, dass ich dafür ein attraktives Theme gefunden habe.

Siehe auch:

Tipps zum Betreiben eines Wiki

Der Nutzen von Blog-Modulen in Wikis

Das Ergebnis sieht so aus:

Ruft man die Funktion wp_title() nämlich ohne Parameter auf, dann gibt sie ein Separatorzeichen aus (standardmäßig ein »). Soll sie kein Trennzeichen erzeugen, muss man ihr eine leere Zeichenkette als Argument übergeben – nicht gerade intuitiv. Wie wäre es mit: wenn kein Trennzeichen, dann kein Parameter, wenn Trennzeichen, dann dieses der Funktion übergeben? Das hätte mir die mühselige Suche nach der Herkunft des nutzlosen » erspart. Und wer den Separator nicht vor, sondern nach dem Titel haben will, der muss tun, womit man unter WP alle möglichen Defizite behebt: ein Plugin installieren.

Solche Gegenüberstellungen gingen in der Regel zugunsten von Microsoft aus, schließlich können die dicken Desktop-Brummer einfach mehr als Googles Browser-Anwendungen. Beklagt wurde etwa häufig, dass die Premier Apps kein Gegenstück zu Powerpoint besäßen, dass die Web-Tools nicht offline-fähig seien oder dass die Textverabeitung keine Fußnoten beherrscht.

Einen echten Mangel entdeckten drei Analysten von Forrester Research in ihrem Kommentar auf CNet: ein fehlendes Pendant zu OneNote. Vermutlich weiß die Mehrheit der Microsoft-Office-Anwender gar nicht, dass sie dieses Programm mit dem Paket erworben haben, und noch weniger werden es nutzen.

Auch wenn die Debatte manchmal solche merkwürdigen Züge annimmt, so kommt immerhin wieder ein bisschen Bewegung in einen Markt, den Microsoft seit Jahren im eisernen Griff hält. In der letzten Ausgabe der Computerwoche habe ich drei Beiträge betreut, die einen guten Überblick über die aktuelle Entwicklung geben:

• Microsofts Office-Strategie: Collaboration ergänzt persönliche Produktivität
• Der Fahrplan für OpenOffice: OpenOffice: Community statt Featuritis
• Überblick über Web-Alternativen: Office 2.0: Online-Anwendungen statt Desktop-Schwergewichte

Während Microsofts Strategie, Office noch mehr mit den eigenen Server-Produkten und Programmierwerkzeugen zu verknüpfen, hinlänglich bekannt ist, waren mir die Absichten von OpenOffice.org weitgehend unklar. Das Kernprodukt nur mehr geringfügig zu erweitern und zusätzliche Funktionen nach dem Vorbild von Mozilla als Plugins anzukoppeln, entspricht einem konsequenten Open-Source-Ansatz. Der Beitrag von Stephan Lamprecht über Office 2.0 gibt eine gute Orientierung über die Aktivitäten von einschlägigen Web-2.0-Startups. Nach den Erfahrungen mit anderen Segmenten des IT-Marktes kann man allerdings davon ausgehen, dass die meisten von ihnen die kommende Konsolidierung bei Online-Office nicht überstehen werden.

[Via WWWorker]

Oracle gehörte zwar zu den ersten großen IT-Firmen, die Linux unterstützten. Ansonsten hat die Firma mit freier Software nicht allzu viel am Hut, weil sie ihr Geld vor allem mit Lizenzen verdient. Der größte Teil davon entfällt auf die Datenbank. Trotz aller Dementis empfindet Oracle MySQL als Störenfried, der die Preise verdirbt. Vor einem halben Jahr kaufte Larry Ellison die skandinavische Firma InnoDB. Sie liefert für MySQL eine Storage-Engine, die sich für die Transaktionsverarbeitung eignet – also für ein Einsatzgebiet, das Oracle dominiert. InnoDB erfüllt Anforderungen, die Unternehmen beispielsweise für kaufmännische Software stellen.

MySQL selbst unterstützt nur Tabellen vom Typ MyIsam. Salopp formuliert handelt es sich dabei um eine aufgebohrtes Dateisystem mit SQL-Schnittstelle. Es eignet sich gut für Anwendungen, bei denen die Lesezugriffe überwiegen und die nicht erfordern, dass beim Fehlschlagen einer Operation eine gesamte Transaktion zurückgenommen wird. Mit dem Kauf von InnoDB erlangte Oracle die Kontrolle über die Komponente, die MySQL für den Einsatz in Unternehmen häufig benötigt. Neil McAllister beschrieb damals in seinem Beitrag sehr schlüssig, welchen Nutzen der Kauf für Oracle brachte: Zugriff auf die Support-Datenbank von InnoDB, die Aufschluss darüber gibt, welche Kunden MySQL für anspruchsvolle Aufgaben einsetzen. Und einen genauen Überblick darüber, wieviele Lizenzen MySQL tatsächlich verkauft.

Im Rahmen seines modularen Konzepts hatte MySQL noch eine weitere Option für eine transaktionsfeste Storage-Engine. Sie spielte hinter InnoDB die zweite Geige und gewann nun an Bedeutung. Sie stammte von – richtig, Sleepycat. Und die hat Oracle jetzt auch kassiert. Auch wenn Oracle weder InnoDB noch Sleepycat schließt oder die Verträge mit MySQL kündigt, so müssen die Schweden nun zusehen, dass sie die Lücke selbst stopfen. Das dürfte den Zeitplan und die Produktstrategie der Firma vorerst etwas durcheinanderbringen.

Und Jboss? Gibt Oracle mehrere hundert Millionen Dollar für eine Firma aus, die gängige Java-Middleware herstellt – lauter Produkte, die Oracle selbst im Portfolio hat? Auch das finde ich unwahrscheinlich. Jboss war schon länger der Hecht im Java-Karpfenteich. Die Entscheidung von Sun, seine gesamte Server-Software als Open Source freizugeben, wurde m.E. nicht unwesentlich durch den Erfolg von Jboss beeinflusst. Gegen die aggressive Open-Source-Konkurrenz machte Sun kaum einen Stich, und die anderen Anbieter wie Bea und Oracle dürften sie auch zu spüren bekommen. Kürzlich schloss Hewlett-Packard ein Vertriebsabkommen mit Jboss, die der freien Software den Zutriit zu großen Firmen noch weiter erleichtern wird. Neben den Apache-Produkten trägt Jboss damit zur ökonomischen Entwertung einer ganzen Softwarekategorie bei – und zwar einer, mit der Oracle Geld verdienen will. Daher glaube ich, dass es Larry Ellison auch in diesem Fall primär darum geht, Jboss aus dem Verkehr zu ziehen und an die Kunden des Unternehmens zu gelangen.

Update: CNet berichtet, dass Oracle auch MySQL kaufen wollte.

Ein wesentlicher Beweggrund, die Weiterentwicklung einer geschlossenen Software in Frage zu stellen, sind die Kosten. Wenn bei 20 Mitarbeitern nur einer hauptsächlich mit der Programmierung beschäftigt ist, dann stellt dies schon eine erhebliche Belastung dar. Was ist also der Gegenwert? Setzt die Software Geschäftsprozesse um, die vor der Konkurrenz verborgen werden müssen? Enthält sie aufwändig entwickelte Algorithmen, die sonst niemand kennt? Ist die Software mithin ein Business Differentiator oder nur eine Enabling Technology? Im Fall von Knallgrau dürften sich diese Fragen schnell beantworten lassen. Software auch für große Weblog-Installationen ist Commodity, wie etwa Wordpress oder diverse freie Content-Management-Systeme belegen.

Verschenkt Knallgrau also seine Kernkompetenz? Das glaube ich nicht. Denn die besteht wie bei vielen Open-Source-Firmen darin, Services auf Basis der Software zu bieten. Bei Knallgrau sind das nicht der sonst oft übliche Support oder individuelle Anpassungen, sondern der Betrieb einer Medienplattform. Die Entscheidung könnte lehrbuchmäßig nach der Anleitung von Bruce Berens oder Eric Raymond erfolgt sein.

Mir ist allerdings nicht ganz klar, warum man auf eine BSD-ähnliche Lizenz gekommen ist, nachdem es schon vor einem Jahr Überlegungen in Richtung GPL gegeben hat. Diese gilt zwar als geschäftsfeindlich, wird aber paradoxerweise von einigen Firmen genutzt, die sich neuerdings mit dem Etikett “Commercial Open Source” schmücken. Das gilt etwa für MySQL oder Jboss (LGPL). Sie wollen mögliche Wettbewerber dazu zwingen, eigene Entwicklungen an das Projekt zurückzugeben.

Der Vortrag zu Forrest, einem Publishing-Framework auf Basis von Cocoon, half mir nach der etwas unklaren Selbstdarstellung des Projekts zu verstehen, worum es dabei geht. Im Wesentlichen definiert es ein XML-basierendes Darstellungsformat, das als Zwischenstadium dient, um Daten aus unterschiedlichen Quellen in diversen Zielformaten auszugeben. Auf der Input-Seite übersetzen Plugins das Eingabeformat (XML, Word, OpenOffice, etc.) in die intermediäre Repräsentation, für die das System mehrere konfigurierbare Output-Filter (Skins) bereit hält. Der Zweck von Forrest ist also das immer wieder propagierte Single Source Publishing. Das mag für bestimmte Textsorten (etwa Dokumentationen oder Bücher) funktionieren, meine Erfahrungen mit Zeitungs- oder Zeitschriftenartikeln stimmen mich eher skeptisch. Dort müssen Beiträge auf das jeweilige Medium angepasst werden. So kommt es beispielsweise in Print darauf an, dass Überschriften richtig laufen, während sie online für Suchmaschinen optimiert sein sollen. Letztlich kommt man an medienspezifischen Versionen der Texte nicht vorbei.

Der zweite Vortrag, der mir besonders in Erinnerung geblieben ist, ging über die Rules-Engine Drools. Es handelt sich dabei zwar um kein Apache-Projekt, es unterliegt aber einer Apache-ähnlichen Lizenz. Rules-Engines gehen auf die Expertensysteme der 80er Jahre zurück und sind in der Lage, aus einer Kombination von Regeln und Fakten selbständig Schlüsse zu ziehen. Früher waren sie vor allem komplexen Anwendungen im Finanzsektor vorbehalten, wo sich die vielfältigen Bedingungen (gesetzliche Vorschriften, Marktentwicklungen) laufend verändern und daher nicht als bedingte Anweisungen fest in die Programme codiert werden sollten. Vielmehr werden sie als Regeln in eine eigene Rules-Engine gefüttert. Durch Open-Source-Implementierungen wie Drools verlieren sie diesen exklusiven Charakter, auch wenn kommerzielle Highend-Produkte wie Ilog wesentlich mächtiger sind. Das freie Drools eröffnet für Rules Engines neue Einsatzgebiete in weniger exklusiven Anwendungen, wie etwa die Personalisierung von Content oder die Umsetzung komplexer Zugriffsrechte.

Siehe auch:

ApacheCon-Blog

Bilder von der ApacheCon

Vorteile:

• Zu den offensichtlichsten Vorzügen gehört der große Funktionsumfang eines ausgewachsenen CMS. Der kommt einem auch dann zugute, wenn man mit dem System nur ein Blog betreiben möchte. Denn auch dieses Modul profitiert von Features, die Bestandteil des Frameworks sind. Das gilt etwa für die rollenbasierte Rechtevergabe, die Versionierung der Inhalte oder die aus dem Forum-Modul stammende Anzeige von Diskusionen in einer Baumstruktur (”threaded discussion”).
• Trotz des größeren Umfangs von Drupal im Vergleich zu reiner Blog-Software fällt die Installation nicht wesentlich schwerer. Nach Einrichtung der Datenbank und Anpassung einer einfachen Konfigurationsdatei kann man die meisten Adminstrationsaufgaben in einer Web-Oberfläche erledigen.
• Wenn man neben seinem Blog vielleicht noch andere Content-Typen publizieren möchte, etwa statische Seiten, Foren oder Online-Artikel (”Stories”), dann kann man das mit Drupal gleich tun und muss keine separate Software installieren. Von der Community gibt es zudem noch Module für Buchbesprechungen, Comics, Gästebücher oder Projektverwaltung. Flexinode erlaubt zudem die Definition beliebiger (einfacher) Typen durch den Benutzer. Die Wiki-Unterstützung wird ihren Namen allerdings nicht gerecht.
• Die sehr aktive Community entwickelte neben Erweiterungen für neue Content-Typen eine Vielzahl von Extensionen, die Drupal für viele Aufgaben empfehlen. Ihre Installation fällt i. A. sehr einfach: Das gezippte tar-Archiv wird im Verzeichnis modules entpackt, anschließend taucht das Modul in der Administrationsoberfläche auf und kann dort konfiguriert werden.
• Im Gegensatz zu älteren MT-Versionen bietet Drupal die Möglichkeit, WYSIWYG-Editoren einzubinden (die ich persönlich aber nicht brauche, weil ich keine Angst vor ein bisschen Markup habe ;-). Zur Auswahl stehen Htmlarea und FCKedit.
• Ansonsten haben mir noch folgende systemweit verfügbaren Funktionen gut gefallen:
  • Mit dem Sticky-Attribut können Beiträge dauerhaft auf der Homepage verankert werden.
  • URL-Aliases erlauben die beliebige Zuweisung von Pfaden zu einzelnen Einträgen oder bestimmten Content-Typen.
  • Beschreibung der Inhalte durch vielfältige Metadaten: Mehrstufige Taxonomien, Kategorien oder Folksonomies.
  • Drupal wurde in verschiedenen Sprachen lokalisiert, unter anderem auch in Deutsch.
  • Eingebautes Statistikmodul und die Möglichkeit für Abstimmungen (”Polls”).

Nachteile: Der große Funktionsreichtum und die daraus resultierende Komplexität sind auch die größte Hürde bei der Einrichtung eines Drupal-basierten Weblogs. Hier ein paar Beispiele:

• Auch wenn Drupal den Content-Typ Blog-Posting kennt, ist das System nach der Installation längst keine betriebsbereite Weblog-Software wie MT oder Wordpress. So müssen einige Funktionen erst über separate Module nachgerüstet werden, etwa Trackbacks (inklusive manueller Erweiterung des Datenbankschemas) oder die Erzeugung von “sprechenden” URLs, die den Titel des Postings enthalten (via Pathauto). Das Gleiche gilt für Uploads, die erst nach der Installation einer entsprechenden Extension möglich sind. Wer sein Blog nicht unter der standardmäßigen URL vom Typ http://meine.site.de/blog/1 finden will, muss ein URL-Alias definieren.
• Der größte Brocken für Umsteiger von anderen Blog-Systemen ist m. E. das Drupal-Konzept für Themes. Die zahlreichen Grundsatzdiskussionen in den Foren zeigen, dass die Community damit selbst nicht zufrieden ist. Themes bestehen wie bei anderen Systemen auch aus Templates und CSS-Stylesheets. Allerdings gibt es für Drupal mehrere Template-Engines, die völlig verschiedene Schablonen für Webseiten verarbeiten. Die zwei wichtigsten Engines sind XTemplate und PHPTemplate. Die Erstellung von beiden Template-Typen erfordert zumindest grundlegende PHP-Kenntnisse. Verglichen mit der Fülle an Template-Tags, die MT bietet, sind die Möglichkeiten der entsprechenden Drupal-Variablen eher ärmlich. Das liegt zum Teil daran, dass das Layout maßgeblich über das Admin-Interface gesteuert wird.
• Die Eigenarten von Drupal-Themes verlangen einige Klimmzüge, um ein gewohntes Blog-Layout umzusetzen. So geht Drupal standardmäßig davon aus, dass alle Seiten auf dem gleichen Template basieren. Bei meinem Blog ist das der Fall, aber viele Sites stellen etwa die Einzelbeiträge anders dar als die Homepage. Wenn man das bei Drupal will, dann kostet das einige Anstrengungen.
• 
  Ungewohnt für Anwender alternativer Blog-Software ist das Fehlen der üblichen Struktur für Postings, die sich in Entry Body, Extended Entry und Excerpt unterteilt. In Drupal kann man einstellen, dass die ersten x Zeichen automatisch als Teaser herangezogen werden, oder man nutzt die Anweisung <!– break –>, um einen Seitenumbruch einzufügen. Alternativ gibt es noch ein Zusatzmodul namens Excerpt, das die getrennte Eingabe eines Abstracts vorsieht.

Angesichts der enormen Komplexität eines ausgewachsenen Web-CMS frage ich mich, ob das Konzept einer integrierten Anwendung für allzu viele Sites sinnvoll ist. In den meisten Fällen dürfte man mit einem “Best of Breed” besser fahren, indem man eine spezialisierte Software für Blogs und Wikis installiert. Man hat dann zwar keine übergreifende Benutzer- und Rechteverwaltung, sowie separate Layouts/Templates. Aber der Lernaufwand dürfte immer noch geringer sein als für eine eierlegende Wollmilchsau wie Drupal. Ich habe mit noch nicht entschieden, ob ich auf dieses CMS umsteigen werde. Aber wenn ich daran denke, dass es mir bisher noch nicht gelungen ist, unter einer normalen Benutzerkennung bestehende Blog-Inhalte zu editieren, dann muss ich noch viel Zeit in dieses System investieren, bis ich damit mein Blog betreiben kann.

Auch wenn die Bezeichnung Framework normalerweise nach Rohmaterial für Programmierer klingt, soll sich Forrest besonders durch Benutzerfreundlichkeit hervortun. Zum CMS fehlen dem Tool offenbar einige wesentliche Funktionen. So konnte ich keine Hinweise auf Workflow-Unterstützung oder eine differenzierte Rechteverwaltung finden. Auf der ApacheCon nächste Woche in Stuttgart gibt es einige Veranstaltungen zu Forrest. Ich bin nur am 20.7. und 22.7. auf der Konferenz, aber wenn sich Gelegenheit ergibt, möchte ich ein bisschen mehr über Forrest herausfinden.