Docmost - Open-Source-Software für kollaborative Dokumentation und Wikis, ähnlich wie Confluence & Notion

 (github.com/docmost)
4 Punkte von GN⁺ 2024-06-30 | 3 Kommentare | Auf WhatsApp teilen
  • Docmost ist ein Projekt für Open-Source-Kollaborations-Wikis und Dokumentationssoftware, das Teams beim gemeinsamen Erstellen und Verwalten von Dokumenten unterstützt
  • Zu den Hauptfunktionen gehören Echtzeit-Zusammenarbeit, Spaces, Rechteverwaltung, Gruppen, Kommentare, Seitenhistorie, Suche und Dateianhänge
  • Die Dokumentation umfasst Diagramme auf Basis von Draw.io, Excalidraw und Mermaid, Einbettungen wie Airtable, Loom und Miro sowie Übersetzungen in mehr als 10 Sprachen
  • Für den Einstieg kann die offizielle Dokumentation genutzt oder die Cloud-Version ausprobiert werden
  • Der Docmost-Kern steht unter der Lizenz AGPL 3.0, während Enterprise-Funktionen und Dateien in bestimmten Verzeichnissen unter die Docmost-Enterprise-Lizenz fallen

Überblick über Docmost

Kollaboration und Dokumentationsfunktionen

  • Unterstützt Real-time collaboration
  • Bietet die Funktion Spaces zur Trennung von Dokumentbereichen
  • Stellt Rechteverwaltung und Gruppenfunktionen bereit
  • Unterstützt Kommentare und Seitenhistorie
  • Enthält Suche und Dateianhänge

Diagramme, Einbettungen und Übersetzungen

  • Die Funktion Diagrams unterstützt Draw.io, Excalidraw und Mermaid
  • Embeds umfassen unter anderem Airtable, Loom und Miro
  • Übersetzungen werden in mehr als 10 Sprachen unterstützt

Lizenzstruktur

  • Der Docmost core wird unter der Open-Source-Lizenz AGPL 3.0 bereitgestellt
  • Enterprise-Funktionen werden unter der Enterprise-Lizenz der Enterprise Edition bereitgestellt
  • Alle Dateien in den folgenden Verzeichnissen unterliegen der Docmost Enterprise license, wie in packages/ee/License definiert
    • apps/server/src/ee
    • apps/client/src/ee
    • packages/ee

Entwicklung und Danksagungen

  • Mitwirkende können die development documentation konsultieren
  • Crowdin bietet Zugang zur Lokalisierungsplattform
  • Algolia bietet Volltextsuche für die Dokumentation

Verwandte Beiträge

3 Kommentare

 
nutella 2025-01-10

Bei uns im Unternehmen sind sowohl Notion als auch Obsidian gesperrt … ich will das mal ausprobieren, und es scheint eine gute Alternative zu sein.
 
moderato 2024-10-10

Ich habe es ausprobiert, und es ist ein gut gemachtes Tool, das Notion ähnelt.
Da es Notion jedoch zu ähnlich ist, gibt es an Stellen, an denen es sich von Notion unterscheidet, auch Unannehmlichkeiten.
Ich hoffe, dass es sich gut weiterentwickelt.
 
