PKM for developers: Dendron and Foam in VS Code

Most knowledge management tools are applications you open. A VS Code based system is not: it is a folder of Markdown files with an extension pointed at it. That sounds like a smaller idea than it is, because a folder of Markdown files in a working copy inherits everything a repository already gives you.

The notes have history. git log tells you when a decision was written down, git blame tells you who changed the paragraph that is now wrong, and a bad edit is one git revert away rather than gone. For a shared engineering wiki this matters more than any feature: a change to the deployment runbook arrives as a pull request, gets reviewed by the person who owns the system, and is merged with a diff that shows exactly which sentence moved. No note-taking application has an equivalent, because none of them has a review model.

The notes are also searchable by the tools you already use: rg "retry budget" across a directory holding both the notes and the code finds the design note and the implementation in one pass. Multi-cursor editing, regex replace and snippets apply to Markdown as readily as to TypeScript, and most note apps have weaker text editing than the editor you already use all day.

Then there is the plain ergonomic argument. The editor is already open, so there is no second application to install on a new machine, no second sync mechanism to configure, and no second place to search. The cost is the mirror image: a repository is a technical artefact, and everything below assumes the person keeping the notes is comfortable with one.

Dendron's central idea is that the hierarchy lives in the name of the file rather than in folders. A note about the audio pipeline of a project is a file called proj.earkeep.audio.md, sitting flat in the vault directory next to proj.earkeep.ui.md and proj.website.deploy.md. The dots are the tree. There are no directories to move things between, and a note can belong to a hierarchy without its parent existing as a file at all.

This is a deliberate trade. Folders force a single classification; dotted names make the classification a prefix, which you can type, autocomplete, filter and rename in bulk. Dendron ships a hierarchy refactor that renames a parent and rewrites every child and every inbound link, the operation folder-based systems handle worst. The same instinct outside a developer setting is Johnny Decimal.

The interface to all of it is the lookup bar. One keyboard shortcut opens a fuzzy prompt over the whole vault; typing proj.ear narrows to that subtree, and pressing enter on a name that does not exist creates it. Finding and creating are the same gesture, which is what keeps the hierarchy from decaying: the cheapest way to make a note is to make it in the right place.

The part that has no real equivalent elsewhere is schemas. A schema is a YAML file that declares what a hierarchy is allowed to contain: that under proj.* there may be children called audio, ui and deploy, that each of them may have a decisions child, and that a note created at a given position is born from a given template. The vault then autocompletes the next valid segment as you type and flags notes that sit outside the declared shape.

That is the sense in which Dendron treats a note as something with a contract. Elsewhere, structure is a habit you maintain by hand and lose when you are busy; in Dendron it is a declared, machine-checked artefact versioned alongside the notes it governs. The cost is ceremony, and a vault of forty personal notes will never repay it. A shared knowledge base of several thousand notes might.

Dendron is a good design that lost its company, and any honest recommendation has to start there. In February 2023, founder Kevin Lin told the community that after two years of building, the venture-backed business had not found product-market fit and the company was winding down. The project's README on the default branch now opens with a one-line notice that Dendron is in maintenance only and that active development has ceased.

The repository bears that out. Checking it in August 2026, the last substantive commits to the default branch date from early 2024, with only occasional housekeeping since, and there are several hundred open issues. The code was relicensed to Apache 2.0 in 2024, so anyone is free to fork it, but no fork has emerged as the successor. The extension is still published, still installs, and still works for what it already does.

Treat that as the fair summary rather than an obituary: a stable, unmaintained tool operating on plain Markdown files you own is a much safer thing to depend on than a stable, unmaintained tool with a proprietary database. If Dendron's hierarchies and schemas are exactly what you want, the files remain yours and readable whatever happens to the extension. But you should check the repository yourself before adopting it, and you should not expect bugs to be fixed or the extension to keep pace with changes in VS Code indefinitely.

Foam, by Jani Eväkallio, takes the opposite position. It is MIT licensed, and it describes itself as a personal knowledge management and sharing system built on VS Code and GitHub rather than as an application. In practice it is a small extension plus a handful of conventions, and the conventions are the ones the wider Markdown note-taking world already uses.

