HN Debrief

Show HN: OpenKnowledge – open source AI-first alternative to Obsidian/Notion

  • AI
  • Open Source
  • Developer Tools
  • Knowledge Management
  • Collaboration

OpenKnowledge is an open source app for editing and sharing markdown knowledge bases with a polished rich-text editor, Git-backed sync, and integrations aimed at desktop AI agents. The launch post pitches it as a Notion-like experience on top of local markdown files, with a macOS app plus web UI and command line interface, built-in Model Context Protocol servers and skills, and a sync and sharing model that uses GitHub under the hood instead of a proprietary document store. The technical hook is a bidirectional pipeline between a ProseMirror rich-text editor and byte-faithful markdown, plus conflict handling with Conflict-free Replicated Data Types so the visual editor and markdown stay in sync.

If you already have an Obsidian or VS Code stack wired to agents, OpenKnowledge is not a slam-dunk replacement yet. It is more interesting if your pain is team sharing, Git-friendly collaboration, and getting non-technical users onto an AI-aware markdown workflow without custom plugin setup.

Discussion mood

Mixed but curious. People liked the open source, markdown-first, Git-backed team collaboration idea and thought the editor looked polished, but many were unconvinced it beats Obsidian or VS Code for individual users. The biggest reasons were missing built-in chat, weak first-class local model support, macOS-only desktop packaging, and the sense that existing plugin-based setups already cover much of the AI story.

Key insights

  1. 01

    GitHub sync is explicit, not automatic

    The privacy and sharing model was murkier than the launch post made it sound. The useful clarification is that choosing a “shared” project does not publish anything by itself. It only keeps OpenKnowledge config files in version control. Actual sync starts only after the user explicitly creates a repository in their own GitHub account or organization and turns on autosync. That shifts the product from “mystery cloud layer on top of Git” to “GitHub-assisted collaboration with guardrails,” which is a much cleaner position.

    If you evaluate it for a team, test the exact repo creation and autosync flow before ruling it out on privacy grounds. The real decision point is whether your team is comfortable using GitHub as the remote system of record.

      Attribution:
    • pcthrowaway #1
    • mkt123 #1
    • engomez #1
  2. 02

    The real value is setup standardization

    What this adds over an Obsidian vault is not novel AI capability. People already run Obsidian with Model Context Protocol plugins, REST APIs, and direct markdown access from Claude Code or other agents. The stronger case is operational. OpenKnowledge packages the same pattern so teams do not have to teach every person how to wire plugins, Git, and cross-agent configs together. That makes it more of a deployment product than a raw capability breakthrough.

    Judge it like internal tooling for onboarding and consistency, not like a feature race against your own power-user stack. If your team loses time to custom setup and support, the packaged workflow may be worth more than one more plugin.

      Attribution:
    • rnxrx #1
    • engomez #1 #2
  3. 03

    Obsidian migration breaks on computed views

    The hardest migration gap is not opening markdown files. It is losing the higher-level behaviors people built on top of them. Obsidian users pointed to Dataview-style queries, dashboards, charts, and generated task views as the real lock-in. The maintainer acknowledged that the database side is the main missing piece. That means compatibility with vault files is only the first mile, not a true migration story for advanced users.

    If your organization uses markdown as a lightweight database, inventory those derived views before considering a switch. File compatibility is not enough when people depend on queries, dashboards, and document-generated tables.

      Attribution:
    • jfim #1
    • engomez #1
  4. 04

    Multi-document agent edits need stronger transactions

    One commenter pushed the team collaboration idea further than ordinary note sync. In AI-native workflows, multiple agents may update a policy, its references, changelog, and procedures together. That requires atomic, semantically coherent changesets across several documents. Per-document history is too weak for that job. This is the kind of requirement that starts to separate a pleasant markdown app from a real system for AI-mediated knowledge operations.

    If you plan to let agents edit shared documentation at scale, look past single-file undo and Git history. You will want explicit support for grouped multi-document changes, review boundaries, and machine-readable change intent.

      Attribution:
    • abdullin #1
    • engomez #1
  5. 05

    Skills payloads can become context overhead

    The built-in skills and Model Context Protocol layer are supposed to help agents navigate and manipulate the knowledge base, but one early user hit a case where Codex said the skill bundle was too large and had to be read in chunks. That is a practical warning. Tooling meant to help agents can also consume context budget and add latency if it is not aggressively trimmed. Progressive disclosure is the right direction, but the current packaging still needs work.

    Treat agent instructions and tool manifests like production assets, not documentation blobs. Measure prompt footprint and startup behavior, especially if you want the app to work well with smaller or cheaper models.

      Attribution:
    • engomez #1 #2 #3
    • sizero #1