GN⁺ 2024-06-30
Meinungen auf Hacker News

  • Die Barrierefreiheit von Notion und Confluence ist bei beiden wirklich katastrophal.
    Ich frage mich, ob ihr das bei der Entwicklung von Docmost berücksichtigt habt. Mit Blick auf den ADA in den USA und den bald in Kraft tretenden EAA der EU ist das ein ziemlich wichtiger Faktor für den Unternehmenseinsatz, und es wäre schön, wenn es diesmal ein Produkt gäbe, das seine Hausaufgaben bei der Barrierefreiheit richtig gemacht hat. Wenn ihr möchtet, kann ich es mir einmal ansehen. Zur Einordnung: Ich bin nativer Screenreader-Nutzer, blind, Entwickler und Accessibility-Auditor.

    • Wenn das schon für Menschen mit durchschnittlichen Händen und Augen gilt, kann man sich vorstellen, wie es für Menschen mit Behinderungen ist.
    • Barrierefreiheit haben wir bedacht.
      Zum Beispiel unterstützt der Seitenbaum in der Sidebar Tastaturnavigation. Die verwendete UI-Bibliothek Mantine folgt ebenfalls Best Practices für Barrierefreiheit und bietet vollständige Tastaturunterstützung. Es gibt noch viel zu tun, aber mit dem Fortschritt des Projekts wird die Unterstützung weiter ausgebaut. Früher habe ich den Twitter-Bot @threadvoice gebaut, mit dem man Twitter-Threads als Audio anhören konnte, und auch damals war Barrierefreiheit eine der Motivationen.
      https://twitter.com/Philipofficial9/status/11899711858004869...
    • Auch die Authentifizierung ist ein Problem. Bei diesen beiden Websites habe ich manchmal das Gefühl, ich würde lieber alles verlieren, als noch einmal durch den Login-Prozess zu müssen.
    • Wenn Unternehmen bereits Confluence und Notion nutzen, die bei Barrierefreiheit so schlecht sind, frage ich mich, wie wichtig das für Unternehmen in der Praxis wirklich ist.
    • Wichtig ist es schon, aber ich würde es wahrscheinlich nicht ganz oben auf die Liste der Dinge setzen, die man direkt zum Projektstart lösen muss.

  • Als kleines Feedback: Ich wollte das Produkt ausprobieren, und die Website wirkte sauber und vielversprechend, aber die Installationsseite hat mich abgeschreckt, sodass ich fast abgesprungen wäre.
    Die ersten Anweisungen betrafen die Docker-Installation. Ich weiß, der Abschnitt heißt „Prerequisites“, aber wenn Docker die einzige Installationsmethode ist, hätte ich eher etwas zu docker-compose und zur Dokumentation der Variablen erwartet. Auch „Installation Steps“ beginnt mit mkdir, cd, curl, vi und läuft am Ende auf „verwende dieses docker-compose“ hinaus. Voraussetzungen können für viele Leute wichtig sein, und wenn man das als Problem sieht, gibt es verschiedene Möglichkeiten, es zu lösen. Entwickler und technisch versierte Leute überspringen alles und schauen zuerst auf Terminalbefehle oder Code. Deshalb sollte man „nicht tun“ nicht zu weit oben in ein Repository-README setzen, denn genau das ist dann der Teil, den wir als Erstes kopieren und einfügen. Das ist keine Kritik, es sieht großartig gemacht aus, aber es ist das Feedback eines durchschnittlichen Experimentierers, den ihr auf dieser Seite verlieren könntet.
    https://docmost.com/docs/installation

    • Ich würde die Docker-Installationsanleitung entfernen. Die Leute können sie in der Docker-Dokumentation nachlesen, und es gibt wenig Grund, sie anderswo zu duplizieren.
      Außerdem wäre es für die Verwaltung von Umgebungsvariablen besser, eine .env-Datei zu verwenden, statt die docker-compose-Datei bearbeiten zu lassen. Viele Leute werden die yaml-Datei wahrscheinlich in die Versionsverwaltung aufnehmen, daher ist es keine gute Idee, dort Geheimnisse im Klartext abzulegen.
      https://docs.docker.com/compose/environment-variables/set-en...
    • Wenn ihr die Adoption erhöhen wollt, solltet ihr meiner Meinung nach einen All-in-one-Container anbieten.
      Man kann runit verwenden, Datenbank, Redis und App in denselben Container packen und ein großes Datenverzeichnis bereitstellen. Für die meisten kleinen Teams, die Container ausführen können, reicht das aus, und die „mal ausprobieren“-Erfahrung wird einfach zu docker run.

  • Wir nutzen immer noch Confluence On-Premises hinter einem VPN. Für einen Umzug bräuchten wir PDF-Export, einen integrierten Diagrammeditor wie Gliffy sowie Historie und Diffs.
    Bisher kam Outline dem am nächsten, aber es eilt nicht, daher werde ich auch die Entwicklung dieses Projekts beobachten.

    • XWiki SAS entwickelt ein Tool für die Migration von Confluence zu XWiki.
      XWiki ist eine Open-Source-Wiki-Software, die ungefähr zur gleichen Zeit wie Confluence gestartet ist und alle genannten Funktionen bietet. Wir bieten auch Migrationsunterstützung und Consulting an; das Migrationstool versucht, möglichst viele Inhalte und Funktionen zu erhalten, und wir arbeiten auch an kompatiblen Makros. Bei Bedarf könnt ihr euch melden.
      https://xwiki.com
      http://xwiki.org
    • Aus der Confluence-Perspektive ist der größte leicht zu übersehende Bedarf meiner Meinung nach die Integration von Wiki und Code-Dokumentation.
      Es ist wichtig, die aus der Codebasis generierte Dokumentation wie READMEs im Code, sphinx, mkdocs und swagger mit dem Wiki zusammenzubringen. Beim integrierten Diagrammeditor kann man durch Standardisierung auf Dokument-als-Code-Abstraktionen wie Mermaid oder Kroki Diagrammcode nutzen, der sich per Diff vergleichen lässt, sowie verschiedene Open-Source-Editoren. Auch für VSCode-Erweiterungen gibt es einige Implementierungen, und wenn man Mermaid wählt, funktionieren dieselben Diagramme gemeinsam in Wiki-Tools, GitHub und local-first Tools für offene Inhaltsformate wie Foam, Dendron oder Obsidian.md, was ein Vorteil ist.
    • Ich nutze Bookstack für diesen Zweck und kann es empfehlen. Es ist kostenlos und Open Source.
      Es unterstützt PDF-Export, OAuth2, Revisionen, Historie, Berechtigungen, WYSIWYG/Markdown/Diagramme usw.
      https://www.bookstackapp.com/
    • PDF-Export ist geplant.
      Diagramme sind ebenfalls geplant, als Nächstes kommt MermaidJs. Andere Diagrammanbieter wie Draw.io und Excalidraw können hinzugefügt werden, nachdem geklärt ist, wie sich die Quelldaten effizient speichern und importieren lassen. Seitenhistorie wird unterstützt, aber Diff-Vergleiche gibt es noch nicht.
    • In Confluence habe ich es nicht genutzt, aber https://www.tldraw.com/ lässt sich zumindest in Notion einbetten und funktioniert als Diagrammeditor sehr gut.

  • Wir evaluieren im Unternehmen gerade Dokumentationstools; wegen unseres speziellen regulatorischen Umfelds sind die Personen, die ein Dokument erstellen, nicht dieselben wie die, die es prüfen und freigeben.
    Deshalb könnte das Konzept von Merge Requests für Dokumente ein Differenzierungsmerkmal sein. Jemand erstellt ein Dokument, eine andere Person ändert es und reicht die Änderungen dann als Review-Anfrage ein. GitBook hat das, aber andere zentrale Bereiche fehlen uns dort.

    • Ich wollte das schon lange, aber nach längerem Nachdenken bevorzuge ich inzwischen einfach Git zu verwenden und Markdown-Dokumente in ein Notes System zu pushen.
      Ich möchte nicht, dass ein anderes System Bearbeitung, Review und Merge übernimmt. Ich will Dokumente aus Git ausliefern und nur kontinuierlich in ein System deployen, das die nötigen dokumentbezogenen Funktionen ordentlich hostet.
    • Das wäre vermutlich ein großartiges Feature. Wir haben ein ähnliches Problem: Es gibt eine offizielle, geprüfte Dokumentversion, und wenn man in Confluence an der nächsten Version arbeiten will, muss man eine separate Arbeitsseite anlegen.
      Dadurch werden die Suchergebnisse verunreinigt und es wird schnell unübersichtlich.
    • Wenn Merge Requests für Dokumente eine Kernanforderung sind, würde mich interessieren, welche anderen Funktionen nötig sind, für die Git oder ein anderes Versionskontrollsystem nicht ausreichen.
    • Das wäre wirklich ein sehr gutes Feature.

  • Ich mag Wikis und bestimmte Arten, wie Wikis innerhalb von Unternehmen genutzt werden, sehr.
    Allerdings mag ich manche Wiki-Softwareprodukte deutlich weniger, die sich offenbar vom Enterprise-Vertrieb an Kunden treiben lassen, die Wikis nicht verstehen. Was ein bestimmtes Enterprise-Produkt ziemlich gut gemacht hat, war die Integration von Zeichentools. Nicht alle im Unternehmen brauchen diese Integration, aber einige Nutzer schon; und dadurch können sehr nützliche visuelle Materialien dokumentiert werden, die sonst nicht erhalten geblieben wären.

    • https://www.tldraw.com/ lässt sich zumindest live in Notion einbetten und bietet dadurch auch in einem Wiki, das so etwas ursprünglich nicht unterstützt, recht gute Funktionen für gemeinsames Zeichnen. In Confluence oder anderen Tools habe ich es noch nicht ausprobiert.
    • Mich würde interessieren, ob du ein paar zentrale Erkenntnisse dazu zusammenfassen kannst, warum du Wikis magst. Besonders würde mich interessieren, welche Nutzungsweisen innerhalb eines Unternehmens am effektivsten sind.

  • Die größten Probleme bei den meisten Dokumentationssoftwares sind zwei Dinge.
    Erstens ist alles eingeschlossen. Man sollte Notizen einfach exportieren oder sichern können. Zweitens fühlt sich die Preisgestaltung zu sehr nach kleinteiligem Abkassieren an. Wenn der Dokumentenbaum mehr als 100 Knoten hat, soll man auf einen höheren Tarif wechseln, oder jedes Mal, wenn man eine Person zu einem Projekt hinzufügt, wird daraus eine Kaufentscheidung – das ist ermüdend. Es wäre gut, wenn du genauer erklären könntest, wie ihr Postgres und Redis verwendet.

    • Postgres ist die primäre Datenbank für alle Workspace- und nutzerbezogenen Daten.
      Redis verwenden wir für Queues, für die Synchronisierung des Status des kollaborativen Editors zwischen Servern und für die WebSocket-Synchronisierung zwischen Servern. Die letzten beiden Funktionen sind wichtig, wenn die Software auf mehreren Nodes oder Replikaten läuft.

  • Ich arbeite bei XWiki. Es freut mich, Kolleginnen und Kollegen zu sehen, die Open-Source-Alternativen bauen; je mehr solcher Versuche es gibt, desto besser.
    Etwas zu entwickeln, das mit Confluence konkurrieren kann, erfordert wirklich viel Arbeit, und XWiki ist seit seinen Anfangstagen in diesem Bereich aktiv. Mich interessiert, wie ihr Docmost im Vergleich zu XWiki positioniert und warum ihr euch entschieden habt, nicht die Kräfte zu bündeln.
    https://xwiki.org

    • Ich habe XWiki ausprobiert, weil ich von Confluence zu etwas Open Source wechseln wollte, aber die User Experience wirkte im Vergleich recht unausgereift.
      Gibt es ein empfohlenes Bündel an Erweiterungen, das XWiki für Leute, die eine Confluence-ähnliche Erfahrung wollen, akzeptabler macht?

  • Ich fände solche Funktionen gut:
    Man sollte Seiten mit dem Editor seiner Wahl als Plain Text in Git oder einem anderen Versionskontrollsystem verwalten und sie committen können, ohne durch den Browser zu gehen. Die Seiten könnten in irgendeiner Markup-Sprache geschrieben sein; da Markdown in manchen Bereichen nicht ausdrucksstark genug ist, sollten einfache Seiten per Dateiendung als Markdown erkennbar sein, während das Wiki auch ein leistungsfähigeres, von Nutzern erweiterbares Format wie reStructuredText zulässt. Außerdem sollten Seiten serverseitig gerendert und leicht cachebar sein. Wenn Seiten Dateien sind, lässt sich die Cache-Gültigkeit einfach über sha-Summen prüfen, sodass sie im Gegensatz zum langsamen und schlechten Confluence nahezu sofort angezeigt werden können.

    • Es ist nicht ganz derselbe Anwendungsfall, aber für die Erstellung der statischen Dokumentationssite eines Projekts nutze ich https://nextra.site/ mit sehr guten Ergebnissen.
      Es trifft eine gute Balance: Meist kann man einfach normales Markdown verwenden, aber bei Bedarf auf React-Komponenten heruntergehen. Wenn ein Merge nach main per Continuous Deployment auf GitHub Pages geht, ist das eine ziemlich gute Erfahrung.
    • Wenn man Markdown-Dokumente außerhalb des Browsers schreibt und mit Git versioniert, weiß ich nicht, wozu man so ein Tool braucht. Das untergräbt doch den Zweck, oder?
      Oder geht es darum, Dokumente über einen entwicklerfreundlichen Workflow bereitzustellen, damit die übrigen nicht-technischen Teammitglieder sie nur ansehen? Im Allgemeinen halte ich das für eine wirklich schlechte Idee. Wenn man dem Team ein selbst gehostetes, vermutlich fehlerhaftes MVP vorsetzt und selbst die UI-Schicht, die alle anderen nutzen, gar nicht bedient, ist das eine Mischung, die zu Widerstand und Toolwechsel führt. Ich habe technische Gründer diesen Fehler sehr oft machen sehen. Dasselbe passiert bei CMS für Marketing-Websites: Man merkt, dass statische Site + Markdown + Git für Nichtentwickler nicht skaliert, und stellt dann fest, dass ein Headless CMS, das man selbst nicht nutzt, im Alltag schlecht funktioniert.
    • Bei uns im Unternehmen verwenden wir dafür Jekyll, bauen die Site mit GitHub Actions und hosten sie anschließend über GitHub Pages.
      Das funktioniert sehr gut und unterstützt auch Mermaid-Diagramme, MathML usw.
    • Mich würde interessieren, ob du MyST schon gesehen hast. Es ist so ausdrucksstark wie ReST und meiner Meinung nach viel einfacher zu verwenden.
    • Noch eine Stimme gegen Markdown.
      Markdown ist für einfache Dokumente in Ordnung, aber für Wikis, bei denen Links zwischen Seiten zentral sind, ist es sehr schwach. Persönlich finde ich Creole-Markup für das Schreiben von Wikis deutlich besser. Man sollte das Dateiformat nicht in der Dateiendung speichern, sondern Metadaten sauber als Metadaten ablegen. Die Anwendung wird sehr wahrscheinlich ohnehin viel mehr Metadaten haben wollen, sodass am Ende ein System zur Speicherung von Metadaten nötig wird. Ich sehe mich als einsamen Kreuzritter dafür, Metadaten aus Dateinamen herauszuhalten.

  • Confluence war unter der Enterprise-Software, die ich bisher benutzt habe, vielleicht abgesehen vom riesigen Jira, die langsamste.
    Bei PayPal wurde „auf Confluence warten“ zu einer Redewendung wie „mein Monorepo lädt gerade alle Abhängigkeiten herunter“. Man konnte eine längere Pause machen, über die Straße einen Kaffee holen und zurückkommen, während man darauf wartete, dass ein Dokument von der anderen Seite der Stadt geladen wurde. Ich habe nicht einmal versucht, dieses Dokument zu aktualisieren – alles Bessere ist also besser. Das ist kaum übertrieben.

  • Ein sehr cooles Projekt. Ich frage mich, ob es eine Möglichkeit gibt, es zu unterstützen.
    Ich habe auch gesehen, dass die Dokumentation Docusaurus verwendet; es wäre schön, hier Docmost selbst zu verwenden. Dann wäre es, selbst wenn nur lesend, eine Demo-Umgebung und zugleich eine Form der Entwicklung durch eigene Nutzung.