Docmost - software de documentación y wiki colaborativa de código abierto, similar a Confluence y Notion

 (github.com/docmost)
4 puntos por GN⁺ 2024-06-30 | 3 comentarios | Compartir por WhatsApp
  • Docmost es un proyecto de wiki colaborativa de código abierto y software de documentación para que los equipos redacten y administren documentos en conjunto
  • Sus funciones principales incluyen colaboración en tiempo real, Spaces, gestión de permisos, grupos, comentarios, historial de páginas, búsqueda y archivos adjuntos
  • La documentación incluye diagramas basados en Draw.io, Excalidraw y Mermaid, integraciones embebidas como Airtable, Loom y Miro, y traducción a más de 10 idiomas
  • Para comenzar, se puede consultar la documentación oficial o probar la versión en la nube
  • El núcleo de Docmost está licenciado bajo AGPL 3.0, mientras que las funciones Enterprise y los archivos de directorios específicos siguen la licencia Docmost Enterprise

Descripción general de Docmost

Funciones de colaboración y documentación

  • Compatible con Real-time collaboration
  • Incluye la función Spaces para separar espacios de documentación
  • Ofrece gestión de permisos y funciones de grupos
  • Soporta comentarios e historial de páginas
  • Incluye búsqueda y archivos adjuntos

Diagramas, embebidos y traducción

  • La función Diagrams es compatible con Draw.io, Excalidraw y Mermaid
  • Los Embeds incluyen Airtable, Loom y Miro, entre otros
  • La traducción es compatible con más de 10 idiomas

Estructura de licencias

  • El núcleo de Docmost se ofrece como código abierto bajo licencia AGPL 3.0
  • Las funciones Enterprise se ofrecen bajo la licencia empresarial de Enterprise Edition
  • Todos los archivos de los siguientes directorios siguen la licencia Docmost Enterprise definida en packages/ee/License
    • apps/server/src/ee
    • apps/client/src/ee
    • packages/ee

Desarrollo y agradecimientos

  • Los colaboradores pueden consultar la development documentation
  • Crowdin proporciona acceso a la plataforma de localización
  • Algolia ofrece búsqueda de texto completo para la documentación

Lecturas relacionadas

3 comentarios

 
nutella 2025-01-10

Como en la empresa no se puede usar Notion y también está bloqueado Obsidian... estoy pensando en probarlo, y parece que podría ser una buena alternativa.
 
moderato 2024-10-10

Después de usarlo, me pareció una herramienta bien hecha, similar a Notion.
Pero como se parece demasiado a Notion, también llegan a surgir incomodidades en puntos donde es diferente de Notion.
Ojalá siga evolucionando bien.
 
