4 poin oleh GN⁺ 2024-06-30 | 3 komentar | Bagikan ke WhatsApp
  • Docmost adalah wiki kolaboratif open-source dan perangkat lunak dokumentasi, sebuah proyek untuk membantu tim menulis dan mengelola dokumen bersama
  • Fitur utamanya mencakup kolaborasi real-time, Spaces, manajemen izin, grup, komentar, riwayat halaman, pencarian, dan lampiran file
  • Dokumennya mencakup diagram berbasis Draw.io, Excalidraw, dan Mermaid, embed seperti Airtable·Loom·Miro, serta fitur terjemahan untuk lebih dari 10 bahasa
  • Untuk memulai, Anda dapat merujuk ke dokumentasi resmi atau mencoba versi cloud
  • Docmost core dilisensikan dengan AGPL 3.0, sementara fitur Enterprise dan file di direktori tertentu mengikuti lisensi Docmost Enterprise

Ikhtisar Docmost

Fitur kolaborasi dan dokumen

  • Mendukung Real-time collaboration
  • Memiliki fitur Spaces untuk membagi ruang dokumen
  • Menyediakan manajemen izin dan fitur grup
  • Mendukung komentar dan riwayat halaman
  • Mencakup fitur pencarian dan lampiran file

Diagram, embed, dan terjemahan

  • Fitur Diagrams mendukung Draw.io, Excalidraw, dan Mermaid
  • Embeds mencakup Airtable, Loom, Miro, dan lainnya
  • Terjemahan mendukung lebih dari 10 bahasa

Struktur lisensi

  • Docmost core disediakan sebagai open-source dengan lisensi AGPL 3.0
  • Fitur Enterprise disediakan di bawah lisensi enterprise Enterprise Edition
  • Semua file dalam direktori berikut mengikuti Docmost Enterprise license yang didefinisikan di packages/ee/License
    • apps/server/src/ee
    • apps/client/src/ee
    • packages/ee

Pengembangan dan ucapan terima kasih

  • Kontributor dapat merujuk ke development documentation
  • Crowdin menyediakan akses ke platform lokalisasi
  • Algolia menyediakan pencarian teks penuh untuk dokumentasi

3 komentar

 
nutella 2025-01-10

Di kantor, Notion tidak bisa dipakai dan Obsidian juga diblokir... Jadi saya ingin mencoba ini, dan sepertinya bisa menjadi alternatif yang bagus.

 
moderato 2024-10-10

