Docmost - ซอฟต์แวร์เอกสารและวิกิสำหรับการทำงานร่วมกันแบบโอเพนซอร์ส คล้ายกับ Confluence และ Notion

• Docmost เป็นโปรเจ็กต์ วิกิและซอฟต์แวร์จัดทำเอกสารสำหรับการทำงานร่วมกันแบบโอเพนซอร์ส ที่ออกแบบมาสำหรับให้ทีมเขียนและจัดการเอกสารร่วมกัน
• ฟีเจอร์หลักประกอบด้วย การทำงานร่วมกันแบบเรียลไทม์, Spaces, การจัดการสิทธิ์, กลุ่ม, ความคิดเห็น, ประวัติหน้า, การค้นหา และการแนบไฟล์
• ภายในเอกสารรองรับ ไดอะแกรม ที่ทำงานบน Draw.io, Excalidraw, Mermaid รวมถึงการฝัง Airtable, Loom, Miro และรองรับการแปลมากกว่า 10 ภาษา
• หากต้องการเริ่มต้น สามารถดู เอกสาร อย่างเป็นทางการหรือทดลองใช้เวอร์ชันคลาวด์ได้
• Docmost core ใช้ไลเซนส์ AGPL 3.0 ส่วนฟีเจอร์ Enterprise และไฟล์ในไดเรกทอรีที่กำหนดจะอยู่ภายใต้ไลเซนส์ Docmost Enterprise

---

ภาพรวมของ Docmost

• Docmost คือวิกิและซอฟต์แวร์จัดทำเอกสารสำหรับการทำงานร่วมกันแบบโอเพนซอร์ส
• โปรเจ็กต์มี 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
• ไฟล์ทั้งหมดในไดเรกทอรีต่อไปนี้อยู่ภายใต้ Docmost Enterprise license ตามที่กำหนดไว้ใน packages/ee/License
  • apps/server/src/ee
  • apps/client/src/ee
  • packages/ee

การพัฒนาและการระบุเครดิต

• ผู้มีส่วนร่วมสามารถดู development documentation
• Crowdin ให้การเข้าถึงแพลตฟอร์มการแปลเป็นภาษาท้องถิ่น
• Algolia ให้บริการค้นหาข้อความแบบเต็มสำหรับเอกสาร

[nutella]

ที่บริษัทใช้ Notion ไม่ได้และ Obsidian ก็ถูกบล็อกด้วย... เลยว่าจะลองใช้ดู น่าจะเป็นทางเลือกที่ดีได้เหมือนกัน

[moderato]

พอลองใช้ดูแล้วเป็นเครื่องมือที่ทำออกมาได้ดี คล้ายกับ Notion
แต่เพราะมันคล้ายกับ Notion มากเกินไป ก็เลยมีจุดที่ใช้งานไม่สะดวกเมื่อเทียบกับสิ่งที่ Notion ทำต่างออกไปอยู่บ้าง
หวังว่าจะพัฒนาต่อไปได้ดี

[GN⁺]

ความคิดเห็นจาก Hacker News

