Docmost — Software de documentação colaborativa e wiki open source semelhante ao Confluence e ao Notion

 (github.com/docmost)
4 pontos por GN⁺ 2024-06-30 | 3 comentários | Compartilhar no WhatsApp
  • O Docmost é um software de wiki colaborativa open source e documentação, um projeto voltado para equipes criarem e gerenciarem documentos em conjunto
  • Os principais recursos incluem colaboração em tempo real, Spaces, gerenciamento de permissões, grupos, comentários, histórico de páginas, busca e anexos de arquivos
  • A documentação inclui diagramas baseados em Draw.io, Excalidraw e Mermaid, embeds de Airtable, Loom, Miro etc., além de recursos de tradução para mais de 10 idiomas
  • Para começar, consulte a documentação oficial ou experimente a versão em nuvem
  • O Docmost core é licenciado sob AGPL 3.0, enquanto os recursos Enterprise e os arquivos nos diretórios especificados seguem a licença Docmost Enterprise

Visão geral do Docmost

Recursos de colaboração e documentação

  • Oferece suporte a Real-time collaboration
  • Conta com o recurso Spaces para separar espaços de documentação
  • Oferece gerenciamento de permissões e recursos de grupos
  • Oferece suporte a comentários e histórico de páginas
  • Inclui busca e anexos de arquivos

Diagramas, embeds e tradução

  • O recurso Diagrams oferece suporte a Draw.io, Excalidraw e Mermaid
  • Embeds incluem Airtable, Loom, Miro etc.
  • A tradução oferece suporte a mais de 10 idiomas

Estrutura de licenciamento

  • O Docmost core é disponibilizado sob a licença open source AGPL 3.0
  • Os recursos Enterprise são disponibilizados sob a licença empresarial da Enterprise Edition
  • Todos os arquivos nos diretórios a seguir seguem a Docmost Enterprise license definida em packages/ee/License
    • apps/server/src/ee
    • apps/client/src/ee
    • packages/ee

Desenvolvimento e agradecimentos

  • Colaboradores podem consultar a development documentation
  • O Crowdin oferece acesso à plataforma de localização
  • O Algolia fornece busca de texto completo para a documentação

Leituras relacionadas

3 comentários

 
nutella 2025-01-10

Na empresa, o Notion também não funciona e o Obsidian também está bloqueado... Estou pensando em usar isso, e parece que pode ser uma boa alternativa.
 
moderato 2024-10-10

Pelo que usei, é uma ferramenta bem feita, parecida com o Notion.
Mas, por ser parecida demais com o Notion, acaba trazendo incômodos justamente nos pontos em que difere do Notion.
Espero que evolua bem.
 
