Das originale Wiki ist absolut offen angelegt, was es für viele potentielle Anwendungen ausschließt. Verschiedene Stufen von Benutzer- und Contentkontrolle sind daher meist die ersten Punkte, die in der Featureliste erweiterter Wiki-Server auftauchen. Für statische Websites mit Wiki-Backend oder Extranet-Wikis sind diese Features unabdingbar. TWiki^[13] ermöglicht die Registrierung individueller Benutzer, sowie das Anlegen von Benutzergruppen und die feingranulare Vergabe von Schreib- und Leserechten (pro Seite), und lässt damit in diesem Punkt kaum Wünsche offen.

Die „RecentChanges“-Seite ist ein Grundbestandteil des Wiki-Konzepts und Anlaufpunkt für regelmäßige Besucher. Im originalen Wiki ist sie sehr einfach über den Timestamp der geänderten Seiten implementiert. Mächtigere Funktionen zur Protokollierung stehen ebenfalls weit oben in der Featureliste besserer Wiki-Server. Sie speichern in der Regel eine detaillierte Historie jeder einzelnen Seite. Eine meist „diff“ genannte Funktion ermöglicht die genaue Verfolgung aller gemachten Änderungen.

In einer offenen Umgebung wie einem Wiki muss der Schutz vor böswilligen Eingriffen bedacht werden. Das originale Wiki verlässt sich hierbei lediglich auf eine externe Backup-Lösung und hat überraschend gute Erfahrungen damit gemacht.^[14] Wie schon erwähnt, speichern viele andere Server eine Historie aller Seiten und ermöglichen dadurch auch das Rollback jeder einzelnen Seite zu einem beliebigen vergangenen Zeitpunkt.

Diese ist bei einem Wiki per Definition gegeben. Verschiedene Seiten können natürlich unabhängig voneinander bearbeitet werden. Konflikte bei der gleichzeitigen Bearbeitung der selben Seite durch mehrere User werden im originalen Wiki nicht abgefangen. Die anderen untersuchten Server warnen den User beim Speichern der Änderungen, so dass er selbst seine Änderungen mit denen des anderen Users abgleichen kann. TWiki warnt schon am Anfang des Editiervorgangs, dass die Seite zur Zeit von einem anderen User bearbeitet wird.

Ein solches Konzept ist in den betrachteten Wiki-Servern nicht bekannt. Die zuletzt beschriebene Funktion von TWiki kann als eine Art von Checkout-Support betrachtet werden. Heutige Wikis haben wenig Bedarf nach dieser Funktion, Wiki-Content wird nicht für mehrere Tage ausgecheckt. Gründe dafür sind die informelle Natur der meisten Wikis und die Art des Contents (einfacher, „flacher“ Text). Bedarf für diese Funktion ist aber durchaus vorstellbar, z.B. wenn ein Buch kollaborativ mittels einem Wiki geschrieben wird.

Hier tritt ein deutlicher Unterschied zwischen Wikis und CMS zutage. Bei letzteren ist die Fähigkeit zur Anreicherung der verwalteten Objekte mit Metadaten ein wesentliches Merkmal. Wikis hingegen kümmern sich kaum um Metainformationen. Der originale Wiki-Server begnügt sich mit den vom Dateisystem gebotenen Attributen und speichert keinerlei zusätzliche Daten. Warum Wikis trotzdem funktionieren, ist eine interessante Frage, der später ein eigener Abschnitt gewidmet werden soll.

Zum Thema Verwaltungsfunktionalität sei nur eines am Rande angemerkt: Eine charmante Eigenschaft der Wikis ist, dass es per Definition keine toten Links gibt (zumindest Site-intern).

Der Mangel an Metainformationen in Wikis beschränkt auch die Möglichkeiten zur Formulierung von Anfragen. Typischerweise unterstützte Anfragen sind die Suche nach Seitentitel, die Volltextsuche, RecentChanges (Liste der letzten Änderungen) und Backlinks (Liste der Seiten, die auf Seite X linken), sowie die Suche nach verwaisten Seiten, die keinen „eintreffenden“ Link mehr haben. Die phantasievolle Verwendung von WikiWords kann weitere Anfragemöglichkeiten eröffnen. Auch hierzu später mehr.

Massenoperationen sind in traditionellen CMS häufig nur über Makrosprachen zugänglich.^[15] Ähnlich sieht es in den Wikis aus, wo man oft mit Perl-Skripten oder ähnlichen Werkzeugen hantieren muss. Das Open-Source-Modell der meisten Wikis und ihre einfache Datenstruktur erleichtern solche Vorgänge.

Bearbeitung und Verifikation sind bei Wikis naturgemäß relativ unkompliziert. Der Content von Wiki ist plain text, und als Editor wird das Formulareingabefeld des Webbrowsers verwendet. WYSIWYG-Editoren für Wiki (als Java-Applet oder JavaScript) werden immer wieder diskutiert und auch umgesetzt,^[16] haben aber nicht Fuß fassen können. Die Gründe dafür sind unklar. Möglicherweise bringen WYSIWYG-Editoren in diesem Bereich nicht so viel, wie man instinktiv annehmen könnte (vgl. Email-Clients, deren seit Jahren verfügbare WYSIWYG-Editoren wenig genutzt werden).

