Docmost - ConfluenceとNotionに似たオープンソースのコラボレーション文書・Wikiソフトウェア
(github.com/docmost)- Docmostは、チームが文書を共同で作成・管理するためのオープンソースのコラボレーションWikiおよびドキュメント作成ソフトウェアのプロジェクト
- 主な機能には、リアルタイムコラボレーション、Spaces、権限管理、グループ、コメント、ページ履歴、検索、ファイル添付が含まれる
- ドキュメントには、Draw.io、Excalidraw、Mermaidベースのダイアグラム、Airtable・Loom・Miroなどの埋め込み、10以上の言語への翻訳機能が含まれる
- 始めるには公式のドキュメントを参照するか、クラウド版を試すことができる
- Docmost coreはAGPL 3.0でライセンスされており、Enterprise機能および特定ディレクトリ内のファイルはDocmost Enterpriseライセンスに従う
Docmost概要
- DocmostはオープンソースのコラボレーションWikiおよびドキュメント作成ソフトウェア
- プロジェクトは公式のWebsite、Documentation、Twitter / Xを提供している
- 始め方はdocumentationを参照するか、cloud versionを試してみる方法
コラボレーションと文書機能
- Real-time collaborationをサポート
- 文書空間を分けるSpaces機能がある
- 権限管理とグループ機能を提供
- コメントとページ履歴をサポート
- 検索とファイル添付機能を含む
ダイアグラム、埋め込み、翻訳
- Diagrams機能はDraw.io、Excalidraw、Mermaidをサポート
- EmbedsはAirtable、Loom、Miroなどを含む
- 翻訳は10以上の言語をサポート
ライセンス構成
- Docmost coreはオープンソースのAGPL 3.0ライセンスで提供される
- Enterprise機能はEnterprise Editionのエンタープライズライセンスのもとで提供される
- 次のディレクトリ内のすべてのファイルは、
packages/ee/Licenseで定義されたDocmost Enterprise licenseに従うapps/server/src/eeapps/client/src/eepackages/ee
開発および謝辞表記
- コントリビューターはdevelopment documentationを参照できる
- Crowdinはローカリゼーションプラットフォームへのアクセスを提供する
- Algoliaはドキュメント向けの全文検索を提供する
3件のコメント
会社では Notion も使えず Obsidian もブロックされていて……使ってみようと思っていますが、なかなか良い代替になりそうですね
使ってみると Notion によく似た、よくできたツールですが
あまりに Notion に似ているぶん、Notion と異なる点で不便さを感じることもありました。
うまく発展していってくれるといいですね
Hacker Newsのコメント
NotionとConfluenceのアクセシビリティは、どちらも本当にひどい。
Docmostを作るにあたってこの点を考慮したのか気になる。米国のADAと、まもなく施行されるEUのEAAを考えると、企業導入ではかなり重要な要素だし、今回はアクセシビリティの宿題をきちんとやった製品があるといいと思う。希望があれば一度レビューできる。ちなみに自分はネイティブのスクリーンリーダーユーザーで、視覚障害者であり、開発者であり、アクセシビリティ監査人でもある。
たとえばサイドバーのページツリーはキーボード操作をサポートしている。使っているUIライブラリのMantineもアクセシビリティのベストプラクティスに従っており、完全なキーボードサポートを提供している。まだやることは多いが、プロジェクトが進むにつれてサポートはさらに増やしていく予定。以前、Twitterスレッドを音声で聴けるTwitterボット
@threadvoiceを作ったことがあり、そのときもアクセシビリティが動機の一つだった。https://twitter.com/Philipofficial9/status/11899711858004869...
細かいフィードバックとして、製品を使ってみたいと思ったし、Webサイトもすっきりしていて有望に見えたのだが、インストールページが怖くて危うく離脱しそうになった。
最初の案内がDockerのインストールだった。「Prerequisites」というセクション名なのは分かるが、インストール方法がDockerしかないなら、期待するのは
docker-composeと変数のドキュメント程度だった。「Installation Steps」もmkdir、cd、curl、viで始まり、結局は「この docker-compose を使え」という流れになっている。前提条件は多くの人にとって重要かもしれないし、これを問題だと考えるなら解決方法はいくつもある。開発者や技術に慣れた人は、全部飛ばしてまずターミナルコマンドやコードを見る。だからリポジトリのREADME上部に「やってはいけないこと」をあまり上のほうに置くべきではない。そこが私たちが最初にコピー＆ペーストする部分になるからだ。批判ではなく、とてもよくできていると思うが、そのページで取りこぼしてしまうかもしれない普通の試用者からのフィードバック。https://docmost.com/docs/installation
また環境変数の管理は、docker composeファイルを編集させるよりも .envファイル を使うほうがよい。多くの人はyamlファイルをバージョン管理に入れる可能性が高いので、そこに秘密情報を平文で置くのはよい考えではない。
https://docs.docker.com/compose/environment-variables/set-en...
runitを使い、データベース、redis、アプリを同じコンテナに入れて、大きめのデータディレクトリを1つ用意すればよい。コンテナを実行できる大半の小規模チームにはそれで十分で、「ちょっと試してみる」体験がそのまま
docker runになる。まだVPNの裏でConfluenceオンプレミスを使っている。移行するにはPDFエクスポート、Gliffyのような統合ダイアグラムエディタ、履歴と差分が必要。
今のところはOutlineが一番近かったが、急いではいないので、このプロジェクトの進展も見守るつもり。
XWikiはConfluenceとほぼ同時期に始まったオープンソースのWikiソフトウェアで、挙げられていた機能をすべて備えている。マイグレーション支援やコンサルティングも提供しており、移行ツールはコンテンツと機能を可能な限り保持しようとしていて、互換マクロも開発中。必要なら連絡してほしい。
https://xwiki.com
http://xwiki.org
コードのREADMEや、sphinx、mkdocs、swaggerのようにコードベースから生成される文書をWikiと一緒に束ねることが重要。統合ダイアグラムエディタについては、MermaidやKrokiのような文書コード抽象化で標準化すれば、差分比較可能なダイアグラムコードと複数のオープンソースエディタを活用できる。VSCode拡張にもいくつか実装があり、Mermaidを選べば同じダイアグラムがWikiツール、GitHub、Foam、Dendron、Obsidian.mdのようなローカルファーストな公開コンテンツ形式ツールでも共通して動くので良い。
PDFエクスポート、OAuth2、リビジョン、履歴、権限、WYSIWYG/Markdown/ダイアグラムなどをサポートしている。
https://www.bookstackapp.com/
ダイアグラムも追加予定で、次はMermaidJs。その後は、元データを効率よく保存・取り込みする方法を整理したうえで、Draw.ioやExcalidrawのような他のダイアグラム提供元も追加できる。ページ履歴はサポートしているが、まだ差分比較はない。
会社で文書ツールを評価しているが、規制環境が特殊で、文書を作成する人とレビュー・承認する人が異なる
このため、文書向けマージリクエストという概念は差別化機能になり得る。誰かが文書を作成し、別の人が修正したうえで、変更内容をレビュー依頼として提出する方式だ。GitBookにはあるが、ほかの重要な部分が私たちには不足している
編集、レビュー、マージを別のシステムに処理してほしくない。Gitから文書を送り、必要な文書関連機能を適切にホスティングしてくれるシステムに継続デプロイするだけにしたい
そうすると検索結果が汚染され、すぐに散らかってしまう
ウィキと、社内でウィキを使う特定のやり方がとても好きだ
ただし、ウィキを理解していない顧客向けの企業営業に引っ張られているような一部のウィキソフトウェア製品は、それほど好きではない。ある企業向け製品がかなりうまくやっていた点は、描画ツールの統合だった。会社の全員がこの統合を必要としているわけではないが、一部のユーザーには必要であり、そのおかげで、なければ残らなかったはずの非常に有用な視覚資料を記録できる
ほとんどの文書ソフトウェアにおける最大の問題は二つある
第一に、すべてが閉じ込められていることだ。ノートを簡単にエクスポートしたりバックアップしたりできるべきだ。第二に、価格設定が細かく金を取る感じが強すぎる。文書ツリーのノードが100個を超えたらプランを上げろとか、プロジェクトに人を追加するたびに購入判断が発生して疲れる。PostgresとRedisをどのように使っているのか、もっと説明してもらえるとうれしい
Redisはキュー、サーバー間での協調編集状態の同期、サーバー間でのWebSocket同期に使っている。最後の二つの機能は、複数ノードやレプリカでソフトウェアを動かすときに重要だ
XWikiで働いている。オープンソース代替を作る同業者を見るのはうれしいし、こうした試みは多いほどよい
Confluenceに匹敵するものを作るには本当に多くの作業が必要で、XWikiは初期からこの領域にいた。DocmostをXWikiと比べてどう位置付けているのか、そして力を合わせないと決めた理由が気になる
https://xwiki.org
Confluenceのような体験を求める人たちに、より受け入れられやすくするおすすめの拡張パッケージがあるのか気になる
こういう機能があるとよい
好きなエディタを使ってページをGitや他のバージョン管理システムでプレーンテキストとして管理し、ブラウザを介さずにページをコミットできるとよい。ページは何らかのマークアップ言語で書くとしても、Markdownは一部の領域で表現力が足りないので、単純なページはファイル拡張子でMarkdownだと分かるようにしつつ、ウィキではreStructuredTextのような、ユーザーが拡張できるより強力な形式も許可するとよい。また、ページをサーバー側でレンダリングして簡単にキャッシュできるとよい。ページがファイルならshaハッシュでキャッシュの有効性を簡単に確認できるので、遅くてひどいConfluenceとは違って、ほぼ即座に表示できるはずだ
基本的には普通のMarkdownを書けるようにしつつ、必要なときにはReactコンポーネントに降りられるというバランスがうまい。mainにマージしたらGitHub Pagesへ継続デプロイする形なら、かなり良い体験だ
あるいは、開発者に優しいワークフローで文書を上げて、残りの非開発者チームメンバーに見せたいということなのだろうか。一般的には本当に悪い考えだと思う。セルフホストの、おそらくバグの多いMVPをチームに投げ込み、自分は皆が使うUIレイヤーをろくに扱わないのだとしたら、反発とツール乗り換えが起きる組み合わせだ。技術系創業者がこのミスをするのを本当によく見てきた。静的サイト + Markdown + Gitが非開発者にはスケールしないことに気づき、自分では使わないヘッドレスCMSが日常利用ではひどいと分かるマーケティングサイトのCMSでも、同じことが起きている
とてもうまく動いており、MermaidダイアグラムやMathMLなどもサポートしている
Markdownは単純な文書にはよいが、ページ間リンクが中核となるウィキには非常に弱い。個人的には、Creoleマークアップのほうがウィキ執筆にはずっと適していると思う。ファイル形式を拡張子に保存するのではなく、メタデータはきちんとメタデータとして保存したほうがよい。アプリケーションはいずれ、どうせもっと多くのメタデータを持ちたくなる可能性が高いので、結局メタデータ保存の仕組みが必要になる。ファイル名からメタデータをなくそうという孤独な十字軍を自任している
Confluence は、これまで使ってきた企業向けソフトウェアの中でも、おそらく巨大な Jira を除けば最も遅かった。
PayPal では「Confluence 待ち」は、「自分のモノレポがすべての依存関係をダウンロード中」と並ぶ決まり文句になっていた。向こう側の文書が読み込まれるのを待つ間に、通りを渡ってコーヒーを飲んで戻ってこられるほど長い休憩が取れた。その文書を更新しようとすらしていないので、これより良いものなら何でもましだった。ほとんど誇張ではない
とても素晴らしいプロジェクト。支援する方法があるのか気になる。
ドキュメントに Docusaurus を使っているのも見たが、ここで Docmost 自体を使うこと も良さそう。そうすれば、読み取り専用だとしてもデモ環境になり、同時に自分たちで実際に使ってみる開発スタイルにもできる