• การเข้าถึง (accessibility) ของ Notion และ Confluence นั้นแย่มากทั้งคู่จริง ๆ
  อยากรู้ว่าตอนสร้าง Docmost ได้คำนึงถึงส่วนนี้หรือไม่ เมื่อคิดถึง ADA ของสหรัฐฯ และ EAA ของสหภาพยุโรปที่กำลังจะมีผลบังคับใช้ นี่เป็นปัจจัยที่ค่อนข้างสำคัญสำหรับการนำไปใช้ในองค์กร และครั้งนี้ก็อยากให้มีผลิตภัณฑ์ที่ทำการบ้านเรื่อง accessibility มาอย่างเหมาะสม ถ้าต้องการ ผม/ฉันช่วยรีวิวให้ได้ อนึ่ง ผม/ฉันเป็นผู้ใช้ screen reader แบบเนทีฟ เป็นผู้พิการทางสายตา นักพัฒนา และผู้ตรวจประเมิน accessibility

  • ถ้าสำหรับคนที่มีมือและตาทั่วไปยังเป็นแบบนั้น ลองจินตนาการดูว่าจะเป็นอย่างไรสำหรับ ผู้ที่มีความพิการ
  • เคยคิดเรื่อง accessibility ไว้แล้ว
    ตัวอย่างเช่น tree ของหน้าใน sidebar รองรับ การนำทางด้วยคีย์บอร์ด ไลบรารี UI ที่ใช้คือ Mantine ก็ปฏิบัติตามแนวทางปฏิบัติที่ดีด้าน accessibility และให้การรองรับคีย์บอร์ดครบถ้วน ยังมีงานที่ต้องทำอีกมาก แต่เมื่อโปรเจกต์เดินหน้าต่อไป การรองรับจะเพิ่มขึ้น เคยสร้างบอต Twitter ชื่อ @threadvoice ที่ทำให้ฟังเธรด Twitter เป็นเสียงได้ และตอนนั้น accessibility ก็เป็นหนึ่งในแรงจูงใจด้วย
    https://twitter.com/Philipofficial9/status/11899711858004869...
  • การยืนยันตัวตนก็เป็นปัญหาเหมือนกัน รู้สึกว่ายอมเสียทุกอย่างไปเลยยังดีกว่าต้องผ่านขั้นตอนล็อกอินใหม่ในสองไซต์นี้
  • ถ้าองค์กรต่าง ๆ ใช้ Confluence และ Notion ที่ทำ accessibility ได้แย่ขนาดนี้อยู่แล้ว ก็ชวนสงสัยว่าในทางปฏิบัติเรื่องนี้สำคัญกับองค์กรแค่ไหนกันแน่
  • สำคัญก็จริง แต่คงไม่วางไว้เป็นรายการแรกสุดที่ต้องแก้ตอนเพิ่งเริ่มโปรเจกต์

• ขอ feedback เล็กน้อย ผม/ฉันอยากลองใช้ผลิตภัณฑ์นี้ และเว็บไซต์ก็ดูสะอาดตาและมีอนาคต แต่ หน้าติดตั้ง ทำให้รู้สึกน่ากลัวจนเกือบออกไปแล้ว
  คำสั่งแรกคือการติดตั้ง Docker ซึ่งเข้าใจว่า section ชื่อ “Prerequisites” แต่ถ้าวิธีติดตั้งมีแค่ Docker ก็จะคาดหวังเอกสารประมาณ docker-compose กับตัวแปรต่าง ๆ มากกว่า “Installation Steps” ก็เริ่มด้วย mkdir, cd, curl, vi แล้วสุดท้ายก็ไหลไปสู่ “ให้ใช้ docker-compose นี้” เงื่อนไขตั้งต้นอาจสำคัญกับคนจำนวนมาก และถ้ามองว่านี่เป็นปัญหา ก็มีหลายวิธีแก้ นักพัฒนาและคนที่คุ้นกับเทคโนโลยีมักข้ามทุกอย่างแล้วดูคำสั่งเทอร์มินัลหรือโค้ดก่อน ดังนั้นไม่ควรใส่สิ่งที่ “ห้ามทำ” ไว้สูงเกินไปที่ด้านบนของ README ใน repo เพราะมันจะกลายเป็นส่วนแรกที่พวกเราคัดลอกไปวาง นี่ไม่ใช่คำวิจารณ์นะ ดูเหมือนทำมาได้ดีมาก แต่เป็น feedback จากคนทดลองทั่วไปที่คุณอาจเสียไปได้จากหน้านั้น
  https://docmost.com/docs/installation

  • น่าจะเอาคำแนะนำการติดตั้ง Docker ออก คนดูได้จากเอกสาร Docker อยู่แล้ว และไม่มีเหตุผลมากนักที่จะใส่ซ้ำไว้ที่อื่น
    อีกอย่าง การจัดการ environment variables ควรใช้ ไฟล์ .env มากกว่าให้แก้ไฟล์ docker compose หลายคนมีโอกาสจะเอาไฟล์ yaml เข้าระบบ version control ดังนั้นการใส่ secret เป็นข้อความธรรมดาไว้ในนั้นไม่ใช่ความคิดที่ดี
    https://docs.docker.com/compose/environment-variables/set-en...
  • ถ้าอยากเพิ่มการนำไปใช้ ผม/ฉันคิดว่าควรมี คอนเทนเนอร์แบบ all-in-one
    ใช้ runit แล้วใส่ database, redis และ app ไว้ในคอนเทนเนอร์เดียวกัน จากนั้นมีไดเรกทอรีข้อมูลขนาดใหญ่หนึ่งอัน สำหรับทีมเล็กส่วนใหญ่ที่รันคอนเทนเนอร์ได้ แค่นั้นก็น่าจะพอ และประสบการณ์ “ลองใช้ดูสักครั้ง” ก็จะกลายเป็นแค่ docker run