Links sind ein Mehrwert, sonst gäbe es das WWW nicht. Nirgendwo ist die Schaffung dieses Mehrwerts leichter als in einem Wiki. Wiki-Content besteht aus Seiten. Jede Seite hat einen Namen. Jede Verwendung des Namens stellt automatisch den Link zu der Seite her. Erfahrene Wiki Autoren formen aus Gewohnheit Interessante Begriffe zu WikiWörtern um, ohne zu wissen, ob sie damit eine existierende Seite erreichen werden. So entsteht ein weitaus dichteres Netz von Beziehnungen zwischen den einzelnen Seiten, als es möglich wäre, wenn das Erstellen von Links mit zusätzlichem Aufwand (und seien es nur ein paar Mausklicks) verbunden ist. Wenn der Mehraufwand für das Setzen eines Links gegen Null geht, entstehen interessante neue Verwendungen für Links, auf die später eingegangen wird.

Für die parallele Verwaltung des selben Inhalts in verschiedenen Sprachen sind Wikis sicherlich nicht geeignet. Wikis sind dynamische Gebilde. Die synchrone Verwaltung verschiedensprachiger Versionen des gleichen Inhalts ist ein aufwändiger Vorgang und passt dabei nicht ins Konzept. Die Grundvoraussetzung für den Einsatz in vielen Sprachen bringen Wikis jedoch mit, da der Unicode-Standard von allen gängigen Browsern unterstützt wird, und ein Wiki sich für Ein- und Ausgabe auf den Browser stützt.

Hier ist wieder ein deutlicher konzeptioneller Unterschied zwischen Wikis und CMS zu sehen. Wikis kennen das Konzept eines Content Lifecycle nicht. Die schnelle und unmittelbare Verfügbarkeit aller Änderungen ist ein wichtiges Merkmal der Wiki-Idee und lässt sich mit einem komplexen Workflow nicht vereinbaren. Für Umgebungen, in denen die Schaffung neuen Inhalts ein mehrstufiger Prozess ist, kommt ein Wiki daher nicht in Frage.

Die Trennung von Content und Layout ist in einem Wiki notwendiger Weise realisiert, da die Inhalte in einer nicht online publizierbaren Form geschaffen werden. Die Generierung von HTML bzw. XHTML für die Anzeige im Browser erfolgt mittels einfacher Templates. Da für die Formatierung nur ein Satz einfacher Regeln zur Verfügung steht, sind Autoren in ihren Möglichkeiten zur Gestaltung des Inhalts eingeschränkt. Dies ist jedoch in traditionellen CMS ähnlich, es sei denn, die Autoren sollen den Komplexitäten von HTML ausgesetzt werden.

Die wichtigste Im- und Exportschnittstelle eines Wikis ist wahrscheinlich die Copy & Paste-Funktion des Webbrowsers. Das Hauptproblem bei der Wandlung verschiedener Formate, nämlich die oftmals drastisch unterschiedliche Expressivität, reduziert sich bei der Konvertierung in oder aus einfachem Text erheblich. Dementsprechend lassen sich für fast alle Im- und Exportanforderungen eines Wikis relativ einfach Ad-Hoc-Lösungen finden. Heutige Wikis verzichten daher auf explizite Im- und Export-Schnittstellen zu bestimmten Formaten. Oftmals mitgeliefert sind Tools zum Import von Daten aus anderen Wiki-Servern.

Ein konzeptionelles Problem der Wikis ist, dass der Content einer bestimmten Wiki-Seite per Definition dynamisch ist. Daher kann man nicht davon ausgehen, dass die gleiche Information zu einem späteren Zeitpunkt noch unter der gleichen URL zu finden ist, was prinzipiell vermieden werden sollte.^[17] Damit wird es riskanter, auf Wiki-Seiten von außerhalb zu linken oder Zitate aus einem Wiki mit einer URL als Referenz zu belegen.

Durch das originale Wiki kann man stundenlang surfen, ohne eine einzige Grafik zu sehen. Die Einbindung multimedialer Assets ist in Wiki zwar geringfügig leichter als für den HTML-Autor mit Texteditor und FTP-Programm (Hilfen sind z.B. Fileupload-Features und spezielle Textformatierungsregeln für die Einbindung von Grafiken), aber gegenüber dem herrlich einfachen Umgang mit Text müssen Grafiken et al als wahrer Krampf erscheinen. Eine Randnotiz ist das TWikiDraw-Plugin wert, welches über ein Java-Applet die Erstellung einfacher Grafiken ermöglicht. Das Beispiel deutet darauf hin, dass die Textlastigkeit heutiger Wikis nicht prinzipbedingt ist. Die Unterstützung von reinem Text ist jedoch viel einfacher zu realisieren als andere Medienformate. Beim heutigen Entwicklungsstand der Wiki-Server sind sie jedoch damit für viele Anwendungen disqualifiziert, da Seiten aus reinem Text im heutigen Web eigentlich nicht zeitgemäß sind.

Dies ist kein Feature eines CMS, aber ein Feature von Wiki. Die Idee des kollaborativen Schreibens ist vermutlich nicht neu, aber konnte wohl noch nie so effektiv realisiert werden wie in einem Wiki. Potentiell kann dort jeder vorbeisurfende Besucher seine Beiträge hinterlassen und den Wert der Seite damit - hoffentlich - erhöhen.

Damit sind folgende konzeptionelle Unterschieden zwischen Wikis und CMS ausgemacht:

Auf diese Eigenheiten soll nun jeweils in einem eigenen Abschnitt näher eingegangen werden.