Setelah mencobanya, ini alat yang dibuat dengan baik dan mirip dengan Notion.
Namun karena terlalu mirip dengan Notion, ada juga ketidaknyamanan pada titik-titik yang berbeda dari Notion.
Semoga bisa berkembang dengan baik.

 
GN⁺ 2024-06-30
Opini Hacker News
  • Aksesibilitas Notion dan Confluence sama-sama benar-benar menyedihkan
    Saya penasaran apakah bagian ini dipertimbangkan saat membuat Docmost. Mengingat ADA di AS dan EAA Uni Eropa yang akan segera berlaku, ini faktor yang cukup penting untuk adopsi perusahaan, dan kali ini saya berharap ada produk yang benar-benar mengerjakan PR aksesibilitasnya dengan baik. Kalau mau, saya bisa meninjaunya. Sebagai catatan, saya pengguna screen reader native, penyandang tunanetra, developer, dan auditor aksesibilitas

    • Kalau bagi orang dengan tangan dan mata yang umum saja begitu, bayangkan bagaimana bagi orang-orang dengan disabilitas
    • Aksesibilitas sudah dipikirkan
      Misalnya, tree halaman di sidebar mendukung navigasi keyboard. Library UI yang digunakan, Mantine, juga mengikuti praktik terbaik aksesibilitas dan menyediakan dukungan keyboard penuh. Masih banyak yang harus dikerjakan, tetapi dukungan akan terus bertambah seiring proyek berjalan. Dulu saya pernah membuat bot Twitter @threadvoice yang memungkinkan thread Twitter didengarkan sebagai audio, dan saat itu aksesibilitas juga menjadi salah satu motivasinya
      https://twitter.com/Philipofficial9/status/11899711858004869...
    • Autentikasi juga bermasalah. Di kedua situs itu, rasanya lebih baik kehilangan semuanya daripada harus melalui proses login ulang lagi
    • Kalau perusahaan sudah memakai Confluence dan Notion yang aksesibilitasnya seburuk ini, saya ragu seberapa penting hal ini sebenarnya bagi perusahaan
    • Memang penting, tetapi sepertinya bukan hal pertama yang akan saya selesaikan saat proyek baru saja dimulai
  • Sedikit masukan: saya ingin mencoba produknya, dan situs webnya juga rapi serta tampak menjanjikan, tetapi halaman instalasi membuat saya gentar sampai hampir pergi
    Instruksi pertama adalah instalasi Docker. Saya paham nama seksinya “Prerequisites”, tetapi kalau satu-satunya cara instalasi adalah Docker, saya mengharapkan kira-kira dokumen docker-compose dan variabel. “Installation Steps” juga dimulai dengan mkdir, cd, curl, vi, lalu akhirnya alurnya menjadi “gunakan docker-compose ini”. Prasyarat bisa penting bagi banyak orang, dan kalau ini dianggap masalah, ada banyak cara mengatasinya. Developer dan orang yang akrab dengan teknologi akan melewati semuanya dan langsung melihat perintah terminal atau kode. Jadi jangan menaruh bagian “jangan lakukan” terlalu atas di README repository, karena itulah bagian yang pertama kali akan kami salin-tempel. Ini bukan kritik, dan menurut saya produknya dibuat dengan sangat baik, tetapi ini masukan dari seorang eksperimen biasa yang mungkin saja hilang di halaman itu
    https://docmost.com/docs/installation

    • Sebaiknya instruksi instalasi Docker dihapus. Orang bisa melihatnya di dokumentasi Docker, dan tidak banyak alasan untuk menduplikasinya di tempat lain
      Selain itu, untuk manajemen environment variable, lebih baik memakai file .env daripada meminta orang mengubah file docker compose. Banyak orang kemungkinan besar akan memasukkan file yaml ke version control, jadi menaruh nilai rahasia dalam plaintext di sana bukan ide bagus
      https://docs.docker.com/compose/environment-variables/set-en...
    • Kalau ingin meningkatkan adopsi, menurut saya perlu menyediakan container all-in-one
      Pakai runit, masukkan database, redis, dan aplikasi ke container yang sama, lalu sediakan satu direktori data besar. Itu sudah cukup bagi sebagian besar tim kecil yang bisa menjalankan container, dan pengalaman “coba dulu” menjadi cukup docker run
  • Kami masih memakai Confluence on-premise di balik VPN. Untuk pindah, kami butuh ekspor PDF, editor diagram terintegrasi seperti Gliffy, serta histori dan diff
    Sejauh ini Outline yang paling mendekati, tetapi tidak mendesak, jadi saya juga akan mengikuti perkembangan proyek ini

    • XWiki SAS sedang membuat alat untuk migrasi dari Confluence ke XWiki
      XWiki adalah software wiki open source yang mulai dibuat sekitar waktu yang sama dengan Confluence, dan memiliki semua fitur yang disebutkan. Mereka juga menyediakan dukungan migrasi dan konsultasi, sementara alat migrasinya berusaha mempertahankan sebanyak mungkin konten dan fitur, serta sedang mengerjakan macro kompatibilitas. Kalau perlu, silakan hubungi
      https://xwiki.com
      http://xwiki.org
    • Menurut saya kebutuhan terbesar yang mudah terlewat saat datang dari Confluence adalah integrasi wiki dan dokumentasi kode
      Penting untuk menggabungkan wiki dengan dokumentasi yang dihasilkan dari codebase, seperti README kode, sphinx, mkdocs, dan swagger. Terkait editor diagram terintegrasi, jika distandardisasi dengan abstraksi dokumen-sebagai-kode seperti Mermaid atau Kroki, kita bisa memanfaatkan kode diagram yang bisa dibandingkan diff-nya dan berbagai editor open source. Ada beberapa implementasi juga dalam ekstensi VSCode, dan jika memilih Mermaid, diagram yang sama bisa berjalan bersama di tool wiki, GitHub, serta tool format konten publik local-first seperti Foam, Dendron, dan Obsidian.md, jadi itu bagus
    • Saya memakai Bookstack untuk keperluan ini dan bisa merekomendasikannya. Gratis dan open source
      Mendukung ekspor PDF, OAuth2, revisi, histori, izin akses, WYSIWYG/Markdown/diagram, dan lain-lain
      https://www.bookstackapp.com/
    • Ekspor PDF akan hadir
      Diagram juga akan hadir, dan berikutnya adalah MermaidJs. Penyedia diagram lain seperti Draw.io dan Excalidraw bisa ditambahkan setelah kami merapikan cara menyimpan dan mengambil data sumber secara efisien. Histori halaman didukung, tetapi belum ada diff
    • Saya belum pernah memakainya di Confluence, tetapi https://www.tldraw.com/ setidaknya bisa di-embed di Notion dan bekerja sangat baik sebagai editor diagram
  • Di perusahaan kami sedang mengevaluasi alat dokumentasi, tetapi karena lingkungan regulasinya agak khusus, orang yang membuat dokumen berbeda dari orang yang meninjau dan menyetujuinya
    Karena itu, konsep merge request untuk dokumen bisa menjadi fitur pembeda. Caranya, seseorang membuat dokumen, orang lain mengubahnya, lalu mengajukan perubahan tersebut sebagai permintaan peninjauan. GitBook punya ini, tetapi bagian inti lainnya kurang memadai bagi kami

    • Saya sudah menginginkan ini sejak lama, tetapi setelah dipikir-pikir, saya jadi lebih memilih memakai Git saja dan mendorong dokumen Markdown ke Notes System
      Saya tidak ingin sistem lain menangani penyuntingan, review, dan merge. Saya hanya ingin mengirim dokumen dari Git, lalu melakukan continuous deployment ke sistem yang meng-hosting fitur-fitur terkait dokumen yang dibutuhkan dengan baik
    • Sepertinya akan menjadi fitur yang bagus. Kami punya masalah serupa: ada versi dokumentasi resmi yang sudah melalui proses peninjauan, dan untuk mengerjakan versi berikutnya di Confluence kami harus membuat halaman kerja terpisah
      Akibatnya hasil pencarian tercemar dan cepat menjadi berantakan
    • Kalau merge request dokumen adalah kebutuhan utama, saya penasaran fitur lain apa yang tidak cukup dipenuhi oleh Git atau sistem version control lain
    • Ini akan menjadi fitur yang sangat bagus jika ada
  • Saya sangat menyukai wiki dan cara-cara tertentu wiki digunakan di dalam perusahaan
    Namun saya tidak terlalu menyukai sebagian produk perangkat lunak wiki yang tampaknya terdorong oleh penjualan enterprise kepada pelanggan yang tidak memahami wiki. Salah satu hal yang cukup berhasil dilakukan oleh sebuah produk enterprise adalah integrasi alat menggambar. Tidak semua orang di perusahaan membutuhkan integrasi ini, tetapi sebagian pengguna membutuhkannya, dan berkat itu materi visual yang sangat berguna—yang kalau tidak ada fitur tersebut mungkin tidak akan terdokumentasi—bisa terekam

    • https://www.tldraw.com/ setidaknya bisa di-embed secara live di Notion, sehingga menyediakan fitur menggambar kolaboratif yang cukup baik bahkan di dalam wiki yang pada dasarnya tidak mendukung fitur seperti itu. Saya belum mencobanya di Confluence atau alat lain
    • Saya penasaran apakah Anda bisa merangkum beberapa inti kebijaksanaan tentang mengapa Anda menyukai wiki. Khususnya, saya ingin tahu pola penggunaan seperti apa yang paling efektif di dalam perusahaan
  • Masalah terbesar pada kebanyakan perangkat lunak dokumentasi ada dua
    Pertama, semuanya terkunci di dalamnya. Catatan harus bisa diekspor atau dicadangkan dengan mudah. Kedua, kebijakan harganya terasa terlalu memeras dalam hal-hal kecil. Misalnya harus naik paket kalau node di pohon dokumen melebihi 100, atau setiap kali menambahkan orang ke proyek menjadi keputusan pembelian, yang melelahkan. Akan bagus kalau Anda bisa menjelaskan lebih lanjut bagaimana Postgres dan Redis digunakan

    • Postgres adalah database utama yang menyimpan semua data terkait workspace dan pengguna
      Redis digunakan untuk antrean, sinkronisasi status editor kolaboratif antar-server, dan sinkronisasi WebSocket antar-server. Dua fungsi terakhir penting saat menjalankan software di beberapa node atau replika
  • Saya bekerja di XWiki. Senang melihat rekan-rekan membuat alternatif open source, dan semakin banyak upaya seperti ini semakin baik
    Membuat sesuatu yang sebanding dengan Confluence membutuhkan pekerjaan yang sangat banyak, dan XWiki sudah berada di ranah ini sejak masa awal. Saya penasaran bagaimana Anda memposisikan Docmost dibandingkan XWiki, dan mengapa memilih untuk tidak bergabung tenaga
    https://xwiki.org

    • Saya pernah mencoba XWiki karena ingin pindah dari Confluence ke sesuatu yang open source, tetapi pengalaman penggunanya terasa relatif kasar
      Saya penasaran apakah ada kumpulan ekstensi yang direkomendasikan yang membuatnya lebih bisa diterima bagi orang yang menginginkan pengalaman seperti Confluence
  • Akan menyenangkan kalau fitur-fitur seperti ini ada
    Saya ingin bisa memakai editor pilihan sendiri untuk mengelola halaman sebagai teks biasa di Git atau sistem version control lain, dan bisa commit halaman tanpa melalui browser. Halaman bisa ditulis dalam bahasa markup apa pun; karena Markdown kurang ekspresif di beberapa area, halaman sederhana bisa dikenali sebagai Markdown lewat ekstensi file, sementara wiki juga sebaiknya mengizinkan format yang lebih kuat dan bisa diperluas pengguna seperti reStructuredText. Selain itu, halaman sebaiknya dirender di sisi server dan mudah di-cache. Jika halaman berupa file, validitas cache bisa dicek dengan mudah melalui hash sha, sehingga dapat ditampilkan nyaris seketika, tidak seperti Confluence yang lambat dan buruk

    • Bukan kasus penggunaan yang persis sama, tetapi saya sangat nyaman memakai https://nextra.site/ untuk membuat situs dokumentasi statis sebuah proyek
      Ia menjaga keseimbangan yang bagus: sebagian besar cukup memakai Markdown biasa, tetapi saat diperlukan bisa turun ke komponen React. Dengan pola merge ke main lalu continuous deployment ke GitHub Pages, pengalamannya cukup bagus
    • Kalau menulis dokumen Markdown di luar browser dan mengelolanya dengan Git, saya tidak paham mengapa alat seperti ini diperlukan. Rasanya itu justru menggugurkan tujuannya sendiri
      Atau apakah maksudnya ingin mengunggah dokumen dengan workflow yang ramah developer, lalu anggota tim non-developer lainnya tinggal membacanya? Secara umum saya melihat ini benar-benar ide buruk. Jika Anda melempar MVP self-hosted yang mungkin banyak bug ke tim, sementara Anda sendiri tidak memakai lapisan UI yang dipakai semua orang, itu kombinasi yang akan memicu penolakan dan pergantian alat. Saya sudah sering melihat founder teknis melakukan kesalahan ini. Hal yang sama terjadi pada CMS situs web marketing: mereka sadar static site + Markdown + Git tidak bisa diskalakan ke non-developer, lalu mengetahui bahwa headless CMS yang tidak mereka pakai sendiri ternyata buruk untuk penggunaan harian
    • Di perusahaan, kami memakai Jekyll untuk keperluan ini, membangun situs dengan GitHub Actions, lalu meng-hosting-nya di GitHub Pages
      Ini bekerja sangat baik dan juga mendukung diagram Mermaid, MathML, dan lain-lain
    • Saya penasaran apakah Anda pernah melihat MyST. Ekspresifnya setara ReST, dan menurut saya pribadi jauh lebih mudah digunakan
    • Satu suara lagi menentang Markdown
      Markdown baik untuk dokumen sederhana, tetapi sangat lemah untuk wiki yang tautan antarhalamannya menjadi inti. Secara pribadi, menurut saya markup Creole jauh lebih baik untuk menulis wiki. Sebaiknya jangan menyimpan format file di ekstensi; metadata lebih baik disimpan sebagai metadata yang benar. Aplikasi kemungkinan besar pada akhirnya ingin memiliki jauh lebih banyak metadata, sehingga pada akhirnya tetap membutuhkan sistem penyimpanan metadata. Saya menganggap diri saya pejuang yang kesepian untuk menghapus metadata dari nama file
  • Confluence adalah salah satu software enterprise paling lambat yang pernah saya pakai sejauh ini—mungkin selain Jira yang raksasa itu.
    Di PayPal, “menunggu Confluence” sudah jadi ungkapan seperti “monorepo saya sedang mengunduh semua dependency”. Saking lamanya menunggu dokumen dari ujung lain kantor dimuat, rasanya cukup untuk istirahat panjang, menyeberang jalan, lalu minum kopi. Itu pun saya belum mencoba memperbarui dokumennya, jadi apa pun yang lebih baik dari ini jelas lebih baik. Ini hampir bukan hiperbola.

  • Proyek yang sangat keren. Saya penasaran apakah ada cara untuk mensponsorinya.
    Saya juga melihat dokumentasinya memakai Docusaurus, tapi sepertinya bagus juga kalau menggunakan Docmost itu sendiri di sana. Dengan begitu, meski hanya read-only, ia bisa menjadi lingkungan demo sekaligus cara pengembangan dengan memakainya langsung.