• ยังใช้ Confluence on-premises อยู่หลัง VPN ถ้าจะย้าย ต้องมีการ export เป็น PDF, ตัวแก้ไขไดอะแกรมแบบผสานรวมอย่าง Gliffy, history และ diff
  จนถึงตอนนี้ Outline ใกล้เคียงที่สุด แต่ไม่ได้รีบร้อน เลยจะคอยดูการพัฒนาของโปรเจกต์นี้ต่อไป

  • XWiki SAS กำลังทำเครื่องมือสำหรับย้ายจาก Confluence ไป XWiki
    XWiki เป็นซอฟต์แวร์วิกิโอเพนซอร์สที่เริ่มมาในช่วงเวลาใกล้เคียงกับ Confluence และมีฟีเจอร์ทั้งหมดที่กล่าวถึง นอกจากนี้ยังให้บริการสนับสนุนการ migration และ consulting ด้วย โดยเครื่องมือย้ายข้อมูลพยายามคงเนื้อหาและฟีเจอร์ไว้ให้มากที่สุด และกำลังทำ compatibility macros อยู่ หากต้องการก็ติดต่อได้
    https://xwiki.com
    http://xwiki.org
  • ความต้องการที่มักพลาดได้ง่ายที่สุดเมื่อมาจากฝั่ง Confluence น่าจะเป็น การรวมวิกิกับเอกสารโค้ด
    การผูกเอกสารที่สร้างจาก codebase เช่น README ของโค้ด, sphinx, mkdocs, swagger เข้ากับวิกิเป็นเรื่องสำคัญ สำหรับตัวแก้ไขไดอะแกรมแบบผสานรวม ถ้าทำให้เป็นมาตรฐานด้วย abstraction แบบ document-as-code อย่าง Mermaid หรือ Kroki ก็จะใช้โค้ดไดอะแกรมที่เปรียบเทียบ diff ได้และตัวแก้ไขโอเพนซอร์สหลายตัวได้ มี implementation หลายแบบใน VSCode extension ด้วย และถ้าเลือก Mermaid ก็จะดีตรงที่ไดอะแกรมเดียวกันทำงานร่วมกันได้ทั้งในเครื่องมือวิกิ, GitHub และเครื่องมือรูปแบบเนื้อหาสาธารณะแบบ local-first อย่าง Foam, Dendron, Obsidian.md
  • ใช้ Bookstack สำหรับงานนี้อยู่ และแนะนำได้ เป็นโอเพนซอร์สฟรี
    รองรับการ export เป็น PDF, OAuth2, revisions, history, permissions, WYSIWYG/Markdown/ไดอะแกรม ฯลฯ
    https://www.bookstackapp.com/
  • จะมีการ export เป็น PDF ตามมา
    ไดอะแกรมก็จะมีตามมาเช่นกัน และลำดับถัดไปคือ MermaidJs ส่วนผู้ให้บริการไดอะแกรมอื่น ๆ อย่าง Draw.io และ Excalidraw จะเพิ่มได้หลังจากจัดการวิธีบันทึกและนำเข้าข้อมูลต้นฉบับอย่างมีประสิทธิภาพแล้ว รองรับ page history แต่ยังไม่มี การเปรียบเทียบ diff
  • ยังไม่เคยใช้กับ Confluence แต่ https://www.tldraw.com/ อย่างน้อยก็ embed ใน Notion ได้ และทำงานเป็น ตัวแก้ไขไดอะแกรม ได้ดีมาก