Against the grain

  1. 01

    Power users may see a wrapper, not a leap

    For someone already comfortable with Obsidian, VS Code, and local model tooling, the product can feel like a dressed-up bridge between existing apps rather than a better environment. The critique is not that the idea is bad. It is that handing AI off to Codex or Claude while keeping a separate editor misses the chance to make the agent feel native, and the current benefits may amount to fewer copy-paste steps plus bundled defaults.

    If your buyers are expert individual users, do not assume polish alone will move them. The stronger audience is teams that value packaged workflows more than maximal flexibility.

      Attribution:
    • kylenessen #1
  2. 02

    Open source branding clashes with proprietary defaults

    A few people objected to calling this fully local and open source while centering proprietary AI services and leaving local model support underdeveloped. The maintainers said agent-agnostic command line and Model Context Protocol paths exist today, and that OpenCode, Zed, and clearer local-model guides are next. Still, the criticism lands because the first-run story points users toward hosted models, while local inference feels like a roadmap item.

    If openness is part of your product identity, make local models and OpenAI-compatible endpoints first-class from day one. Otherwise expect skepticism from exactly the users most likely to care about open source knowledge tools.

      Attribution:
    • jrm4 #1
    • engomez #1 #2 #3
    • pcthrowaway #1

In plain english

Claude ↩
A family of AI models and apps from Anthropic, often used for writing and coding tasks.
Codex ↩
An AI coding product or model line associated with OpenAI, used here as an external coding agent app.
Cursor ↩
An AI-focused code editor built on top of Visual Studio Code.
Dataview ↩
A popular Obsidian plugin that lets users query metadata and generate dynamic tables, lists, and dashboards from markdown notes.
Git ↩
A distributed version control system used to track changes to files and coordinate work across people or machines.
GitHub ↩
A hosted platform for Git repositories that adds collaboration features like pull requests, permissions, and issue tracking.
Notion ↩
A popular document and workspace app that mixes writing, databases, and collaboration in a hosted product.
Obsidian ↩
A note-taking app built around local markdown files, backlinks, and a large plugin ecosystem.
OpenCode ↩
An AI coding tool or harness mentioned by commenters as a desired integration target.
ProseMirror ↩
A toolkit for building rich-text editors that represents documents as structured trees instead of plain text.
VS Code ↩
Visual Studio Code, a widely used code editor from Microsoft with extension support and built-in AI integrations through various tools.
WYSIWYG ↩
What You See Is What You Get, an editor where the on-screen formatting looks close to the final rendered document while you type.
Zed ↩
A code editor mentioned as a possible integration target for local or user-chosen AI models.

Reference links

Project docs and product references

Related formats and naming collisions

Comparable projects and integrations

  • piclaw
    A commenter’s own markdown knowledge app with WYSIWYG, terminal, and plugin support that they said had replaced Obsidian for them.
  • CRM Open Knowledge Wiki example
    An example knowledge base built around the Open Knowledge Format, offered as something OpenKnowledge could edit.
  • Running Knowledge Base example
    Another Open Knowledge Format example repo mentioned as a potential fit for the app.

Interop references