Wissen liegt verstreut in Dateien, Chats und Köpfen? WZ-IT richtet Unternehmenswikis ein, bindet sie an Ihre Identitäten an und übernimmt Managed Hosting und laufenden Betrieb. Vorhaben gemeinsam einordnen
Wer ein Unternehmenswiki auswählt, findet vier ernstzunehmende quelloffene Kandidaten und eine Menge Vergleiche, die überwiegend von Anbietern konkurrierender Produkte stammen.
Einer dieser Vergleiche verbreitet derzeit eine Aussage, die sich überprüfen lässt und so nicht stimmt: Wiki.js sei eingeschlafen, der letzte Commit Monate alt. Das Repository wurde am 24. August 2026 aktualisiert. Der wahre Sachverhalt ist ein anderer und für die Entscheidung wichtiger, als die falsche Version es wäre.
Dieser Beitrag ordnet die vier anhand von Lizenz, Struktur, Funktionsgrenzen und Betriebsaufwand ein. Alle Angaben aus den Repositories und Projektseiten, Stand 24. August 2026; Versionen, Lizenzstufen und Migrationswege aktualisiert am 12. Oktober 2026.
Inhaltsverzeichnis
- Die vier im Überblick
- Wiki.js: was tatsächlich der Fall ist
- Lizenzen und Funktionsgrenzen
- Struktur: der unterschätzte Unterschied
- BookStack
- Docmost
- XWiki
- Wiki.js
- Welches System wofür
- Was ein Funktionsvergleich nicht beantwortet
- Unser Vorgehen bei WZ-IT
- Weiterführende Guides
Die vier im Überblick
Angaben aus den öffentlichen Repositories, Stand 24. August 2026.
| System | GitHub-Sterne | Lizenz | Unterbau | Letzte Aktualisierung |
|---|---|---|---|---|
| Wiki.js | 28.789 | AGPL-3.0 | Node.js, PostgreSQL | 24.08.2026 |
| Docmost | 21.450 | AGPL-3.0 | Node.js, PostgreSQL | 24.08.2026 |
| BookStack | 19.002 | MIT | PHP, MySQL | 24.08.2026 |
| XWiki | 1.301 | LGPL-2.1 | Java, relationale Datenbank | 24.08.2026 |
Alle vier Repositories wurden am selben Tag aktualisiert. Keines der Projekte ist verwaist.
Die Sternezahl von XWiki ist irreführend. Das Projekt läuft seit 2007 und verteilt sich über viele Repositories; die Zahl eines einzelnen bildet die Verbreitung nicht ab.
Wiki.js: was tatsächlich der Fall ist
Weil dazu Falsches kursiert, hier der überprüfte Stand.
Das Repository ist aktiv. Letzte Aktualisierung am 24. August 2026, wie bei den anderen drei.
Die Veröffentlichungen der 2.x-Reihe haben sich gestreckt. Die aktuelle Version ist v2.5.315 vom 21. September 2026, davor v2.5.314 vom 1. Mai, v2.5.313 vom 27. April und v2.5.312 vom 12. Februar (Wiki.js Releases). Der Abstand zwischen den Veröffentlichungen ist deutlich größer geworden.
Version 3.0 läuft seit 2021. Angekündigt 2021, eine Developer Preview im Oktober 2022, danach lange im Alpha-Stadium. Inzwischen liegt eine Beta vor, aktuell 3.0.0-beta.651 vom 11. Oktober 2026. Auch die Beta ist laut Release-Hinweis ausdrücklich nicht für den Produktivbetrieb vorgesehen ("Not for production use"). Ein Confluence-Import ist in der Beta als Menüpunkt angelegt, aber noch als "coming soon" deaktiviert.
Was daraus folgt: Wiki.js ist keine tote Software und auch kein Fehlgriff. Aber wer heute damit startet, startet auf 2.x und nimmt einen Versionswechsel in Kauf, dessen Zeitpunkt und Aufwand niemand beziffern kann. Das ist ein realer Faktor in einer Entscheidung, die auf Jahre wirkt, und er ist etwas anderes als "das Projekt ist tot".
Lizenzen und Funktionsgrenzen
| System | Lizenz | Eingeschränkter Teil |
|---|---|---|
| BookStack | MIT | keiner |
| XWiki | LGPL-2.1 | Pro-Apps und Confluence Migration Toolkit kostenpflichtig, Kern uneingeschränkt |
| Wiki.js | AGPL-3.0 | keiner |
| Docmost | AGPL-3.0 | Business- und Enterprise-Stufe, u. a. SSO, Seitenrechte und Confluence-Import |
Docmost führt neben der quelloffenen Community Edition die kostenpflichtigen Stufen Business und Enterprise. Business kostet 6 US-Dollar je Nutzer und Monat bei jährlicher Zahlung, mindestens 10 Nutzer; SSO mit SAML, OIDC und LDAP, MFA, Seitenrechte und der Confluence-Import gibt es erst ab dieser Stufe (Docmost Pricing, Stand Oktober 2026). Welche Funktionen in welcher Stufe liegen und welche im freien Teil, haben wir in einem eigenen Beitrag aufgeschlüsselt. Für die Auswahl gilt derselbe Rat wie überall, wo eine solche Grenze verläuft: Erst prüfen, auf welcher Seite die gebrauchten Funktionen liegen, dann entscheiden.
Bei XWiki verläuft die Grenze bei Zusatzangeboten: Pro-Apps und das Confluence Migration Toolkit sind kostenpflichtig, das Toolkit ab 2.140 € je Jahr für 25 Nutzer (XWiki Store, Stand Oktober 2026). LDAP und OpenID Connect stehen dagegen als freie Erweiterungen unter LGPL-2.1 bereit. Bei BookStack und Wiki.js stellt sich diese Frage nicht. AGPL-3.0 bei Wiki.js verlangt bei Bereitstellung über ein Netzwerk die Offenlegung eigener Änderungen, was für den internen Betrieb ohne Weitergabe in aller Regel unproblematisch ist.
Struktur: der unterschätzte Unterschied
Der Punkt, der nach zwei Jahren über den Nutzen entscheidet, und der in Funktionsvergleichen kaum vorkommt.
BookStack erzwingt eine Gliederung: Regale enthalten Bücher, Bücher enthalten Kapitel, Kapitel enthalten Seiten. Mehr Ebenen gibt es nicht. Das nimmt Freiheit, und genau darin liegt der Nutzen: Ein Wiki ohne vorgegebene Struktur wird ohne konsequente Pflege zu einer Sammlung, in der niemand mehr findet, was er sucht.
Docmost, Wiki.js und XWiki arbeiten mit freien Seitenbäumen. Das ist flexibler und verlangt jemanden, der die Ordnung verantwortet.
Die Frage vor der Auswahl lautet deshalb nicht "welches kann mehr", sondern: Gibt es jemanden, der die Struktur pflegt? Wenn nein, ist eine vorgegebene Gliederung ein Vorteil, kein Mangel.
BookStack
BookStack steht unter MIT, hat 19.002 Sterne und basiert auf PHP und MySQL. Es ist das schlankeste der vier Systeme im Betrieb und mit einem Docker-Aufruf gestartet.
Stärke: die feste Gliederung, geringer Ressourcenbedarf, unkomplizierte Aktualisierung, keine Funktionsgrenze. Für Teams ohne festen Wiki-Verantwortlichen ist es die risikoärmste Wahl.
Grenze: kein gleichzeitiges Arbeiten am selben Dokument im Stil moderner Editoren, weniger Erweiterungsmöglichkeiten als XWiki. Wie es sich gegenüber Confluence schlägt, haben wir gesondert beschrieben.
Docmost
Docmost steht unter AGPL-3.0, hat 21.450 Sterne und basiert auf Node.js und PostgreSQL. Es ist das jüngste der vier Systeme, mit blockbasiertem Editor und gleichzeitigem Arbeiten mehrerer Personen an einer Seite.
Stärke: die modernste Bedienung der vier, am ehesten vergleichbar mit dem, was Teams aus kommerziellen Werkzeugen kennen.
Grenze: das jüngste Projekt mit dem kleinsten Ökosystem, und die Aufteilung in die freie Community Edition und die kostenpflichtigen Stufen Business und Enterprise gehört vor die Entscheidung geprüft.
XWiki
XWiki steht unter LGPL-2.1, ist in Java geschrieben und wird seit 2007 entwickelt. Es ist das mächtigste und zugleich aufwendigste der vier Systeme.
Stärke: strukturierte Daten innerhalb von Seiten, umfangreiche Erweiterbarkeit, erprobt in großen Installationen. Wo ein Wiki mehr sein soll als Text, etwa mit eigenen Datenstrukturen und Formularen, ist XWiki das einzige der vier, das dorthin reicht.
Grenze: Java-Betrieb mit entsprechendem Ressourcenbedarf, die steilste Einarbeitung, und für ein Team von zwanzig Personen deutlich überdimensioniert.
Wiki.js
Wiki.js steht unter AGPL-3.0, hat 28.789 Sterne und ist damit das beachtetste der vier Systeme. Es basiert auf Node.js und PostgreSQL und bietet eine ansprechende Oberfläche sowie breite Anbindungsmöglichkeiten für Identitäten und Speicherorte.
Stärke: gute Bedienung, viele Anbindungen, aktive Gemeinschaft.
Grenze: der oben beschriebene Stand der 3.0-Entwicklung. Wer eine Entscheidung für die nächsten fünf Jahre trifft, sollte diesen Punkt bewusst abwägen statt ihn zu übergehen.
Welches System wofür
| Ausgangslage | Naheliegende Wahl | Begründung |
|---|---|---|
| Kein fester Wiki-Verantwortlicher, Ordnung soll halten | BookStack | vorgegebene Gliederung, geringster Betriebsaufwand |
| Team kommt von Notion oder Confluence, will gleichzeitig arbeiten | Docmost | blockbasierter Editor, Funktionsgrenze vorher prüfen |
| Große Installation, strukturierte Daten, Erweiterungen | XWiki | einziges mit dieser Tiefe, seit 2007 erprobt |
| Viele Anbindungen gewünscht, Versionslage bewusst akzeptiert | Wiki.js | starke Integrationen, 3.0-Frage einkalkulieren |
| Öffentliche Dokumentation neben internem Bereich | BookStack oder Wiki.js | beide mit getrennten Berechtigungsbereichen |
Was ein Funktionsvergleich nicht beantwortet
Wer pflegt die Inhalte? Ein Wiki ohne benannte Verantwortung veraltet innerhalb eines Jahres und wird dann umgangen. Das ist unabhängig vom System und der häufigste Grund, warum Wiki-Einführungen scheitern.
Wie kommen die Inhalte hinein? Migration aus einem bestehenden Wiki überträgt Texte meist zuverlässig und Anhänge, Berechtigungen, Querverweise und Versionsstände selten. Der Aufwand liegt fast nie im Text. Eine Ausnahme ist der Weg aus Confluence nach XWiki: Das kostenpflichtige Confluence Migration Toolkit übernimmt auch Rechte, Seitenhistorie und Anhänge. Welcher Weg für welches System gilt und welche Fristen für Confluence Data Center laufen, beschreibt der Leitfaden Confluence Data Center End of Life: Migration zu Open-Source-Wikis.
Wer aktualisiert es? Ein Wiki enthält oft mehr Betriebswissen als jede andere interne Anwendung, einschließlich Dingen, die dort nicht stehen sollten. Eine ungepatchte Instanz mit Zugriff aus dem Internet ist entsprechend heikel.
Was passiert bei Verlust? Sicherung mit geprüfter Wiederherstellung ist bei Wikis besonders leicht zu vergessen, weil sie selten spürbar ausfallen. Bemerkt wird es erst, wenn jemand etwas nachschlagen will.
Noch unklar, welches Werkzeug passt? In der Wiki-Auswahl probieren Sie alle Kandidaten als Demo-Instanzen aus und erhalten eine Entscheidungsvorlage mit Lizenzkosten und Migrationspfad. Ab 3.900 € netto, angerechnet auf die Einführung.
Unser Vorgehen bei WZ-IT
Wir richten alle vier ein und entscheiden nicht nach Funktionsumfang, sondern nach zwei Fragen: Wer pflegt die Struktur, und woher kommen die Inhalte.
Gibt es keinen festen Verantwortlichen, empfehlen wir BookStack, weil die erzwungene Gliederung einen Teil dieser Aufgabe übernimmt. Kommt ein Team von einem modernen Editor und erwartet gleichzeitiges Arbeiten, ist Docmost näher an der Erwartung. XWiki empfehlen wir dort, wo ein Wiki tatsächlich strukturierte Daten tragen soll, und nicht als Standardantwort.
Bei Wiki.js benennen wir die Versionslage vor der Entscheidung. Das ist kein Ausschluss, aber es gehört auf den Tisch, bevor Inhalte hineinwandern.
Was wir unabhängig vom System einrichten, ist die Anbindung an die vorhandenen Identitäten. Ein Wiki mit eigener Benutzerverwaltung neben allem anderen wird bei Ein- und Austritten vergessen.
Weiterführende Guides
- Confluence Data Center End of Life - Fristen bis 2029 und Migrationswege je System
- BookStack als Confluence-Alternative - der Vergleich zum kommerziellen Platzhirsch
- Docmost Community gegen Enterprise Edition - wo die Funktionsgrenze verläuft
- BookStack, Docmost, Wiki.js und XWiki - die Systeme im Einzelnen
- Managed Open Source - Einrichtung, Anbindung und Betrieb
Unklar, welches System zu Ihrer Arbeitsweise passt? Wir sichten Team, Inhalte und vorhandene Identitäten und richten das passende System samt Anbindung ein. Termin vereinbaren
