Docmost - logiciel open source de documentation collaborative et de wiki, similaire à Confluence & Notion

 (github.com/docmost)
4 points par GN⁺ 2024-06-30 | 3 commentaires | Partager sur WhatsApp
  • Docmost est un projet de wiki collaboratif open source et de logiciel de documentation conçu pour permettre aux équipes de rédiger et gérer des documents ensemble
  • Ses principales fonctionnalités incluent la collaboration en temps réel, les Spaces, la gestion des permissions, les groupes, les commentaires, l’historique des pages, la recherche et les pièces jointes
  • La documentation comprend des diagrammes basés sur Draw.io, Excalidraw et Mermaid, des intégrations embarquées comme Airtable, Loom et Miro, ainsi qu’une fonction de traduction dans plus de 10 langues
  • Pour commencer, vous pouvez consulter la documentation officielle ou essayer la version cloud
  • Le cœur de Docmost est sous licence AGPL 3.0, tandis que les fonctionnalités Enterprise et les fichiers de répertoires spécifiques relèvent de la licence Docmost Enterprise

Présentation de Docmost

Collaboration et fonctionnalités documentaires

  • Prise en charge de la collaboration en temps réel
  • Fonction Spaces pour séparer les espaces documentaires
  • Gestion des permissions et des groupes
  • Prise en charge des commentaires et de l’historique des pages
  • Fonctionnalités de recherche et de pièces jointes incluses

Diagrammes, intégrations embarquées et traduction

  • La fonctionnalité Diagrams prend en charge Draw.io, Excalidraw et Mermaid
  • Les Embeds incluent Airtable, Loom, Miro, etc.
  • La traduction prend en charge plus de 10 langues

Structure de licence

  • Le cœur de Docmost est proposé sous licence open source AGPL 3.0
  • Les fonctionnalités Enterprise sont fournies sous la licence Enterprise Edition
  • Tous les fichiers des répertoires suivants relèvent de la licence Docmost Enterprise définie dans packages/ee/License
    • apps/server/src/ee
    • apps/client/src/ee
    • packages/ee

Développement et mentions de remerciement

  • Les contributeurs peuvent consulter la documentation de développement
  • Crowdin fournit l’accès à la plateforme de localisation
  • Algolia fournit la recherche full-text pour la documentation

À lire aussi

3 commentaires

 
nutella 2025-01-10

Au bureau, Notion n’est pas autorisé et Obsidian est également bloqué... J’essaie de l’utiliser, et ça me semble être une bonne alternative.
 
moderato 2024-10-10

Après l’avoir essayé, c’est un outil bien conçu qui ressemble à Notion.
Mais justement parce qu’il ressemble beaucoup à Notion, il peut aussi créer des gênes sur des points où il diffère de Notion.
J’espère qu’il continuera à bien évoluer.
 