What it gives you is the Roam-descended set: [[wikilinks]] with autocompletion and aliases, a backlinks panel showing every note that references the current one with its surrounding context, hierarchical tags with their own explorer, a graph view, note embedding, sections addressable as [[note#Section]], daily notes, and templates. Two smaller features carry more weight in daily use than they sound: renaming a file updates the links that point at it, and a panel lists orphans (notes nothing links to) and placeholders (links pointing at notes that do not exist yet), which together are the maintenance checklist for a growing set of notes.

There is no hierarchy in the filename, no schema and nothing to declare. Structure emerges from links, which is the model described in Zettelkasten and evergreen notes, and the two of them fit together well: Foam is close to the smallest software that makes that method workable.

The lock-in story is unusually clean. Because Foam's data model is just Markdown with wikilinks, its own documentation notes that an Obsidian vault is usually already a Foam workspace. You can open the same folder in both, use Obsidian on a phone and Foam at a desk, and stop using either without converting anything. That property, more than any single feature, is the argument for it.

Foam is also the one that is still moving: its repository showed commits in the weeks before this article was written, and releases through 2026. It has not declared itself finished either, since the README still asks for a high tolerance for alpha-grade software while promising it will never lock you in or damage your files. This reverses the conventional wisdom of a few years ago, when Dendron was the better-resourced project and Foam the quiet side effort.

The two differ on almost every axis except the file format, and the file format is the thing that lets you change your mind later.

Given the maintenance picture, the honest default for someone starting today is Foam, or a plain folder with no extension at all. Dendron is worth reaching for when you specifically want schemas and hierarchy refactoring, knowing they will not be developed further. Its ideas are worth stealing regardless: a dotted naming convention and a written-down rule for what may exist under each prefix cost nothing in any editor.

The choice is less about features than about who the notes are for and where you are when you write them.

A VS Code based system wins when:

• The notes sit next to code. Design notes, runbooks, incident write-ups and architecture decision records benefit from living in, or beside, the repository they describe, and from being reviewed the same way.
• More than one person edits them. Pull requests, review and merge are a governance model that note apps replace with a shared folder and hope.
• You want the history. Knowing when a claim entered the wiki, and what it replaced, is often the whole value of an engineering knowledge base.
• You want automation over the notes. A link checker, a Markdown linter or a publishing step in CI is trivial when the notes are a repository. Publishing a vault as a site with a static generator such as Quartz follows from the same property.
• You distrust tool lock-in. A directory of Markdown and a git history will outlive every extension mentioned here.

A standalone application wins when:

• Capture happens away from the desk. Neither Dendron nor Foam has a mobile app, and a git client plus a text editor on a phone is not a capture tool. This is the single most common reason people move to Obsidian.
• Non-technical people need to write too. Asking a colleague to clone, branch and open a pull request to fix a typo is a real cost, and often the wrong one to impose.
• You need rich objects. Canvases, embedded PDFs, spaced repetition, relational tables and database-style queries over frontmatter (the Dataview plugin's territory) are not things a Markdown extension will give you.
• You want a large plugin ecosystem. The comparison between the main desktop options is in Obsidian, Logseq and SiYuan, and the more specialised open-source tools in Zettlr, Joplin, Anytype and AppFlowy.
• Your editor is not VS Code. Neither extension follows you to a JetBrains IDE, Neovim or Emacs. VSCodium is the exception, since both run there.

The two are not exclusive. Because both extensions operate on ordinary Markdown, the common arrangement is a single folder opened in VS Code at the desk and in a mobile Markdown app elsewhere, synced by git or by whatever the phone can manage. This is the arrangement Foam's own documentation anticipates.

A knowledge base that is a repository has one property that a proprietary note app does not: a coding agent can already read it. It greps, it opens files, it follows links, and it can propose a change as a diff you review. Nothing needs to be indexed, embedded or exported first.

The convention that makes this work in practice is a plain instructions file at the root of the notes repository, most commonly AGENTS.md, an open convention that several coding agents now read by default (some tools use their own filename, so check which one yours looks for). Its job is to tell an agent what a human newcomer would need: how notes are named, what lives under which prefix, where decisions are recorded as opposed to speculation, which files are canonical and which are scratch, and what should be updated when something changes. It is the schema idea again, expressed as prose for a reader that understands prose.

Two habits separate a notes repository an agent can use from one it merely searches. Keep each note about one thing and say what it is in the first sentence, since that sentence is what a retrieval step matches on. And distinguish settled from unsettled explicitly, because an agent cannot tell a decision from a passing thought unless the file says so.

Andrej Karpathy's LLM wiki is the fullest version of this idea: a hand-curated Markdown knowledge base kept deliberately small and well-structured, read directly by a model rather than retrieved from a vector store. It is covered in the LLM wiki, and the retrieval alternative in local RAG. A Foam or Dendron vault is already most of the way to being one.