Docmost - Confluence और Notion जैसा ओपन सोर्स सहयोगी दस्तावेज़ और wiki सॉफ़्टवेयर

 (github.com/docmost)
4 पॉइंट द्वारा GN⁺ 2024-06-30 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • Docmost एक ओपन सोर्स सहयोगी wiki और documentation सॉफ़्टवेयर प्रोजेक्ट है, जिसका उपयोग टीमें मिलकर दस्तावेज़ लिखने और प्रबंधित करने के लिए कर सकती हैं
  • इसकी मुख्य सुविधाओं में real-time collaboration, Spaces, permission management, groups, comments, page history, search और file attachments शामिल हैं
  • दस्तावेज़ों में Draw.io, Excalidraw, Mermaid आधारित diagrams, Airtable·Loom·Miro आदि embeds, और 10 से अधिक भाषाओं में translation की सुविधा शामिल है
  • शुरू करने के लिए आधिकारिक documentation देखें या cloud version आज़माएँ
  • Docmost core AGPL 3.0 के तहत लाइसेंस किया गया है, जबकि Enterprise सुविधाएँ और निर्दिष्ट directories की files Docmost Enterprise license का पालन करती हैं

Docmost परिचय

  • Docmost एक ओपन सोर्स सहयोगी wiki और documentation सॉफ़्टवेयर है
  • प्रोजेक्ट आधिकारिक Website, Documentation, Twitter / X प्रदान करता है
  • शुरू करने के लिए documentation देखें या cloud version आज़माएँ

सहयोग और दस्तावेज़ सुविधाएँ

  • Real-time collaboration का समर्थन करता है
  • दस्तावेज़ों के लिए अलग-अलग space बाँटने की Spaces सुविधा है
  • permission management और groups की सुविधा देता है
  • comments और page history का समर्थन करता है
  • search और file attachment सुविधाएँ शामिल हैं

diagrams, embeds, translation

  • Diagrams सुविधा Draw.io, Excalidraw, Mermaid का समर्थन करती है
  • Embeds में Airtable, Loom, Miro आदि शामिल हैं
  • translation 10 से अधिक भाषाओं का समर्थन करती है

लाइसेंस संरचना

  • Docmost core ओपन सोर्स AGPL 3.0 लाइसेंस के तहत उपलब्ध है
  • Enterprise सुविधाएँ Enterprise Edition के enterprise license के तहत प्रदान की जाती हैं
  • निम्न directories की सभी files packages/ee/License में परिभाषित Docmost Enterprise license का पालन करती हैं
    • apps/server/src/ee
    • apps/client/src/ee
    • packages/ee

development और आभार उल्लेख

  • contributors development documentation देख सकते हैं
  • Crowdin localization platform access प्रदान करता है
  • Algolia documentation के लिए full-text search प्रदान करता है

संबंधित पढ़ाई

3 टिप्पणियां

 
nutella 2025-01-10

कंपनी में Notion भी नहीं चलता और Obsidian भी ब्लॉक है... इसलिए इसे इस्तेमाल करके देखना चाहता हूँ, और लगता है कि यह एक अच्छा विकल्प हो सकता है।
 
moderato 2024-10-10

इस्तेमाल करके देखा तो यह Notion की तरह अच्छी तरह बनाया गया टूल है।
लेकिन Notion से बहुत ज़्यादा मिलता-जुलता होने की वजह से, Notion से अलग होने वाले बिंदुओं पर कुछ असुविधाएँ भी महसूस हुईं।
उम्मीद है कि यह आगे अच्छी तरह विकसित होगा।
 
