Show HN: I am building an open-source Confluence and Notion alternative

Original Article ↗ Hacker News Discussion ↗

Project scope and positioning

  • Many welcome a Confluence/Notion alternative, especially due to Confluence slowness and Notion lock‑in/pricing.
  • Some compare to existing open tools (Outline, XWiki, Bookstack, MediaWiki, Nextcloud, Obsidian, SiYuan, Anytype, Affine).
  • Questions raised about why build new instead of extending XWiki/MediaWiki; others argue architecture and UX are too different.
  • License choice (AGPL) praised for promoting copyleft; minor debate over “open source vs free software” framing.

Collaboration, versioning, and workflows

  • Strong interest in Git‑like workflows: merge requests for docs, git‑backed markdown storage, docs-as-code, staging/approval flows, and official vs working versions.
  • Some want plain‑text storage with rich editor abstraction so the “wiki is just a repo,” but others doubt git+markdown scales for multi‑user real‑time editing or advanced features.
  • Real‑time collaboration is seen as a differentiator compared with many note tools.

Performance, storage, and DB architecture

  • Deep critique of using Postgres to store large, frequently updated Yjs content: TOAST overhead, WAL amplification, full‑text search costs, and GIN index maintenance.
  • Suggestions: store large blobs in object/LSM stores with DB pointers, tune Postgres, optimize column order, remove redundant indexes.
  • Counterpoint: this may be premature optimization for typical self‑hosted usage; can be revisited for a future cloud scale‑out.

Offline, mobile, and real-time use

  • Some users highly value offline‑first and mobile‑first (a known Notion gap); current project has no offline‑first plan and only future, non‑priority mobile apps.
  • Real‑time collab relies on Yjs + Hocuspocus; some report Yjs is now production‑ready.

Accessibility and usability

  • Multiple comments stress poor accessibility in Notion/Confluence and urge building a11y in from the start (keyboard navigation, screen‑reader support, color/contrast).
  • Debate on when to prioritize accessibility: some say not top priority early; others argue deferring it is effectively choosing inaccessibility and makes retrofitting costly.
  • Suggestions include hiring or consulting disabled testers, avoiding over‑custom UI components, and using semantic HTML/ARIA.

Diagrams, markdown, and content formats

  • Strong demand for diagrams: PlantUML, Mermaid, draw.io/Gliffy/Lucid, Excalidraw, tldraw; both diagrams‑as‑code and visual editors.
  • Project plans Mermaid first, possibly other tools later; concerns about how to store raw diagram data efficiently.
  • Many want markdown editing support, fenced code blocks, and robust exports (HTML/Markdown/PDF) plus backup/restore tooling.
  • Some argue markdown is too limited for complex docs and suggest richer syntaxes (reStructuredText, MyST, org‑mode, Creole).

Deployment, self‑hosting, and SaaS

  • Installation via Docker works but docs are seen as intimidating and slightly confusing (docker vs docker‑compose, APP_URL, env handling).
  • Suggestions: simplify to a one‑command demo container, rely on official Docker docs for Docker install, move secrets into .env.
  • Some organizations require self‑hosting for regulatory reasons; others prefer SaaS to reduce operational burden.
  • Author indicates intent to keep Postgres/Redis and later offer a cloud‑hosted version; self‑hosting remains first focus.

Authentication and enterprise features

  • Requests for SSO/OIDC/SAML, Azure AD (EntraID), Keycloak, and reverse‑proxy header auth.
  • Demand for staging/approval workflows, history with diffs, and better handling of stale/ownerless documentation.