GN⁺ 2024-06-30
Opiniões do Hacker News

  • A acessibilidade do Notion e do Confluence é realmente péssima em ambos
    Fico curioso para saber se vocês consideraram isso ao criar o Docmost. Pensando na ADA dos EUA e na EAA da UE, que entrará em vigor em breve, é um fator bastante importante para adoção por empresas, e seria bom ter, desta vez, um produto que tenha feito direito a lição de casa de acessibilidade. Se quiserem, posso fazer uma análise. Para referência, sou usuário nativo de leitor de tela, pessoa com deficiência visual, desenvolvedor e auditor de acessibilidade

    • Se já é assim para pessoas com mãos e olhos típicos, é só imaginar como deve ser para pessoas com deficiência
    • Pensamos em acessibilidade
      Por exemplo, a árvore de páginas da barra lateral oferece suporte a navegação por teclado. A biblioteca de UI que usamos, Mantine, também segue boas práticas de acessibilidade e oferece suporte completo a teclado. Ainda há muito a fazer, mas o suporte deve aumentar conforme o projeto avançar. No passado, criei um bot do Twitter, @threadvoice, que permitia ouvir threads do Twitter em áudio, e acessibilidade também foi uma das motivações naquela época
      https://twitter.com/Philipofficial9/status/11899711858004869...
    • Autenticação também é um problema. Nesses dois sites, chego a pensar que preferiria perder tudo a ter que passar pelo processo de login de novo
    • Se as empresas já usam Confluence e Notion, que são tão ruins em acessibilidade, fico em dúvida sobre o quanto isso de fato é importante para elas
    • É importante, sim, mas acho que eu não colocaria como o primeiro item a resolver quando o projeto está apenas começando

  • Um pequeno feedback: eu queria experimentar o produto, e o site parecia limpo e promissor, mas a página de instalação me assustou e quase me fez desistir
    As primeiras instruções eram para instalar o Docker e, embora eu entenda que a seção se chame “Prerequisites”, se o único método de instalação é Docker, eu esperaria algo como docker-compose e documentação das variáveis. A seção “Installation Steps” também começa com mkdir, cd, curl e vi, para no fim seguir o fluxo de “use este docker-compose”. Pré-requisitos podem ser importantes para muita gente e, se vocês considerarem isso um problema, há várias formas de resolver. Desenvolvedores e pessoas familiarizadas com tecnologia pulam tudo e vão direto para comandos de terminal ou código. Por isso, não se deve colocar um “não faça isso” muito no alto do README do repositório. Porque será a primeira parte que vamos copiar e colar. Não é uma crítica; acho que vocês fizeram um ótimo trabalho, mas é um feedback de um experimentador comum que vocês poderiam perder nessa página
    https://docmost.com/docs/installation

    • Acho melhor remover as instruções de instalação do Docker. As pessoas podem vê-las na documentação do Docker, e não há muito motivo para duplicá-las em outro lugar
      Além disso, para gerenciar variáveis de ambiente, seria melhor usar um arquivo .env em vez de fazer as pessoas editarem o arquivo docker compose. Muita gente provavelmente vai colocar o arquivo yaml em controle de versão, então não é uma boa ideia deixar valores secretos ali em texto puro
      https://docs.docker.com/compose/environment-variables/set-en...
    • Se quiserem aumentar a adoção, acho que precisam oferecer um contêiner tudo-em-um
      Basta usar runit, colocar o banco de dados, o redis e o app no mesmo contêiner, e ter um grande diretório de dados. Isso é suficiente para a maioria das equipes pequenas que conseguem executar um contêiner, e a experiência de “experimentar” vira simplesmente docker run

  • Ainda usamos Confluence on-premises atrás de uma VPN. Para migrar, precisaríamos de exportação para PDF, um editor de diagramas integrado como o Gliffy, histórico e diffs
    Até agora, o Outline foi o que chegou mais perto, mas não temos pressa, então também vou acompanhar a evolução deste projeto

    • A XWiki SAS está criando uma ferramenta para migrar do Confluence para o XWiki
      O XWiki é um software de wiki open source que começou por volta da mesma época do Confluence e tem todos os recursos que você mencionou. Também oferecemos suporte de migração e consultoria, e a ferramenta de migração tenta preservar o máximo possível de conteúdo e funcionalidades; também estamos trabalhando em macros compatíveis. Se precisar, pode entrar em contato
      https://xwiki.com
      http://xwiki.org
    • Vindo do Confluence, acho que a maior necessidade fácil de deixar passar é a integração entre a wiki e a documentação de código
      É importante agrupar, junto com a wiki, a documentação gerada a partir da base de código, como READMEs do código, sphinx, mkdocs e swagger. Quanto a editores de diagramas integrados, se vocês padronizarem em abstrações de documentação-como-código como Mermaid ou Kroki, poderão usar código de diagrama comparável por diff e vários editores open source. Também há algumas implementações em extensões do VSCode, e escolher Mermaid é bom porque o mesmo diagrama funciona em ferramentas de wiki, GitHub e ferramentas de formato de conteúdo público local-first como Foam, Dendron e Obsidian.md
    • Uso Bookstack para esse fim e posso recomendar. É gratuito e open source
      Suporta exportação para PDF, OAuth2, revisões, histórico, permissões, WYSIWYG/Markdown/diagramas etc.
      https://www.bookstackapp.com/
    • Exportação para PDF está prevista
      Diagramas também estão previstos, e o próximo da lista é MermaidJs. Outros provedores de diagramas, como Draw.io e Excalidraw, poderão ser adicionados depois de definirmos uma forma eficiente de armazenar e recuperar os dados originais. Há suporte a histórico de páginas, mas ainda não há comparação de diferenças
    • Não usei no Confluence, mas https://www.tldraw.com/ pode pelo menos ser incorporado ao Notion e funciona muito bem como editor de diagramas

  • Na empresa, estamos avaliando ferramentas de documentação, mas nosso ambiente regulatório é peculiar: quem cria o documento é diferente de quem revisa e aprova.
    Por isso, o conceito de merge request para documentos pode ser um diferencial. Seria um fluxo em que alguém cria um documento, outra pessoa o edita e depois envia as alterações como uma solicitação de revisão. O GitBook tem isso, mas faltam outras partes essenciais para nós.

    • Eu queria isso há tempos, mas, pensando melhor, passei a preferir simplesmente usar Git e enviar documentos em Markdown para um sistema de notas.
      Não quero que outro sistema cuide de edição, revisão e merge. Quero enviar os documentos pelo Git e fazer apenas deploy contínuo para um sistema que hospede corretamente os recursos de documentação de que preciso.
    • Acho que seria um ótimo recurso. Temos um problema parecido: há uma versão oficial da documentação que passou por revisão, e, para trabalhar na próxima versão no Confluence, é preciso criar uma página separada de trabalho.
      Isso polui os resultados de busca e rapidamente vira bagunça.
    • Se merge requests para documentos são um requisito central, fico curioso sobre quais outros recursos, que Git ou outro sistema de controle de versão não cobrem o suficiente, seriam necessários.
    • Seria um recurso muito bom de ter.

  • Gosto muito de wikis e de certas formas de usar wikis dentro de empresas.
    Porém, não gosto tanto de alguns produtos de software wiki que parecem ser puxados por vendas corporativas para clientes que não entendem wikis. Uma coisa que certo produto corporativo fez bem foi a integração com ferramentas de desenho. Nem todo mundo na empresa precisa dessa integração, mas alguns usuários precisam, e, graças a ela, materiais visuais muito úteis que de outro modo não ficariam registrados podem ser preservados.

    • https://www.tldraw.com/ pelo menos pode ser incorporado ao vivo no Notion, então oferece uma função de desenho colaborativo bastante boa mesmo dentro de um wiki que originalmente não dá suporte a isso. Ainda não testei no Confluence nem em outras ferramentas.
    • Gostaria de saber se você consegue resumir alguns pontos de sabedoria essenciais sobre por que gosta de wikis. Em especial, queria entender quais formas de uso funcionam melhor dentro de uma empresa.

  • Os maiores problemas da maioria dos softwares de documentação são dois.
    Primeiro, tudo fica preso. Deve ser fácil exportar ou fazer backup das notas. Segundo, a política de preços parece cobrar por tudo em pequenos detalhes. Coisas como mandar subir de plano quando a árvore de documentos passa de 100 nós, ou transformar cada adição de uma pessoa ao projeto em uma decisão de compra, acabam cansando. Seria bom se você pudesse explicar melhor como usa Postgres e Redis.

    • Postgres é o banco de dados principal que armazena todos os workspaces e dados relacionados a usuários.
      Redis é usado para filas, sincronização do estado do editor colaborativo entre servidores e sincronização de WebSocket entre servidores. As duas últimas funções são importantes quando o software é executado em vários nós ou réplicas.

  • Trabalho na XWiki. Fico feliz em ver colegas criando alternativas open source; quanto mais iniciativas assim, melhor.
    Criar algo comparável ao Confluence exige muito trabalho, e a XWiki está nesse espaço desde o começo. Tenho curiosidade sobre como vocês posicionam o Docmost em comparação com a XWiki e por que decidiram não unir forças.
    https://xwiki.org

    • Eu experimentei a XWiki porque queria migrar do Confluence para algo open source, mas a experiência de usuário me pareceu relativamente áspera.
      Gostaria de saber se há um conjunto recomendado de extensões que a torne mais aceitável para quem quer uma experiência parecida com a do Confluence.

  • Seria bom ter estes recursos.
    Poder usar o editor que eu quiser para manter páginas como texto simples no Git ou em outro sistema de controle de versão e fazer commit das páginas sem passar pelo navegador. As páginas poderiam ser escritas em alguma linguagem de marcação; como Markdown não tem expressividade em algumas áreas, páginas simples poderiam indicar pelo sufixo do arquivo que são Markdown, enquanto o wiki também permitiria formatos mais poderosos e extensíveis pelo usuário, como reStructuredText. Também seria bom renderizar as páginas no lado do servidor e conseguir cacheá-las facilmente. Se as páginas forem arquivos, dá para verificar facilmente a validade do cache por soma sha, de modo que elas possam aparecer quase instantaneamente, ao contrário do Confluence lento e ruim.

    • Não é exatamente o mesmo caso de uso, mas tenho usado https://nextra.site/ muito bem para criar o site de documentação estática de um projeto.
      Ele encontra um bom equilíbrio: permite usar, na maior parte do tempo, Markdown comum, mas descer para componentes React quando necessário. Com merge na main e deploy contínuo para o GitHub Pages, a experiência fica muito boa.
    • Se você escreve documentos Markdown fora do navegador e usa Git para versionamento, não entendo por que precisaria de uma ferramenta dessas. Parece até contrariar o próprio objetivo.
      Ou talvez a ideia seja publicar documentação com um fluxo amigável para desenvolvedores e deixar o restante da equipe não desenvolvedora apenas consultar. Em geral, acho uma péssima ideia. Se você joga para a equipe um MVP auto-hospedado, provavelmente cheio de bugs, e depois nem lida com a camada de UI que todo mundo usa, isso é uma receita para resistência e troca de ferramenta. Já vi fundadores técnicos cometerem esse erro muitas vezes. O mesmo acontece com CMS de sites de marketing: percebem que site estático + Markdown + Git não escala para não desenvolvedores, e depois descobrem que o headless CMS que o próprio fundador não usa é péssimo no uso diário.
    • Na empresa, usamos Jekyll para esse fim, construindo o site com GitHub Actions e hospedando no GitHub Pages.
      Funciona muito bem e também dá suporte a diagramas Mermaid, MathML etc.
    • Você já viu o MyST? Ele é tão expressivo quanto ReST e, pessoalmente, acho muito mais fácil de usar.
    • Mais um voto contra Markdown.
      Markdown é bom para documentos simples, mas é muito fraco para wikis, em que links entre páginas são centrais. Pessoalmente, acho a marcação Creole muito melhor para escrever wikis. É melhor não guardar o formato do arquivo na extensão; metadados devem ser armazenados corretamente como metadados. Como a aplicação provavelmente vai querer muito mais metadados de qualquer forma, no fim será necessário um sistema de armazenamento de metadados. Sou um cruzado solitário pela remoção de metadados dos nomes de arquivo.

  • O Confluence foi talvez o software corporativo mais lento que já usei até hoje, com a possível exceção do gigantesco Jira.
    No PayPal, “esperando o Confluence” virou uma expressão idiomática do tipo “meu monorepo está baixando todas as dependências”. Dava para fazer uma longa pausa, atravessar a rua para tomar um café, enquanto esperava carregar um documento do outro lado da empresa. Nem tentei atualizar esse documento, então qualquer coisa melhor que isso já é um avanço. Quase não é exagero.

  • É um projeto muito bacana. Fico curioso para saber se há alguma forma de patrociná-lo.
    Também vi que a documentação usa Docusaurus, mas acho que seria bom usar o próprio Docmost ali. Assim, mesmo que fosse somente leitura, serviria como um ambiente de demonstração e, ao mesmo tempo, como uma forma de desenvolvimento “dogfooding”.