GN⁺ 2024-06-30
Hacker News की राय

  • Notion और Confluence, दोनों की accessibility सचमुच बेहद खराब है
    Docmost बनाते समय क्या इस हिस्से पर विचार किया गया था, यह जानना चाहूंगा। अमेरिका के ADA और जल्द लागू होने वाले EU के EAA को देखते हुए, enterprise adoption के लिए यह काफी अहम पहलू है, और अच्छा होगा अगर इस बार कोई product accessibility का होमवर्क ठीक से करके आए। चाहें तो मैं एक बार review कर सकता हूं। संदर्भ के लिए, मैं native screen reader user, दृष्टिबाधित व्यक्ति, developer और accessibility auditor हूं

    • अगर सामान्य हाथों और आंखों वाले लोगों के लिए भी ऐसा है, तो कल्पना कीजिए कि दिव्यांग लोगों के लिए कैसा होगा
    • accessibility पर सोचा है
      उदाहरण के लिए, sidebar का page tree keyboard navigation support करता है। हम जिस UI library Mantine का इस्तेमाल कर रहे हैं, वह भी accessibility best practices का पालन करती है और पूरा keyboard support देती है। अभी बहुत काम बाकी है, लेकिन project आगे बढ़ने के साथ support और बढ़ेगा। पहले मैंने @threadvoice नाम का Twitter bot बनाया था, जो Twitter threads को audio में सुनने देता था, और उस समय भी accessibility एक motivation थी
      https://twitter.com/Philipofficial9/status/11899711858004869...
    • authentication भी समस्या है। इन दोनों sites पर फिर से login प्रक्रिया से गुजरने के बजाय मुझे तो लगता है कि सब कुछ खो देना बेहतर होगा
    • अगर companies पहले से ही Confluence और Notion जैसे accessibility में इतने खराब tools इस्तेमाल कर रही हैं, तो संदेह है कि असल में companies के लिए यह कितना महत्वपूर्ण है
    • महत्वपूर्ण तो है, लेकिन project शुरू करते समय सबसे पहले हल करने वाली चीज़ के रूप में शायद इसे नहीं रखूंगा

  • एक छोटा feedback: मैं product आज़माना चाहता था और website भी साफ-सुथरी और promising लगी, लेकिन installation page देखकर मैं लगभग छोड़ने वाला था
    शुरुआती instructions Docker installation की थीं, और मुझे पता है कि section का नाम “Prerequisites” है, लेकिन अगर installation का तरीका सिर्फ Docker है, तो मैं docker-compose और variables documentation जैसी चीज़ों की उम्मीद करता। “Installation Steps” भी mkdir, cd, curl, vi से शुरू होते हैं और आखिर में “यह docker-compose इस्तेमाल करें” तक पहुंचते हैं। prerequisites कई लोगों के लिए महत्वपूर्ण हो सकते हैं, और अगर इसे समस्या माना जाए तो इसे हल करने के कई तरीके हैं। developers और technical लोग सब कुछ skip करके terminal commands या code पर जाते हैं। इसलिए repository README के top पर “क्या नहीं करना है” बहुत ऊपर नहीं रखना चाहिए, क्योंकि वही हिस्सा हम सबसे पहले copy-paste करने वाले होते हैं। यह आलोचना नहीं है, लगता है आपने बढ़िया बनाया है, लेकिन उस page पर खो सकने वाले एक सामान्य experimenter का feedback है
    https://docmost.com/docs/installation

    • Docker installation instructions हटा देना बेहतर होगा। लोग उन्हें Docker docs में देख सकते हैं, और दूसरी जगह duplicate करने की खास वजह नहीं है
      साथ ही environment variables manage करने के लिए docker compose file edit करवाने के बजाय .env file इस्तेमाल करना बेहतर होगा। कई लोग yaml file को version control में रखने की संभावना रखते हैं, इसलिए उसमें secrets को plaintext में रखना अच्छा विचार नहीं है
      https://docs.docker.com/compose/environment-variables/set-en...
    • अगर adoption बढ़ाना चाहते हैं, तो मुझे लगता है कि all-in-one container देना चाहिए
      runit इस्तेमाल करें, database, redis और app को उसी container में रखें, और एक बड़ा data directory दे दें। container चला सकने वाली ज्यादातर छोटी teams के लिए इतना काफी होगा, और “एक बार try करके देखें” वाला experience बस docker run बन जाएगा

  • अभी भी VPN के पीछे Confluence on-premise इस्तेमाल कर रहा हूं। migrate करने के लिए PDF export, Gliffy जैसा integrated diagram editor, history और diffs चाहिए
    अब तक Outline सबसे करीब लगा है, लेकिन जल्दी नहीं है, इसलिए इस project की progress भी देखता रहूंगा

    • XWiki SAS, Confluence से XWiki पर migration करने के लिए tool बना रहा है
      XWiki एक open source wiki software है जो Confluence के आसपास के समय में शुरू हुआ था, और इसमें आपके बताए सभी features हैं। migration support और consulting भी देता है, और migration tool content व features को जितना संभव हो उतना preserve करने की कोशिश करता है और compatible macros पर भी काम चल रहा है। ज़रूरत हो तो संपर्क कर सकते हैं
      https://xwiki.com
      http://xwiki.org
    • Confluence से आने पर जो सबसे बड़ी ज़रूरत छूटना आसान है, वह मुझे wiki और code documentation का integration लगता है
      code के README और sphinx, mkdocs, swagger जैसे codebase से generate होने वाले docs को wiki के साथ जोड़ना महत्वपूर्ण है। integrated diagram editor के संदर्भ में, Mermaid या Kroki जैसी docs-as-code abstraction पर standardize करने से diffable diagram code और कई open source editors का फायदा मिल सकता है। VSCode extensions में भी कुछ implementations हैं, और Mermaid चुनने पर वही diagrams wiki tools, GitHub, Foam, Dendron, Obsidian.md जैसे local-first public content format tools में साथ-साथ काम करते हैं, जो अच्छा है
    • इस काम के लिए Bookstack इस्तेमाल कर रहा हूं और इसकी सिफारिश कर सकता हूं। यह free open source है
      PDF export, OAuth2, revisions, history, permissions, WYSIWYG/Markdown/diagrams आदि support करता है
      https://www.bookstackapp.com/
    • PDF export आने वाला है
      diagrams भी आने वाले हैं, और अगला क्रम MermaidJs है। Draw.io और Excalidraw जैसे दूसरे diagram providers को source data efficiently store और retrieve करने का तरीका तय करने के बाद जोड़ा जा सकता है। page history support है, लेकिन अभी diff comparison नहीं है
    • Confluence में तो इस्तेमाल नहीं किया, लेकिन https://www.tldraw.com/ कम-से-कम Notion में embed किया जा सकता है और diagram editor के रूप में बहुत अच्छा काम करता है

  • कंपनी में हम document tools का मूल्यांकन कर रहे हैं, लेकिन regulatory environment थोड़ा अलग है, इसलिए दस्तावेज़ बनाने वाला व्यक्ति और उसे review/approve करने वाला व्यक्ति अलग होता है
    इसी वजह से दस्तावेज़ों के लिए merge request का concept एक differentiating feature हो सकता है। तरीका यह है कि कोई दस्तावेज़ बनाता है, दूसरा व्यक्ति उसे edit करता है और फिर बदलावों को review request के रूप में submit करता है। GitBook में यह है, लेकिन उसके दूसरे core हिस्से हमारे लिए कम पड़ते हैं

    • मैं इसे काफी समय से चाहता था, लेकिन सोचने पर लगा कि सीधे Git इस्तेमाल करना और Markdown documents को Notes System में push करना मुझे ज़्यादा पसंद है
      मैं नहीं चाहता कि editing, review और merge कोई दूसरा system handle करे। Git से दस्तावेज़ भेजना है और बस ऐसे system पर continuous deploy करना है जो ज़रूरी documentation-related features ठीक से host कर दे
    • यह बेहतरीन feature हो सकता है। हमारी भी मिलती-जुलती समस्या है: review process से गुज़रा हुआ official documentation version होता है, और अगर अगला version Confluence में तैयार करना हो तो अलग work page बनाना पड़ता है
      इससे search results दूषित हो जाते हैं और चीज़ें जल्दी messy हो जाती हैं
    • अगर document merge request core requirement है, तो उत्सुकता है कि Git या किसी दूसरे version control system से पूरी न होने वाली और कौन-सी capabilities चाहिए
    • यह feature हो तो सच में बहुत अच्छा होगा

  • मुझे wiki और कंपनी के अंदर wiki इस्तेमाल करने के कुछ खास तरीके बहुत पसंद हैं
    हालांकि कुछ wiki software products, जो wiki को न समझने वाले customers के लिए enterprise sales की तरफ खिंचे लगते हैं, उतने पसंद नहीं हैं। एक enterprise product ने जो चीज़ काफी अच्छी की थी, वह थी drawing tool integration। कंपनी में हर किसी को इस integration की ज़रूरत नहीं होती, लेकिन कुछ users को होती है, और इसकी वजह से बहुत उपयोगी visual material record हो पाता है जो इसके बिना शायद बचता ही नहीं

    • https://www.tldraw.com/ कम से कम Notion में live embed किया जा सकता है, इसलिए यह उन wikis के अंदर भी काफी अच्छी collaborative drawing capability देता है जो मूल रूप से यह feature support नहीं करतीं। Confluence या दूसरे tools में अभी इसे try नहीं किया
    • उत्सुकता है कि wiki पसंद करने की वजहों से जुड़ी कुछ core wisdom आप summarize कर सकते हैं या नहीं। खासकर यह जानना चाहूँगा कि कंपनी के अंदर कौन-से usage patterns सबसे effective हैं

  • ज़्यादातर documentation software में सबसे बड़ी दो समस्याएँ होती हैं
    पहली, सब कुछ lock-in में फँसा होता है। notes को आसानी से export या backup किया जा सकना चाहिए। दूसरी, pricing policy बहुत nickel-and-dime जैसी लगती है। जैसे document tree में 100 से ज़्यादा nodes हों तो plan upgrade करो, या project में हर व्यक्ति जोड़ना एक purchasing decision बन जाता है और थकान पैदा करता है। अच्छा होगा अगर आप Postgres और Redis कैसे इस्तेमाल करते हैं, यह और समझा सकें

    • Postgres सभी workspaces और user-related data store करने वाला primary database है
      Redis का इस्तेमाल queues, servers के बीच collaborative editor state sync, और servers के बीच WebSocket sync के लिए होता है। आखिरी दो features तब महत्वपूर्ण होते हैं जब software को multiple nodes या replicas पर चलाया जाता है

  • मैं XWiki में काम करता हूँ। open source alternatives बनाने वाले साथियों को देखकर अच्छा लगता है, और ऐसी कोशिशें जितनी ज़्यादा हों उतना बेहतर
    Confluence के बराबर कुछ बनाना सच में बहुत काम मांगता है, और XWiki इस क्षेत्र में शुरुआती दौर से रहा है। उत्सुकता है कि Docmost को आप XWiki की तुलना में कैसे position करते हैं, और साथ मिलकर काम न करने का कारण क्या है
    https://xwiki.org

    • Confluence से किसी open source विकल्प पर जाना चाहता था, इसलिए XWiki try किया, लेकिन user experience अपेक्षाकृत rough लगा
      क्या ऐसे recommended extensions का bundle है जो इसे Confluence जैसी experience चाहने वालों के लिए ज़्यादा acceptable बना दे?

  • ऐसे features हों तो अच्छा होगा
    पसंदीदा editor से pages लिखकर उन्हें Git या किसी दूसरे version control system में plain text के रूप में manage किया जा सके, और browser से गुज़रे बिना भी pages commit किए जा सकें। pages किसी markup language में लिखे जाएँ; लेकिन Markdown कुछ क्षेत्रों में expressiveness में कमजोर है, इसलिए simple pages के लिए file extension से Markdown होना पता चले, और wiki reStructuredText जैसे user-extensible और ज़्यादा powerful formats भी allow करे। साथ ही pages server-side render हों और आसानी से cache किए जा सकें। अगर pages files हैं, तो sha sum से cache validity आसानी से check की जा सकती है, इसलिए वे धीमे और खराब Confluence के उलट लगभग तुरंत दिख सकते हैं

    • बिल्कुल वही use case नहीं है, लेकिन एक project की static documentation site बनाने के लिए https://nextra.site/ का बहुत अच्छा इस्तेमाल कर रहा हूँ
      यह balance अच्छा है कि ज़्यादातर समय plain Markdown लिखने देता है, और ज़रूरत पड़ने पर React components तक उतरने देता है। main में merge होने पर GitHub Pages पर continuous deploy हो जाए, तो experience काफी अच्छा है
    • अगर browser के बाहर Markdown documents लिखकर Git से version control कर रहे हैं, तो समझ नहीं आता ऐसे tool की ज़रूरत क्यों है। क्या इससे उद्देश्य ही खत्म नहीं हो जाता?
      या इरादा यह है कि developer-friendly workflow से docs publish हों और बाकी non-developer team members उन्हें देखें? आम तौर पर मुझे यह सच में बहुत खराब idea लगता है। अगर आप self-hosted, शायद bugs से भरा MVP टीम के सामने रख दें और खुद उस UI layer को handle न करें जिसे सभी इस्तेमाल करेंगे, तो backlash और tool replacement होना तय है। tech founders को यह गलती करते बहुत देखा है। marketing website CMS में भी यही होता है: लोग समझते हैं कि static site + Markdown + Git non-developers तक scale नहीं होता, और फिर पता चलता है कि जिस headless CMS को वे खुद इस्तेमाल नहीं करते, वह daily use में खराब है
    • हमारी कंपनी इस use case के लिए Jekyll इस्तेमाल करती है, GitHub Actions से site build करती है और फिर GitHub Pages पर host करती है
      यह बहुत अच्छा काम करता है और Mermaid diagrams, MathML आदि भी support करता है
    • क्या आपने MyST देखा है? यह ReST जितना expressive है, और निजी तौर पर मुझे इसे इस्तेमाल करना कहीं आसान लगता है
    • Markdown के खिलाफ एक और वोट
      Markdown simple documents के लिए ठीक है, लेकिन pages के बीच links core हों तो wiki के लिए यह बहुत कमजोर है। निजी तौर पर मुझे Creole markup wiki writing के लिए कहीं बेहतर लगता है। file format को extension में store न करें; metadata को सही मायने में metadata की तरह store करना बेहतर है। application वैसे भी शायद बहुत अधिक metadata रखना चाहेगी, इसलिए आखिरकार metadata storage system चाहिए ही होगा। मैं filenames से metadata हटाने की अकेली crusade छेड़े हुए हूँ

  • अब तक इस्तेमाल किए गए enterprise software में Confluence शायद सबसे धीमा था—शायद विशाल Jira को छोड़कर।
    PayPal में “Confluence का इंतज़ार कर रहा हूँ” एक मुहावरा बन गया था, जैसे “मेरा monorepo सभी dependencies डाउनलोड कर रहा है।” मोहल्ले के दूसरी तरफ़ वाले दस्तावेज़ के लोड होने का इंतज़ार करते हुए सड़क पार जाकर कॉफ़ी पीकर लौट आने जितना लंबा ब्रेक लिया जा सकता था। उस दस्तावेज़ को update करने की कोशिश तो की ही नहीं थी, इसलिए इससे बेहतर कुछ भी बेहतर ही होगा। यह लगभग अतिशयोक्ति नहीं है।

  • बहुत शानदार project है। सोच रहा हूँ कि इसे support करने का कोई तरीका है या नहीं।
    देखा कि documentation Docusaurus इस्तेमाल कर रहा है, लेकिन यहाँ Docmost को ही इस्तेमाल करना भी अच्छा होगा। इससे read-only ही सही, एक demo environment बन जाएगा और साथ ही खुद इस्तेमाल करके development करने का तरीका भी हो सकता है।