Docmost - Phần mềm tài liệu cộng tác và wiki mã nguồn mở tương tự Confluence & Notion
(github.com/docmost)- Docmost là một dự án wiki cộng tác mã nguồn mở và phần mềm tài liệu hóa, dùng để các nhóm cùng viết và quản lý tài liệu
- Các tính năng chính gồm cộng tác thời gian thực, Spaces, quản lý quyền hạn, nhóm, bình luận, lịch sử trang, tìm kiếm và tệp đính kèm
- Tài liệu hỗ trợ sơ đồ dựa trên Draw.io, Excalidraw, Mermaid, nhúng Airtable·Loom·Miro và các công cụ khác, cùng tính năng dịch sang hơn 10 ngôn ngữ
- Để bắt đầu, có thể tham khảo tài liệu chính thức hoặc dùng thử phiên bản đám mây
- Docmost core được cấp phép theo AGPL 3.0, còn các tính năng Enterprise và tệp trong các thư mục chỉ định tuân theo giấy phép Docmost Enterprise
Tổng quan về Docmost
- Docmost là phần mềm wiki cộng tác và tài liệu hóa mã nguồn mở
- Dự án cung cấp Website, Documentation, Twitter / X chính thức
- Có thể bắt đầu bằng cách tham khảo documentation hoặc dùng thử cloud version
Tính năng cộng tác và tài liệu
- Hỗ trợ Real-time collaboration
- Có tính năng Spaces để phân chia không gian tài liệu
- Cung cấp quản lý quyền hạn và tính năng nhóm
- Hỗ trợ bình luận và lịch sử trang
- Bao gồm tính năng tìm kiếm và tệp đính kèm
Sơ đồ, nhúng và dịch thuật
- Tính năng Diagrams hỗ trợ Draw.io, Excalidraw, Mermaid
- Embeds bao gồm Airtable, Loom, Miro và các công cụ khác
- Hỗ trợ dịch sang hơn 10 ngôn ngữ
Cấu trúc giấy phép
- Docmost core được cung cấp theo giấy phép mã nguồn mở AGPL 3.0
- Các tính năng Enterprise được cung cấp theo giấy phép doanh nghiệp của Enterprise Edition
- Mọi tệp trong các thư mục sau tuân theo Docmost Enterprise license được định nghĩa trong
packages/ee/Licenseapps/server/src/eeapps/client/src/eepackages/ee
Phát triển và ghi nhận
- Người đóng góp có thể tham khảo development documentation
- Crowdin cung cấp quyền truy cập vào nền tảng bản địa hóa
- Algolia cung cấp tìm kiếm toàn văn cho tài liệu
3 bình luận
Ở công ty tôi không dùng được cả Notion lẫn Obsidian... nên đang định thử, có vẻ đây sẽ là một lựa chọn thay thế khá ổn.
Dùng thử thì đây là một công cụ được làm khá tốt, tương tự như Notion.
Nhưng vì quá giống Notion nên cũng phát sinh những điểm bất tiện ở những chỗ khác với Notion.
Hy vọng nó sẽ tiếp tục phát triển tốt.
Các ý kiến trên Hacker News
Khả năng tiếp cận của cả Notion lẫn Confluence đều thật sự thảm hại
Tôi tò mò không biết khi làm Docmost, họ có tính đến phần này không. Nếu xét đến ADA của Mỹ và EAA của EU sắp có hiệu lực, đây là yếu tố khá quan trọng để doanh nghiệp áp dụng, và tôi mong lần này sẽ có một sản phẩm làm tốt bài tập về khả năng tiếp cận. Nếu muốn, tôi có thể xem qua giúp. Nhân tiện, tôi là người dùng screen reader native, người khiếm thị, lập trình viên và kiểm toán viên về khả năng tiếp cận
Ví dụ, cây trang ở sidebar hỗ trợ điều hướng bằng bàn phím. Thư viện UI đang dùng là Mantine cũng tuân theo các best practice về khả năng tiếp cận và cung cấp hỗ trợ bàn phím đầy đủ. Vẫn còn nhiều việc phải làm, nhưng khi dự án tiến triển, phần hỗ trợ này sẽ được mở rộng hơn. Trước đây tôi từng tạo bot Twitter @threadvoice cho phép nghe các thread trên Twitter dưới dạng âm thanh, và khi đó khả năng tiếp cận cũng là một trong những động lực
https://twitter.com/Philipofficial9/status/11899711858004869...
Một góp ý nhỏ: tôi muốn dùng thử sản phẩm, website cũng gọn gàng và có vẻ hứa hẹn, nhưng trang cài đặt khiến tôi hơi sợ và suýt rời đi
Chỉ dẫn đầu tiên là cài Docker; tôi hiểu phần đó có tên là “Prerequisites”, nhưng nếu Docker là cách cài đặt duy nhất thì tôi kỳ vọng chủ yếu là docker-compose và tài liệu về biến. Phần “Installation Steps” cũng bắt đầu bằng mkdir, cd, curl, vi rồi cuối cùng mới đi đến “hãy dùng docker-compose này”. Điều kiện tiên quyết có thể quan trọng với nhiều người, và nếu xem đây là vấn đề thì có nhiều cách xử lý. Nhà phát triển và người quen công nghệ thường bỏ qua mọi thứ và nhìn thẳng vào lệnh terminal hoặc code. Vì vậy đừng đặt phần “không nên làm” quá cao ở đầu README của repository, vì đó sẽ là đoạn đầu tiên chúng tôi sao chép và dán. Đây không phải lời chê; tôi nghĩ sản phẩm được làm rất tốt, chỉ là phản hồi từ một người thử nghiệm bình thường mà các bạn có thể mất ngay tại trang đó
https://docmost.com/docs/installation
Ngoài ra, để quản lý biến môi trường, nên dùng file .env thay vì yêu cầu sửa file docker compose. Nhiều người có khả năng đưa file yaml vào quản lý phiên bản, nên để secret dạng plain text trong đó không phải ý hay
https://docs.docker.com/compose/environment-variables/set-en...
Chỉ cần dùng runit, đưa database, redis và app vào cùng một container, rồi có một thư mục dữ liệu lớn là được. Với hầu hết các nhóm nhỏ có thể chạy container, như vậy là đủ, và trải nghiệm “thử một lần” chỉ còn là
docker runChúng tôi vẫn đang dùng Confluence on-premise sau VPN. Để chuyển đi, chúng tôi cần xuất PDF, trình chỉnh sửa sơ đồ tích hợp kiểu Gliffy, lịch sử và diff
Cho đến nay Outline là lựa chọn gần nhất, nhưng chưa gấp nên tôi cũng sẽ theo dõi sự phát triển của dự án này
XWiki là phần mềm wiki mã nguồn mở ra đời cùng thời với Confluence và có tất cả các tính năng bạn nhắc đến. Họ cũng cung cấp hỗ trợ migration và tư vấn; công cụ chuyển đổi cố gắng giữ lại nhiều nội dung và tính năng nhất có thể, đồng thời cũng đang làm các macro tương thích. Nếu cần, bạn có thể liên hệ
https://xwiki.com
http://xwiki.org
Điều quan trọng là gom các tài liệu được tạo từ codebase như README của code, sphinx, mkdocs, swagger cùng với wiki. Về trình chỉnh sửa sơ đồ tích hợp, nếu chuẩn hóa theo các abstraction dạng docs-as-code như Mermaid hay Kroki, bạn có thể tận dụng code sơ đồ có thể so sánh diff và nhiều trình chỉnh sửa mã nguồn mở. VSCode extension cũng có vài triển khai, và nếu chọn Mermaid thì cùng một sơ đồ sẽ hoạt động trên công cụ wiki, GitHub và các công cụ định dạng nội dung công khai ưu tiên local như Foam, Dendron, Obsidian.md, điều này rất tiện
Hỗ trợ xuất PDF, OAuth2, revision, lịch sử, quyền, WYSIWYG/Markdown/sơ đồ, v.v.
https://www.bookstackapp.com/
Sơ đồ cũng sẽ có, và tiếp theo là MermaidJs. Các provider sơ đồ khác như Draw.io và Excalidraw có thể được thêm sau khi chúng tôi sắp xếp được cách lưu và tải dữ liệu gốc một cách hiệu quả. Lịch sử trang đã được hỗ trợ nhưng hiện chưa có so sánh diff
Công ty đang đánh giá các công cụ tài liệu, nhưng môi trường pháp lý khá đặc thù: người tạo tài liệu và người rà soát/phê duyệt là khác nhau
Vì vậy, khái niệm merge request cho tài liệu có thể trở thành một tính năng khác biệt. Cách làm là ai đó tạo tài liệu, người khác chỉnh sửa, rồi gửi các thay đổi dưới dạng yêu cầu rà soát. GitBook có tính năng này, nhưng lại thiếu những phần cốt lõi khác đối với chúng tôi
Tôi không muốn một hệ thống khác xử lý việc chỉnh sửa, review và merge. Tôi chỉ muốn gửi tài liệu từ Git, rồi continuous deploy sang một hệ thống host tốt các tính năng liên quan đến tài liệu mà mình cần
Như vậy kết quả tìm kiếm bị nhiễu và rất nhanh trở nên lộn xộn
Tôi rất thích wiki và những cách dùng wiki cụ thể trong nội bộ công ty
Tuy nhiên, tôi không thích bằng một số sản phẩm phần mềm wiki dường như bị kéo theo hướng bán hàng doanh nghiệp cho các khách hàng không hiểu wiki. Một điểm mà một sản phẩm doanh nghiệp nào đó đã làm khá tốt là tích hợp công cụ vẽ. Không phải ai trong công ty cũng cần tích hợp này, nhưng một số người dùng thì cần, và nhờ đó có thể ghi lại những tư liệu trực quan rất hữu ích mà nếu không có thì đã không được lưu giữ
Vấn đề lớn nhất của hầu hết phần mềm tài liệu là hai điểm
Thứ nhất, mọi thứ đều bị nhốt kín. Phải có thể dễ dàng xuất hoặc sao lưu ghi chú. Thứ hai, chính sách giá quá vụn vặt và có cảm giác bị tận thu. Chẳng hạn cây tài liệu vượt quá 100 node thì phải nâng gói, hoặc mỗi lần thêm người vào dự án lại trở thành một quyết định mua sắm, rất mệt mỏi. Sẽ rất hay nếu có thể giải thích thêm về cách dùng Postgres và Redis
Redis được dùng cho hàng đợi, đồng bộ trạng thái trình soạn thảo cộng tác giữa các server, và đồng bộ WebSocket giữa các server. Hai tính năng cuối quan trọng khi chạy phần mềm trên nhiều node hoặc replica
Tôi làm việc tại XWiki. Thật vui khi thấy các đồng nghiệp xây dựng những lựa chọn thay thế mã nguồn mở, càng có nhiều nỗ lực như vậy càng tốt
Để tạo ra thứ có thể sánh với Confluence thật sự cần rất nhiều công sức, và XWiki đã ở trong lĩnh vực này từ những ngày đầu. Tôi tò mò bạn định vị Docmost so với XWiki như thế nào, và vì sao không quyết định hợp lực
https://xwiki.org
Tôi tò mò liệu có gói extension được khuyến nghị nào giúp nó dễ chấp nhận hơn với những người muốn có trải nghiệm giống Confluence không
Sẽ rất tuyệt nếu có các tính năng như thế này
Có thể dùng editor mình muốn để quản lý các trang dưới dạng văn bản thuần trong Git hoặc một hệ thống quản lý phiên bản khác, và có thể commit trang mà không cần đi qua trình duyệt. Trang có thể được viết bằng một ngôn ngữ markup nào đó; Markdown thiếu sức biểu đạt ở một số lĩnh vực, nên với các trang đơn giản có thể nhận biết là Markdown qua phần mở rộng file, còn wiki thì cũng nên cho phép các định dạng mạnh hơn và người dùng có thể mở rộng như reStructuredText. Ngoài ra, sẽ tốt nếu trang được render phía server và có thể cache dễ dàng. Nếu trang là file, có thể dễ dàng kiểm tra tính hợp lệ của cache bằng tổng sha, nhờ đó trang có thể hiển thị gần như tức thì, khác với Confluence chậm chạp và tệ hại
Nó cân bằng tốt giữa việc hầu hết thời gian cho dùng Markdown thông thường, nhưng khi cần vẫn có thể đi xuống React component. Nếu merge vào main rồi continuous deploy lên GitHub Pages thì trải nghiệm khá ổn
Hoặc có phải mục tiêu là đưa tài liệu lên bằng workflow thân thiện với developer, rồi để các thành viên còn lại không phải developer xem không? Nói chung tôi xem đó là một ý tưởng thật sự tệ. Nếu ném một MVP tự host, có lẽ nhiều bug, cho cả nhóm dùng, trong khi bản thân bạn lại không đụng đến lớp UI mà mọi người sử dụng, thì đó là công thức dẫn tới phản ứng ngược và thay công cụ. Tôi đã thấy các founder thiên về kỹ thuật mắc lỗi này rất nhiều. Điều tương tự cũng xảy ra với CMS website marketing: họ nhận ra static site + Markdown + Git không mở rộng được cho người không phải developer, rồi phát hiện CMS headless mà bản thân họ không dùng thì rất tệ trong sử dụng hằng ngày
Hoạt động rất tốt và cũng hỗ trợ Mermaid diagram, MathML, v.v.
Markdown ổn cho tài liệu đơn giản, nhưng rất yếu với wiki, nơi liên kết giữa các trang là cốt lõi. Cá nhân tôi thấy markup Creole tốt hơn nhiều cho việc viết wiki. Đừng lưu định dạng file trong phần mở rộng; metadata nên được lưu đúng nghĩa là metadata. Ứng dụng dù sao nhiều khả năng cũng sẽ muốn có nhiều metadata hơn rất nhiều, nên cuối cùng vẫn cần một cơ chế lưu metadata. Tôi tự nhận mình là một kẻ đơn độc trên cuộc thập tự chinh loại metadata khỏi tên file
Confluence là một trong những phần mềm doanh nghiệp chậm nhất tôi từng dùng, có lẽ chỉ thua Jira đồ sộ
Ở PayPal, “đang chờ Confluence” đã trở thành một thành ngữ kiểu như “monorepo của tôi đang tải xuống tất cả dependency”. Bạn có thể nghỉ một quãng dài, băng qua đường uống cà phê rồi quay lại trong lúc chờ một tài liệu ở phía bên kia khu phố tải xong. Tôi thậm chí còn chưa thử cập nhật tài liệu đó, nên bất cứ thứ gì tốt hơn thế cũng đều là cải thiện. Hầu như không hề phóng đại
Một dự án rất tuyệt. Không biết có cách nào tài trợ không
Tôi cũng thấy phần tài liệu đang dùng Docusaurus, nhưng có lẽ dùng chính Docmost cho việc này cũng hay. Như vậy, dù chỉ ở chế độ chỉ đọc, nó cũng sẽ trở thành môi trường demo, đồng thời là một kiểu phát triển bằng cách tự dùng sản phẩm của mình