Warum habe ich TWiki ausgewählt

Meine Anforderungen

Ich habe die Idee, ein WikiWikiWeb als Notizbuch für die Speicherung aller meiner Notizen, Zettel, Hobbies usw. einzusetzten. Dazu muss es ganz einfach zu handhaben sein (statt Zettelschreiben, schnell ins Wiki eingeben, ohne Technologie-Schwellen-Barriere). Soll so einfach sein, wie das Schreiben von E-Mails. Stichwort: elektronischer Zettelstapel auch als eine Art Knowledge Management für private und auch berufliche Zwecke.

Ich möchte die Sachen leicht wiederfinden können, d.h. Volltextsuche und Kategorisierung ist wichtig. Die so gespeicherten Informationen müssen dort sicher aufgehoben sein. Ein Datenverlust muss ausgeschlossen sein. Die Inhalte werden langfristig (> 10 Jahre) genutzt und müssen prinzipiell in neu aufkommende Systeme migrierbar sein.

Der Übergang von einem Computer auf einen anderen (Nachfolger oder parallel) und die Veröffentlichung zum Web-Provider soll leicht möglich sein.

Es soll sich in die bei mir vorhandene IT mit geringstem Zusatzaufwand möglichst nahtlos einfügen.

Meine IT-Architektur

• Betriebssystem: (1) Windows, (2) Linux
• WebServer: (1) Apache,…
• Scriptsprache: (1) PHP, (2) Perl
• Datenbanken: (1) MySQL, (2) MicrosoftAccess, (3) dBase

Meine Bewertungskriterien

• Zukunftssicherheit
• Stabilität und Fehlerfreiheit
• Export-/Import-Schnittstelle (Datensicherung und Datenaustausch)
• Funktionalität (Volltextsuche,…)
• Konformität mit meiner IT-Architektur (s.o.)
• Betreibbar bei einem meiner WebProvider-Provider
• Dokumentation und Support

Meine Shortlist

• PhpWiki
• MediaWiki
• UseModWiki
• TikiWiki
• TWiki
• JSPWiki

Nicht auf die Shortlist kam

• pmwiki, da es eine zu kleine Community hat. Sieht aber sehr gut aus und ist eine reine PHP-Lösung (ohne SQL). http://www.pmichaud.com/wiki/Main/HomePage
• MoinMoin, weil es mit Python statt PHP für mich zu exotisch war. (Allerdings sehr interessant, weil es ohne RCS/CVS/MySQL auskommt und weil die Jakarta/Apache Community es als ihr Wiki http://wiki.apache.org/jakarta/ ausgeählt hat.)
• cowiki, weil es noch zu neu ist und PHP5 benutzt: http://www.develnet.org
• DocBook Wiki, weil ich es noch nicht kannte (http://sourceforge.net/projects/doc-book/)

Meine Kurzbewertung

Für PhpWiki sprach die Konformität mit meiner IT-Archtektur (PHP und MySQL). Gegen PhpWiki sprach letztlich die Instabilität und die kleine Community/Präsenz (kleines Entwicklerteam, wenig Dokumentation und Support, wenig Websites mit PhpWiki).

Für MediaWiki spricht die hohe Stabilität und Reife, die sich darin zeigt, dass die Wikipedia mit MediaWiki gemacht ist. Gegen MediaWiki sprach die höhere Komplexität und die Tatsache, dass MediaWiki ausser für mehrere Wikipedias ansonsten kaum von anderen grösseren Wiki-Sites eingesetzt wird. Die fehlende Import-/Export-Schnittstelle war ebenfalls ein Minuspunkt.

Für UseModWiki (http://www.usemod.com/cgi-bin/wiki.pl) sprach die gute Stabilität und Community/Präsenz, die sich darin zeigt, dass auf Basis von UseModWiki mehrere grosse Wikis betrieben werden z.B. [Meatballwiki|http://www.usemod.com/cgi-bin/mb.pl Meatballwiki]. Ein Minuspunkt aus meiner Sicht ist die nicht so gute Konformität mit meiner IT-Architektur (Perl statt PHP). Gegen UseModWiki sprach letzlich der relativ schlichte Funktionsumfang; z.B. gibt es keine gute Export-/Import-Schnittstelle.

JSPWiki (http://www.jspwiki.org) habe ich im März 2005 bei einem grossen Anwender in der Schweiz kennengelernt. Vorteile sind: Kommt ohne RCS/CVS/MySQL aus. Kommt ohne Perl aus, wofür dann JSP erstmals in meine Architektur käme – was aber sicher als fällige Weiterentwicklung in die Java-Welt positiv gesehen werden kann. Die Frage ist, ob ich WebProvider-Provider finde, die JSP unterstützen.

Für TWiki sprach die hohe Stabilität und gute Community/Präsenz (inkl. Dokumentation und TWiki:Support ), die sich in der grossen Verbreitung von TWiki als Basis von öffenlichen und firmen-internen Websites zeigt siehe: TWiki:Main.TWikiSuccessStories
Bestechend ist die sehr reichhaltige Funktionalität. Gegen Twiki sprach die nicht gute Konformität mit meiner IT-Architektur wegen Perl (statt PHP) und RCS als Datenhaltungssystem statt MySQL. Mit Perl konnte ich mich angesichts der Tatsache, dass mein WebProvider-Provider es unterstützt und es als zweite Wahl in meiner IT-Architektur gesetzt ist, schon anfreunden. RCS als Datenhaltung für das Wiki schien auf den ersten Blick recht merkwürdig, war aber bei näherer Betrachtung durchaus akzeptabel, denn RCS ist klassischer UNIX-Bestandteil und auf allen Plattformen (Cygwin) verfügbar. Gegenüber einer Datenbanklösung (z.B. MySQL) ist RCS leichtgewichtiger und löst auch das für mich ganz wichtige Probelm einer Export-/Import-Schnittstelle – zwar nicht ganz so wie eigentlich gedacht, aber die Basisfunktionalität Export/Import ist da.

— Main.DietrichKracht – 31 Dec 20033