• ที่บริษัทกำลังประเมินเครื่องมือเอกสารอยู่ แต่สภาพแวดล้อมด้านกฎระเบียบค่อนข้างเฉพาะ ทำให้คนที่สร้างเอกสารกับคนที่ตรวจทาน·อนุมัติเป็นคนละคนกัน
  ด้วยเหตุนี้ แนวคิด merge request สำหรับเอกสาร อาจกลายเป็นฟีเจอร์ที่สร้างความแตกต่างได้ คือให้ใครสักคนสร้างเอกสาร อีกคนแก้ไข แล้วส่งการเปลี่ยนแปลงเป็นคำขอให้ตรวจทาน GitBook มีฟีเจอร์นี้ แต่ส่วนสำคัญอื่น ๆ ยังไม่เพียงพอสำหรับเรา

  • อยากได้สิ่งนี้มานานแล้ว แต่พอคิดดูให้ดี ก็เริ่มชอบวิธีใช้ Git แล้ว push เอกสาร Markdown ไปยัง Notes System มากกว่า
    ไม่อยากให้ระบบอื่นจัดการการแก้ไข การรีวิว และการ merge อยากส่งเอกสารจาก Git แล้วทำ continuous deployment ไปยังระบบที่โฮสต์ฟีเจอร์เกี่ยวกับเอกสารที่จำเป็นได้ดีเท่านั้น
  • น่าจะเป็นฟีเจอร์ที่ยอดเยี่ยม มีปัญหาคล้ายกันอยู่ คือมีเวอร์ชันเอกสารทางการที่ผ่านกระบวนการตรวจทานแล้ว และถ้าจะทำงานกับเวอร์ชันถัดไปใน Confluence ก็ต้องสร้างหน้าสำหรับทำงานแยกต่างหาก
    แบบนั้นทำให้ผลการค้นหาปนเปื้อน และรกขึ้นอย่างรวดเร็ว
  • ถ้า merge request สำหรับเอกสารเป็นความต้องการหลัก ก็สงสัยว่ามีฟีเจอร์อื่นอะไรที่ Git หรือ ระบบควบคุมเวอร์ชัน อื่น ๆ ยังไม่เพียงพอ
  • ถ้ามีก็คงดีมากจริง ๆ

• ชอบวิกิและวิธีใช้วิกิแบบเฉพาะบางอย่างภายในบริษัทมาก
  แต่ไม่ได้ชอบซอฟต์แวร์วิกิบางตัวที่ดูเหมือนถูกขับเคลื่อนด้วยการขายองค์กรให้ลูกค้าที่ไม่เข้าใจวิกิมากนัก สิ่งหนึ่งที่ผลิตภัณฑ์สำหรับองค์กรบางตัวทำได้ค่อนข้างดีคือ การผสานรวมเครื่องมือวาดภาพ ไม่ใช่ทุกคนในบริษัทที่ต้องการการผสานนี้ แต่ผู้ใช้บางส่วนต้องการ และเพราะสิ่งนี้จึงสามารถบันทึกสื่อภาพที่มีประโยชน์มาก ๆ ซึ่งถ้าไม่มีฟีเจอร์นี้ก็คงไม่ถูกเก็บไว้

  • https://www.tldraw.com/ อย่างน้อยก็ฝังแบบ live embed ใน Notion ได้ จึงให้ฟีเจอร์ วาดร่วมกัน ที่ค่อนข้างดี แม้อยู่ในวิกิที่เดิมทีไม่ได้รองรับฟีเจอร์แบบนั้น ยังไม่เคยลองกับ Confluence หรือเครื่องมืออื่น ๆ
  • อยากรู้ว่าสามารถสรุปแก่นสำคัญบางอย่างว่าทำไมถึงชอบวิกิได้ไหม โดยเฉพาะอยากรู้ว่าวิธีใช้งานแบบไหนภายในบริษัทที่ได้ผลดีที่สุด