GN⁺ 2024-06-30
Avis sur Hacker News

  • L’accessibilité de Notion comme de Confluence est vraiment catastrophique
    Je me demande si cet aspect a été pris en compte lors de la création de Docmost. Avec l’ADA aux États-Unis et l’EAA qui entrera bientôt en vigueur dans l’UE, c’est un facteur assez important pour l’adoption en entreprise, et j’aimerais bien qu’un produit ait enfin fait correctement ses devoirs sur l’accessibilité. Je peux y jeter un œil si besoin. Pour contexte, je suis utilisateur natif de lecteur d’écran, aveugle, développeur et auditeur en accessibilité

    • Si c’est déjà le cas pour des personnes ayant des mains et des yeux ordinaires, on peut imaginer ce que cela donne pour des personnes en situation de handicap
    • Nous avons réfléchi à l’accessibilité
      Par exemple, l’arborescence des pages dans la barre latérale prend en charge la navigation au clavier. La bibliothèque UI que nous utilisons, Mantine, suit aussi les bonnes pratiques d’accessibilité et fournit une prise en charge complète du clavier. Il reste encore beaucoup à faire, mais le support s’étoffera au fil de l’avancement du projet. J’avais auparavant créé @threadvoice, un bot Twitter permettant d’écouter des fils Twitter en audio, et l’accessibilité faisait déjà partie de mes motivations à l’époque
      https://twitter.com/Philipofficial9/status/11899711858004869...
    • L’authentification est aussi un problème. Sur ces deux sites, je préfère presque tout perdre plutôt que de devoir repasser par la procédure de connexion
    • Si les entreprises utilisent déjà Confluence et Notion alors qu’ils sont si mauvais en accessibilité, je me demande à quel point c’est réellement important pour elles
    • C’est important, mais je ne pense pas que ce soit l’un des tout premiers points à traiter quand on vient de lancer un projet

  • Petit retour : j’avais envie d’essayer le produit, et le site était propre et prometteur, mais la page d’installation m’a fait peur au point que j’ai failli partir
    Les premières instructions concernaient l’installation de Docker. Je sais que la section s’appelle « Prerequisites », mais si Docker est le seul mode d’installation, je m’attendais plutôt à voir de la documentation sur docker-compose et les variables. La section « Installation Steps » commence aussi par mkdir, cd, curl, vi, pour finir par dire « utilisez ce docker-compose ». Les prérequis peuvent être importants pour beaucoup de gens, et si vous considérez que c’est un problème, il y a plusieurs façons de le résoudre. Les développeurs et les personnes à l’aise avec la technique sautent tout le reste pour aller directement aux commandes de terminal ou au code. Il ne faut donc pas mettre trop haut, en haut du README du dépôt, des choses à « ne pas faire », parce que c’est ce que nous allons copier-coller en premier. Ce n’est pas une critique, le travail a l’air excellent, mais c’est le retour d’un expérimentateur lambda que vous pourriez perdre sur cette page
    https://docmost.com/docs/installation

    • Il vaudrait mieux retirer les instructions d’installation de Docker. Les gens peuvent les trouver dans la documentation Docker, et il y a peu de raisons de les dupliquer ailleurs
      Par ailleurs, pour gérer les variables d’environnement, il vaudrait mieux utiliser un fichier .env plutôt que demander de modifier le fichier docker compose. Beaucoup de gens risquent de versionner le fichier yaml, donc y mettre des secrets en clair n’est pas une bonne idée
      https://docs.docker.com/compose/environment-variables/set-en...
    • Si vous voulez augmenter l’adoption, je pense qu’il faut fournir un conteneur tout-en-un
      Utilisez runit, mettez la base de données, redis et l’app dans le même conteneur, puis ajoutez un gros répertoire de données. Pour la plupart des petites équipes capables d’exécuter un conteneur, ce sera suffisant, et l’expérience « essayer rapidement » devient simplement docker run

  • Nous utilisons encore Confluence on-premise derrière un VPN. Pour migrer, il nous faudrait l’export PDF, un éditeur de diagrammes intégré comme Gliffy, l’historique et les diffs
    Jusqu’ici, Outline était ce qui s’en rapprochait le plus, mais nous ne sommes pas pressés, donc je vais aussi suivre l’évolution de ce projet

    • Chez XWiki SAS, nous développons un outil de migration de Confluence vers XWiki
      XWiki est un logiciel de wiki open source lancé à peu près à la même époque que Confluence, et il possède toutes les fonctionnalités mentionnées. Nous proposons aussi de l’aide à la migration et du conseil ; l’outil de migration essaie de préserver autant que possible le contenu et les fonctionnalités, et nous travaillons aussi sur des macros de compatibilité. N’hésitez pas à nous contacter si besoin
      https://xwiki.com
      http://xwiki.org
    • En venant de Confluence, le plus gros besoin facile à sous-estimer est, selon moi, l’intégration du wiki avec la documentation du code
      Il est important de regrouper le wiki avec la documentation générée depuis la base de code, comme les README du code, sphinx, mkdocs ou swagger. Pour les éditeurs de diagrammes intégrés, standardiser sur des abstractions documentation-as-code comme Mermaid ou Kroki permet d’utiliser du code de diagrammes diffable et plusieurs éditeurs open source. Il existe aussi plusieurs implémentations dans des extensions VSCode, et si vous choisissez Mermaid, les mêmes diagrammes fonctionneront à la fois dans l’outil de wiki, GitHub, et des outils de formats de contenu local-first ouverts comme Foam, Dendron ou Obsidian.md, ce qui est appréciable
    • Nous utilisons Bookstack pour cet usage, et je peux le recommander. C’est gratuit et open source
      Il prend en charge l’export PDF, OAuth2, les révisions, l’historique, les permissions, le WYSIWYG/Markdown/diagrammes, etc.
      https://www.bookstackapp.com/
    • L’export PDF est prévu
      Les diagrammes sont aussi prévus, et la prochaine étape sera MermaidJs. D’autres fournisseurs de diagrammes comme Draw.io et Excalidraw pourront être ajoutés après avoir défini une manière efficace de stocker et récupérer les données sources. L’historique des pages est pris en charge, mais il n’y a pas encore de comparaison des différences
    • Je ne l’ai pas utilisé dans Confluence, mais https://www.tldraw.com/ peut au moins être intégré dans Notion, et fonctionne très bien comme éditeur de diagrammes

  • Dans mon entreprise, nous évaluons des outils de documentation, et notre environnement réglementaire est particulier : la personne qui crée un document n’est pas celle qui le relit et l’approuve.
    À cause de cela, le concept de merge request pour documents pourrait être une fonctionnalité différenciante. Quelqu’un crée un document, une autre personne le modifie, puis soumet les changements sous forme de demande de relecture. GitBook le propose, mais il lui manque d’autres aspects essentiels pour nous.

    • Je voulais ça depuis longtemps, mais à bien y réfléchir, je préfère finalement utiliser simplement Git et pousser des documents Markdown vers un système de notes.
      Je ne veux pas qu’un autre système gère l’édition, la review et le merge. Je veux envoyer les documents depuis Git et faire du déploiement continu vers un système qui héberge correctement les fonctionnalités documentaires dont on a besoin.
    • Ça ferait une excellente fonctionnalité. Nous avons un problème similaire : il existe une version officielle de la documentation passée par un processus de validation, et pour travailler sur la version suivante dans Confluence, il faut créer une page de travail séparée.
      Résultat, les résultats de recherche sont pollués et cela devient vite désordonné.
    • Si les merge requests de documents sont un besoin clé, je me demande quelles autres fonctionnalités Git, ou un autre système de gestion de versions, ne suffit pas à couvrir.
    • Ce serait vraiment une fonctionnalité très appréciable.

  • J’aime beaucoup les wikis et certaines façons précises de les utiliser en entreprise.
    En revanche, j’aime moins certains logiciels de wiki qui semblent tirés vers la vente aux entreprises face à des clients qui ne comprennent pas les wikis. Un point qu’un produit d’entreprise faisait plutôt bien était l’intégration d’un outil de dessin. Tout le monde dans l’entreprise n’en a pas besoin, mais certains utilisateurs oui, et cela permet de consigner des supports visuels très utiles qui, autrement, n’auraient pas été conservés.

    • https://www.tldraw.com/ peut au moins être intégré en live dans Notion, ce qui fournit une fonction de dessin collaboratif assez bonne même dans un wiki qui ne prend pas nativement en charge ce type de fonctionnalité. Je ne l’ai pas encore essayé dans Confluence ni dans d’autres outils.
    • Je serais curieux que tu résumes quelques principes essentiels expliquant pourquoi tu aimes les wikis. J’aimerais surtout savoir quels usages fonctionnent le mieux en entreprise.

  • Les deux plus gros problèmes de la plupart des logiciels de documentation sont les suivants.
    Premièrement, tout est enfermé. Il faut pouvoir exporter ou sauvegarder facilement ses notes. Deuxièmement, la tarification donne trop l’impression de gratter de l’argent sur des détails : passer à l’offre supérieure dès que l’arborescence documentaire dépasse 100 nœuds, ou devoir refaire un choix d’achat à chaque ajout de personne à un projet. Ce serait bien si tu pouvais expliquer davantage comment Postgres et Redis sont utilisés.

    • Postgres est la base de données principale qui stocke toutes les données liées aux workspaces et aux utilisateurs.
      Redis sert aux files d’attente, à la synchronisation de l’état de l’éditeur collaboratif entre serveurs et à la synchronisation WebSocket entre serveurs. Les deux dernières fonctions sont importantes lorsqu’on exécute le logiciel sur plusieurs nœuds ou réplicas.

  • Je travaille chez XWiki. Ça fait plaisir de voir des collègues créer des alternatives open source, et plus il y a d’initiatives de ce type, mieux c’est.
    Construire quelque chose de comparable à Confluence demande énormément de travail, et XWiki est présent dans ce domaine depuis ses débuts. Je me demande comment vous positionnez Docmost par rapport à XWiki, et pourquoi vous avez choisi de ne pas unir vos forces.
    https://xwiki.org

    • J’ai essayé XWiki parce que je voulais migrer de Confluence vers quelque chose d’open source, mais l’expérience utilisateur m’a semblé relativement rugueuse.
      Je me demande s’il existe un ensemble d’extensions recommandées qui le rendrait plus acceptable pour les personnes recherchant une expérience proche de Confluence.

  • J’aimerais avoir ce genre de fonctionnalités.
    Pouvoir utiliser l’éditeur de son choix, gérer les pages en texte brut dans Git ou un autre système de gestion de versions, et committer des pages sans passer par le navigateur. Les pages pourraient être écrites dans un langage de balisage quelconque ; comme Markdown manque d’expressivité dans certains domaines, les pages simples pourraient indiquer qu’elles sont en Markdown via leur extension de fichier, tandis que le wiki pourrait aussi accepter des formats plus puissants et extensibles par l’utilisateur, comme reStructuredText. Il faudrait aussi pouvoir rendre les pages côté serveur et les mettre facilement en cache. Si une page est un fichier, il est facile de valider le cache via une somme sha ; elle pourrait donc s’afficher presque instantanément, contrairement à Confluence, qui est lent et médiocre.

    • Ce n’est pas exactement le même cas d’usage, mais j’utilise https://nextra.site/ avec beaucoup de satisfaction pour créer le site de documentation statique d’un projet.
      Il trouve un bon équilibre : il permet d’utiliser la plupart du temps du Markdown classique, tout en pouvant descendre vers des composants React quand c’est nécessaire. Avec un déploiement continu vers GitHub Pages après merge dans main, l’expérience est plutôt bonne.
    • Si on écrit des documents Markdown hors du navigateur et qu’on les versionne avec Git, je ne vois pas pourquoi on aurait besoin d’un tel outil. J’ai l’impression que cela en contredit l’objectif même.
      Ou alors, l’idée est-elle de publier la documentation avec un workflow adapté aux développeurs, puis de la faire consulter par le reste de l’équipe non développeuse ? En général, je considère que c’est une très mauvaise idée. Si vous imposez à l’équipe un MVP auto-hébergé, probablement plein de bugs, tout en évitant vous-même la couche d’interface utilisée par tout le monde, c’est la recette parfaite pour provoquer un rejet et un remplacement de l’outil. J’ai vu des fondateurs techniques faire cette erreur très souvent. Le même phénomène se produit avec les CMS de sites marketing : ils découvrent que site statique + Markdown + Git ne passe pas à l’échelle avec des non-développeurs, puis se rendent compte que le CMS headless qu’eux-mêmes n’utilisent pas est médiocre au quotidien.
    • Dans mon entreprise, nous utilisons Jekyll pour cet usage, nous construisons le site avec GitHub Actions, puis nous l’hébergeons sur GitHub Pages.
      Cela fonctionne très bien et prend aussi en charge les diagrammes Mermaid, MathML, etc.
    • Je me demande si tu as déjà regardé MyST. Il est aussi expressif que ReST et, à titre personnel, je le trouve beaucoup plus facile à utiliser.
    • Une voix de plus contre Markdown.
      Markdown convient aux documents simples, mais il est très faible pour les wikis, où les liens entre pages sont essentiels. Personnellement, je trouve que le balisage Creole est bien meilleur pour rédiger un wiki. Il vaut mieux ne pas stocker le format de fichier dans l’extension, et conserver les métadonnées comme de vraies métadonnées. L’application voudra de toute façon probablement gérer bien plus de métadonnées, donc il faudra tôt ou tard un système de stockage des métadonnées. Je me considère comme un croisé solitaire pour retirer les métadonnées des noms de fichiers.

  • Confluence a été, parmi les logiciels d’entreprise que j’ai utilisés jusqu’ici, peut-être le plus lent, à l’exception de l’énorme Jira
    Chez PayPal, « attendre Confluence » était devenu une expression idiomatique du genre « mon monorepo est en train de télécharger toutes ses dépendances ». On pouvait prendre une longue pause, traverser la rue pour aller boire un café, le temps qu’un document situé à l’autre bout du quartier se charge. Et je n’essayais même pas de le mettre à jour, donc tout ce qui fait mieux est préférable. Ce n’est presque pas une exagération

  • C’est un très chouette projet. Je me demande s’il existe un moyen de le soutenir
    J’ai aussi vu que la documentation utilisait Docusaurus, mais ce serait bien d’y utiliser Docmost lui-même. Cela ferait office d’environnement de démo, même en lecture seule, et ce serait en même temps une façon de développer en l’utilisant soi-même