GN⁺ 2024-06-30
Opiniones de Hacker News

  • La accesibilidad de Notion y Confluence es realmente pésima en ambos casos.
    Me pregunto si tuvieron esto en cuenta al crear Docmost. Considerando la ADA de EE. UU. y la EAA de la UE, que pronto entrará en vigor, es un factor bastante importante para la adopción empresarial, y sería bueno que esta vez hubiera un producto que haya hecho bien la tarea de accesibilidad. Si quieren, puedo revisarlo. Como referencia, soy usuario nativo de lectores de pantalla, persona con discapacidad visual, desarrollador y auditor de accesibilidad.

    • Si ya es así para personas con manos y ojos comunes, imagina cómo será para las personas con discapacidad.
    • Sí pensamos en la accesibilidad.
      Por ejemplo, el árbol de páginas de la barra lateral admite navegación con teclado. La biblioteca de UI que usamos, Mantine, también sigue buenas prácticas de accesibilidad y ofrece soporte completo de teclado. Todavía queda mucho por hacer, pero a medida que avance el proyecto habrá más soporte. Hace tiempo creé @threadvoice, un bot de Twitter que permitía escuchar hilos de Twitter en audio, y en ese entonces la accesibilidad también fue una de las motivaciones.
      https://twitter.com/Philipofficial9/status/11899711858004869...
    • La autenticación también es un problema. En esos dos sitios, prefiero perderlo todo antes que volver a pasar por el proceso de inicio de sesión.
    • Si las empresas ya usan Confluence y Notion, que manejan tan mal la accesibilidad, me pregunto qué tan importante es esto realmente para ellas.
    • Es importante, pero no creo que lo pondría como lo primero a resolver apenas se inicia un proyecto.

  • Como pequeña retroalimentación: quería probar el producto y el sitio web se veía limpio y prometedor, pero la página de instalación me asustó y casi me hizo abandonar.
    Las primeras instrucciones eran para instalar Docker, y aunque entiendo que la sección se llama “Prerequisites”, si el único método de instalación es Docker, esperaba algo como docker-compose y documentación de variables. “Installation Steps” también empieza con mkdir, cd, curl y vi, para terminar básicamente en “usa este docker-compose”. Los prerrequisitos pueden ser importantes para mucha gente y, si consideran que esto es un problema, hay muchas formas de resolverlo. Los desarrolladores y la gente con experiencia técnica se saltan todo y van directo a los comandos de terminal o al código. Por eso no conviene poner un “no hacer” demasiado arriba en el README del repositorio: porque se convierte en lo primero que vamos a copiar y pegar. No es una crítica; parece que hicieron un gran trabajo, pero es la opinión de un experimentador común al que podrían perder en esa página.
    https://docmost.com/docs/installation

    • Sería mejor quitar las instrucciones de instalación de Docker. La gente puede verlas en la documentación de Docker, y no hay mucho motivo para duplicarlas en otro lado.
      Además, para manejar variables de entorno sería mejor usar un archivo .env en lugar de hacer que se edite el archivo docker compose. Es probable que mucha gente ponga el archivo yaml bajo control de versiones, así que no es buena idea dejar secretos en texto plano allí.
      https://docs.docker.com/compose/environment-variables/set-en...
    • Si quieren aumentar la adopción, creo que deberían ofrecer un contenedor todo en uno.
      Bastaría con usar runit, meter la base de datos, redis y la app en el mismo contenedor, y dejar un único directorio de datos grande. Para la mayoría de los equipos pequeños que pueden ejecutar contenedores, eso sería suficiente, y la experiencia de “probarlo” se vuelve simplemente docker run.

  • Todavía usamos Confluence on-premise detrás de una VPN. Para migrar, necesitaríamos exportación a PDF, un editor de diagramas integrado como Gliffy, historial y diferencias.
    Hasta ahora Outline ha sido lo más cercano, pero no tenemos prisa, así que también seguiré viendo cómo evoluciona este proyecto.

    • En XWiki SAS estamos creando una herramienta para migrar de Confluence a XWiki.
      XWiki es un software wiki de código abierto que empezó más o menos en la misma época que Confluence, y tiene todas las funciones que mencionas. También ofrecemos soporte de migración y consultoría, y la herramienta de migración intenta preservar tanto contenido y funcionalidad como sea posible; además estamos trabajando en macros compatibles. Si lo necesitas, puedes contactarnos.
      https://xwiki.com
      http://xwiki.org
    • Creo que la necesidad más grande que es fácil pasar por alto al venir de Confluence es la integración entre la wiki y la documentación de código.
      Es importante reunir la wiki con documentos generados desde la base de código, como README del código, sphinx, mkdocs y swagger. En cuanto al editor de diagramas integrado, si se estandariza sobre abstracciones de documentación como código como Mermaid o Kroki, se puede aprovechar código de diagramas comparable con diffs y varios editores open source. También hay varias implementaciones en extensiones de VSCode, y si eliges Mermaid, el mismo diagrama funciona en herramientas de wiki, GitHub y herramientas de contenido público local-first como Foam, Dendron y Obsidian.md, lo cual está muy bien.
    • Uso Bookstack para este propósito y puedo recomendarlo. Es gratis y open source.
      Soporta exportación a PDF, OAuth2, revisiones, historial, permisos, WYSIWYG/Markdown/diagramas, etc.
      https://www.bookstackapp.com/
    • La exportación a PDF está en camino.
      Los diagramas también vendrán, y lo siguiente será MermaidJs. Otros proveedores de diagramas como Draw.io y Excalidraw podrán agregarse después de definir una forma eficiente de guardar e importar los datos originales. El historial de páginas ya está soportado, pero todavía no hay comparación de diferencias.
    • No lo he usado en Confluence, pero https://www.tldraw.com/ al menos se puede embeber en Notion y funciona muy bien como editor de diagramas.

  • En la empresa estamos evaluando herramientas de documentación, pero nuestro entorno regulatorio es particular: quien crea un documento no es la misma persona que lo revisa y lo aprueba.
    Por eso, el concepto de solicitudes de fusión para documentos podría ser una función diferenciadora. La idea es que alguien cree un documento, otra persona lo modifique y luego envíe los cambios como solicitud de revisión. GitBook lo tiene, pero otras partes clave nos quedan cortas.

    • Hace tiempo que quería algo así, pero pensándolo bien terminé prefiriendo simplemente usar Git y hacer push de documentos Markdown a un sistema de notas.
      No quiero que otro sistema se encargue de la edición, la revisión y la fusión. Quiero enviar los documentos desde Git y solo hacer despliegue continuo hacia un sistema que aloje correctamente las funciones necesarias relacionadas con documentos.
    • Creo que sería una gran función. Tenemos un problema parecido: existe una versión oficial de la documentación que pasó por revisión, y si queremos trabajar en la siguiente versión en Confluence tenemos que crear una página de trabajo aparte.
      Eso contamina los resultados de búsqueda y se vuelve desordenado muy rápido.
    • Si las solicitudes de fusión de documentos son el requisito principal, me da curiosidad qué otras funciones no bastarían con Git u otro sistema de control de versiones.
    • Sería una función realmente buena.

  • Me gustan mucho los wikis y ciertas formas específicas de usarlos dentro de una empresa.
    Sin embargo, no me gustan tanto algunos productos de software wiki que parecen dejarse arrastrar por ventas empresariales a clientes que no entienden los wikis. Algo que un producto empresarial hacía bastante bien era la integración de herramientas de dibujo. No todas las personas de la empresa necesitan esta integración, pero algunos usuarios sí, y gracias a eso pueden quedar registrados materiales visuales muy útiles que de otro modo no habrían sobrevivido.

    • https://www.tldraw.com/ al menos se puede incrustar en vivo en Notion, así que ofrece una función de dibujo colaborativo bastante buena incluso dentro de wikis que originalmente no la soportan. Todavía no lo probé en Confluence ni en otras herramientas.
    • Me pregunto si podrías resumir algunas ideas clave sobre por qué te gustan los wikis. En especial, quisiera saber qué formas de uso funcionan mejor dentro de una empresa.

  • Los mayores problemas de la mayoría del software de documentación son dos.
    Primero, todo queda encerrado. Debería ser fácil exportar o respaldar las notas. Segundo, la política de precios se siente demasiado como cobrar por cada detalle: que si el árbol de documentos supera los 100 nodos, sube de plan; que cada vez que agregas a alguien al proyecto se convierte en una decisión de compra y genera cansancio. Me gustaría que explicaras más cómo usan Postgres y Redis.

    • Postgres es la base de datos principal donde se almacenan todos los datos relacionados con workspaces y usuarios.
      Redis se usa para colas, sincronización del estado del editor colaborativo entre servidores y sincronización de WebSocket entre servidores. Las dos últimas funciones son importantes cuando se ejecuta el software en varios nodos o réplicas.

  • Trabajo en XWiki. Me alegra ver a colegas creando alternativas open source; mientras más iniciativas de este tipo haya, mejor.
    Para crear algo comparable con Confluence hace falta muchísimo trabajo, y XWiki ha estado en este espacio desde sus inicios. Me da curiosidad cómo posicionan Docmost frente a XWiki y por qué decidieron no sumar fuerzas.
    https://xwiki.org

    • Probé XWiki porque quería pasar de Confluence a algo open source, pero la experiencia de usuario me pareció relativamente áspera.
      Me pregunto si existe algún paquete de extensiones recomendado que lo haga más aceptable para quienes buscan una experiencia similar a Confluence.

  • Me gustaría que existieran estas funciones.
    Sería bueno poder usar el editor que uno quiera para gestionar páginas como texto plano en Git u otro sistema de control de versiones, y poder hacer commit de páginas sin pasar por el navegador. Las páginas podrían escribirse en algún lenguaje de marcado, pero como Markdown carece de expresividad en algunas áreas, las páginas simples deberían poder identificarse como Markdown por la extensión de archivo, y el wiki también debería permitir formatos más potentes y extensibles por el usuario, como reStructuredText. Además, sería bueno que las páginas se renderizaran del lado del servidor y pudieran cachearse fácilmente. Si una página es un archivo, se puede validar fácilmente la caché con una suma sha, de modo que, a diferencia del lento y pésimo Confluence, podría mostrarse casi al instante.

    • No es exactamente el mismo caso de uso, pero he usado muy bien https://nextra.site/ para crear el sitio de documentación estática de un proyecto.
      Logra un buen equilibrio: permite usar casi siempre Markdown común y, cuando hace falta, bajar a componentes React. Si al fusionar a main se despliega de forma continua a GitHub Pages, la experiencia es bastante buena.
    • Si vas a escribir documentos Markdown fuera del navegador y versionarlos con Git, no sé para qué haría falta una herramienta así. Me parece que eso derrumba el propósito en sí.
      O quizá la idea sea subir documentación con un flujo amigable para desarrolladores y que luego el resto del equipo no desarrollador la vea. En general, me parece una muy mala idea. Si le lanzas al equipo un MVP autohospedado, probablemente lleno de bugs, y tú ni siquiera usas la capa de UI que todos los demás sí usan, es la receta para que haya resistencia y cambien de herramienta. He visto a fundadores técnicos cometer muchísimo este error. Lo mismo pasa con CMS para sitios de marketing: se dan cuenta de que sitio estático + Markdown + Git no escala para gente no desarrolladora, y luego descubren que el CMS headless que ellos no usan es pésimo para el uso diario.
    • En la empresa usamos Jekyll para esto: compilamos el sitio con GitHub Actions y lo alojamos en GitHub Pages.
      Funciona muy bien y también soporta diagramas Mermaid, MathML, etc.
    • Me pregunto si has visto MyST. Es tan expresivo como ReST y, personalmente, me parece mucho más fácil de usar.
    • Otro voto en contra de Markdown.
      Markdown está bien para documentos simples, pero es muy débil para wikis donde los enlaces entre páginas son fundamentales. Personalmente, creo que el marcado Creole es mucho mejor para escribir wikis. Es mejor no guardar el formato del archivo en la extensión; los metadatos deberían guardarse correctamente como metadatos. Es muy probable que la aplicación de todos modos quiera tener muchos más metadatos, así que al final hará falta un sistema para almacenarlos. Me considero un cruzado solitario por eliminar los metadatos de los nombres de archivo.

  • Confluence fue, de todo el software empresarial que he usado hasta ahora, quizá el más lento, salvo por el enorme Jira.
    En PayPal, “esperando a Confluence” se volvió una expresión como “mi monorepo está descargando todas las dependencias”. Podías tomarte una pausa larga, cruzar la calle por un café y volver mientras esperabas a que cargara un documento del otro lado del barrio. Ni siquiera intenté actualizar ese documento, así que cualquier cosa mejor que eso ya es una mejora. Casi no estoy exagerando.

  • Es un proyecto muy genial. Me pregunto si hay alguna forma de apoyarlo económicamente.
    También vi que la documentación usa Docusaurus, pero estaría bueno usar el propio Docmost ahí. Así serviría como entorno de demo, aunque sea de solo lectura, y al mismo tiempo como una forma de desarrollo basada en usarlo directamente.