• ปัญหาใหญ่ที่สุดของซอฟต์แวร์เอกสารส่วนใหญ่มีสองข้อ
  ข้อแรก ทุกอย่างถูกกักอยู่ในระบบ ควรส่งออกหรือสำรองโน้ตได้ง่าย ข้อสอง นโยบายราคาดูเหมือนคิดเงินจุกจิกเกินไป เช่น ถ้า node ใน document tree เกิน 100 ก็ให้ขยับแผนราคา หรือทุกครั้งที่เพิ่มคนเข้าโปรเจกต์ก็กลายเป็นการตัดสินใจซื้อจนเหนื่อย ถ้าอธิบายเพิ่มเติมได้ว่าใช้ Postgres และ Redis อย่างไร ก็คงดี

  • Postgres เป็น ฐานข้อมูลหลัก สำหรับเก็บข้อมูลทั้งหมดที่เกี่ยวกับ workspace และผู้ใช้
    Redis ใช้สำหรับคิว การซิงค์สถานะ editor แบบร่วมแก้ไขระหว่างเซิร์ฟเวอร์ และการซิงค์ WebSocket ระหว่างเซิร์ฟเวอร์ ฟีเจอร์สองอย่างหลังสำคัญเมื่อรันซอฟต์แวร์บนหลาย node หรือหลาย replica

• ทำงานอยู่ที่ XWiki ดีใจที่เห็นเพื่อนร่วมวงการทำทางเลือกแบบโอเพนซอร์ส และยิ่งมีความพยายามแบบนี้มากเท่าไรก็ยิ่งดี
  การสร้างสิ่งที่เทียบชั้น Confluence ได้ต้องใช้ความพยายามมากจริง ๆ และ XWiki ก็อยู่ในพื้นที่นี้มาตั้งแต่ยุคแรก ๆ อยากรู้ว่า Docmost วางตำแหน่งตัวเองอย่างไรเมื่อเทียบกับ XWiki และเหตุผลที่ไม่ร่วมแรงกันคืออะไร
  https://xwiki.org

  • เคยลองใช้ XWiki เพราะอยากย้ายจาก Confluence ไปหาอะไรสักอย่างที่เป็นโอเพนซอร์ส แต่ประสบการณ์ผู้ใช้รู้สึกค่อนข้างขรุขระกว่า
    อยากรู้ว่ามีชุด extension ที่แนะนำซึ่งทำให้คนที่ต้องการ ประสบการณ์แบบ Confluence ยอมรับได้มากขึ้นหรือไม่

• ถ้ามีฟีเจอร์เหล่านี้ก็คงดี
  อยากใช้ editor ที่ต้องการเพื่อจัดการหน้าเป็น plain text ใน Git หรือระบบควบคุมเวอร์ชันอื่น และ commit หน้าได้โดยไม่ต้องผ่านเบราว์เซอร์ หน้าอาจเขียนด้วยภาษา markup ใดก็ได้ แต่เพราะ Markdown ขาดพลังในการสื่อความหมายในบางด้าน จึงอยากให้หน้าธรรมดาระบุได้ด้วยนามสกุลไฟล์ว่าเป็น Markdown และให้วิกิรองรับรูปแบบที่ทรงพลังกว่าและผู้ใช้ขยายได้ เช่น reStructuredText ด้วย นอกจากนี้อยากให้ render หน้าในฝั่งเซิร์ฟเวอร์และ cache ได้ง่าย ถ้าหน้าเป็นไฟล์ ก็ตรวจสอบความถูกต้องของ cache ด้วยค่า sha sum ได้ง่าย ทำให้แสดงผลแทบจะทันที ต่างจาก Confluence ที่ช้าและแย่

  • ไม่ใช่ use case เดียวกันทั้งหมด แต่ใช้ https://nextra.site/ ได้ดีมากในการทำไซต์เอกสารแบบ static ของโปรเจกต์หนึ่ง
    มันทำสมดุลได้ดี คือส่วนใหญ่ให้ใช้ Markdown ปกติได้ แต่เมื่อจำเป็นก็ลงไปใช้ React component ได้ ถ้า merge เข้า main แล้ว continuous deploy ไปยัง GitHub Pages ก็เป็นประสบการณ์ที่ค่อนข้างดี
  • ถ้าเขียนเอกสาร Markdown นอกเบราว์เซอร์แล้ว version control ด้วย Git ก็ไม่รู้ว่าทำไมถึงต้องมีเครื่องมือแบบนี้ ดูเหมือนทำลายจุดประสงค์ของมันเองไม่ใช่หรือ
    หรืออยากเอาเอกสารขึ้นด้วย workflow ที่เป็นมิตรกับนักพัฒนา แล้วให้สมาชิกทีมที่เหลือซึ่งไม่ใช่นักพัฒนาดูหรือเปล่า โดยทั่วไปคิดว่าเป็นไอเดียที่แย่มาก ถ้าเอา MVP ที่โฮสต์เองและน่าจะมีบั๊กเยอะไปโยนให้ทีม แต่ตัวเองกลับไม่จัดการชั้น UI ที่ทุกคนใช้ ก็เป็นสูตรสำเร็จให้เกิดแรงต้านและการเปลี่ยนเครื่องมือ เห็นผู้ก่อตั้งสายเทคนิคทำพลาดแบบนี้บ่อยมาก เรื่องเดียวกันเกิดกับ CMS สำหรับเว็บการตลาดด้วย คือพอรู้ว่า static site + Markdown + Git ขยายไปถึงผู้ใช้ที่ไม่ใช่นักพัฒนาไม่ได้ ก็พบว่า headless CMS ที่ตัวเองไม่ได้ใช้กลับแย่มากในการใช้งานประจำวัน
  • ที่บริษัทใช้ Jekyll เพื่อจุดประสงค์นี้ โดย build site ด้วย GitHub Actions แล้วโฮสต์บน GitHub Pages
    ทำงานได้ดีมาก และรองรับ Mermaid diagram, MathML ฯลฯ ด้วย
  • เคยเห็น MyST ไหม อยากรู้ว่า มันสื่อความหมายได้ดีพอ ๆ กับ ReST และโดยส่วนตัวคิดว่าใช้ง่ายกว่ามาก
  • ขอโหวตค้าน Markdown อีกเสียง
    Markdown ใช้กับเอกสารเรียบง่ายได้ดี แต่สำหรับวิกิที่การลิงก์ระหว่างหน้าเป็นแกนหลักนั้นอ่อนมาก โดยส่วนตัวคิดว่า markup แบบ Creole ดีกว่ามากสำหรับการเขียนวิกิ ไม่ควรเก็บรูปแบบไฟล์ไว้ในนามสกุลไฟล์ และ metadata ก็ควรเก็บเป็น metadata อย่างถูกต้อง มีโอกาสสูงที่แอปพลิเคชันจะอยากมี metadata มากกว่านั้นมากอยู่แล้ว สุดท้ายก็ต้องมีระบบจัดเก็บ metadata อยู่ดี กำลังรับบทนักรณรงค์ผู้โดดเดี่ยวเพื่อเอา metadata ออกจากชื่อไฟล์

• Confluence เป็นซอฟต์แวร์สำหรับองค์กรที่ช้าที่สุดเท่าที่เคยใช้มา บางทีอาจเป็นรองแค่ Jira ตัวมหึมาเท่านั้น
  ที่ PayPal คำว่า “กำลังรอ Confluence” กลายเป็นสำนวนติดปากแบบเดียวกับ “โมโนเรโปของฉันกำลังดาวน์โหลด dependency ทั้งหมดอยู่” ถึงขั้นพักยาว เดินข้ามถนนไปซื้อกาแฟดื่มระหว่างรอเอกสารจากอีกฟากของเมืองโหลดเสร็จได้เลย ยังไม่ทันได้ลองอัปเดตเอกสารนั้นด้วยซ้ำ ดังนั้นอะไรก็ตามที่ดีกว่านี้ก็ดีกว่ามากแล้ว แทบไม่ได้พูดเกินจริงเลย

• เป็นโปรเจกต์ที่เจ๋งมาก สงสัยว่ามีวิธีสนับสนุนไหม
  เห็นว่าเอกสารใช้ Docusaurus อยู่ด้วย แต่คิดว่าถ้า ใช้ Docmost เอง ตรงนี้ก็น่าจะดี เพราะอย่างน้อยก็จะกลายเป็นสภาพแวดล้อมเดโมแบบอ่านอย่างเดียวได้ และในขณะเดียวกันก็เป็นแนวทางพัฒนาแบบลองใช้เองจริงด้วย