Files.md is a five-year-old, fully open-source note-taking app that runs as a browser PWA with no Electron wrapper, no build system, and no install step. You open web/index.html and point it at a folder of markdown files. That’s it. When it trended on Hacker News the week of May 19, the discussion quickly stopped being about the app itself and started being about what it exposed: Obsidian’s core is closed-source, and a non-trivial number of its users didn’t know that.
What Files.md Actually Is
Files.md is a progressive web app by developer zakirullin that treats the local filesystem as the database. Notes live as plain .md files in a predefined but optional folder structure: brain/, journal/, habits/, and so on. There is no vault format, no proprietary metadata layer, no .obsidian directory full of JSON blobs. The README is structured to be LLM-friendly, so AI agents can parse the folder layout without reverse-engineering anything.
Sync is opt-in and agnostic. You can keep files purely local, sync via a cloud folder (iCloud, Dropbox, Google Drive), run a self-hosted binary, or use the hosted endpoint at api.files.md. None of these are required. The architecture assumes your files already live somewhere you control.
The README frames the project’s philosophy plainly: use your brain, not advanced templates or AI workflows. It is a direct jab at the personal-knowledge-management tooling crowd. Less system, more writing.
Obsidian’s “Open Shell” Problem
Obsidian is often described as open-source-adjacent. Its data format is markdown. Its plugin ecosystem is open. Its community is vibrant. The core application, however, is proprietary. It ships as an unobfuscated Electron app, but the source is not published under any license. Several commenters in the HN thread expressed genuine surprise at this distinction, with one describing Obsidian as “the inverse of an open core product”: open data format, open plugin surface, closed core. The concept is clear enough to warrant its own shorthand: an open shell.
The practical risk of a closed core is not theoretical. A documented bug in Obsidian’s sync CLI causes .sync.lock directories to persist after a failed acquire() call, with no automatic cleanup. Workarounds exist (skip sync-setup for warm caches), but users are decompiling the sync binary to diagnose the issue because the source is not available. This is the exact class of problem open source is supposed to prevent, and the exact class Obsidian’s model cannot address without vendor action.
According to a third-party download mirror, Obsidian v1.12.7 supports over 1,000 community plugins, bidirectional links, a graph view, a canvas whiteboard, and runs on Windows, macOS, Linux, iOS, and Android. The feature gap between it and files.md is enormous. Nobody is arguing otherwise.
The Plugin Ecosystem: Moat or Migration Tax?
This is where the debate gets sharp. Obsidian’s plugin library is its most cited advantage, and for good reason. If your daily workflow depends on Dataview queries, Templater scripts, or a specific Kanban board plugin, switching to a browser PWA with none of those is not a realistic option.
The counter-argument, raised repeatedly in the HN discussion, is that the plugin ecosystem works both ways. It is a reason to stay, but it is also the only reason to stay. The data format (markdown) is portable by design. The folder structure is portable. The sync layer is replaceable. Once you strip away the plugins, Obsidian is an Electron wrapper around a folder of text files. The switching cost is not in the data. It is in the extensions.
Several HN commenters defended Obsidian’s model as effectively trustworthy despite the closed core, arguing that the real risk lies in unpopular, abandoned open-source plugins with access to the filesystem, not in the core app maintained by a funded team. That is a fair point. A poorly maintained plugin with a fs.readFile call is arguably a bigger surface than a closed-source core with a commercial sync service to protect.
The framing that emerges is specific: Obsidian’s plugin ecosystem is less a competitive moat and more a migration tax. You can leave. It will cost you time and workflow disruption. Whether that tax is worth paying depends on how many plugins you actually rely on daily versus how many you installed and forgot.
How Files.md’s Architecture Differs
The technical contrast is blunt.
| Files.md | Obsidian | |
|---|---|---|
| Runtime | Browser PWA (File System Access API) | Electron (Windows, macOS, Linux, mobile apps) |
| Data format | Plain .md files, standard folders | Plain .md files, .obsidian/ metadata directory |
| Sync | Cloud folder, self-hosted binary, or none | Obsidian Sync (paid), or third-party folder sync |
| Plugin system | None | 1,000+ community plugins |
| Source model | Fully open source | Closed-source core, open plugin API |
| Install | Open index.html | Download platform binary |
| Browser requirement | Chrome preferred (File System Access API) | N/A (native app) |
The Chrome dependency is worth noting. The File System Access API is not fully supported in Firefox or Safari, which limits files.md’s portability compared to Obsidian’s five-platform coverage. For users who live in a Chromium browser, this is invisible. For everyone else, it is a real constraint.
No Electron means no bundled Chromium instance consuming RAM. No build system means the entire app is a static site you can serve from any HTTP server, including file://. There is a certain aesthetic purity to a note-taking app that is literally just HTML, CSS, and JavaScript pointed at a directory.
The Competing Plain-Markdown Field
Files.md is not alone in the no-lock-in niche. QOwnNotes is a native open-source app with Nextcloud integration, targeting the same users who want plain-text notes without vendor entanglement. rwMarkable is a self-hosted, Docker-based option that stores everything as markdown with no database layer.
The common thread among all of these is the same bet: that the filesystem, not a vendor’s sync server or plugin sandbox, should be the canonical store. The differences are in runtime (native vs. browser vs. Docker), sync story (Nextcloud vs. binary vs. none), and feature depth (QOwnNotes has tagging and scripting; files.md has deliberate minimalism).
When Moving Actually Makes Sense
The honest answer is: it depends on what you are actually doing with your notes.
If your Obsidian vault is a daily journal plus a handful of linked notes, and you use three or fewer plugins, files.md or any plain-markdown tool will cover your workflow. The migration path is copying .md files to a new folder. Wikilinks may need converting to standard markdown links, depending on the target tool. That is a script, not a project.
If your vault runs Dataview queries against frontmatter, uses Templater for automated note generation, or depends on canvas boards for spatial thinking, no plain-markdown alternative replaces that today. The plugin ecosystem, in this case, is not a tax. It is the product.
The real signal from files.md’s HN moment is not that Obsidian users are about to leave en masse. It is that a growing number of developers consider the “open data, closed core” model insufficient, and the HN thread gives that sentiment concrete language. When the next plain-markdown tool ships with file-system-native search, bidirectional linking, and a plugin bridge, the switching calculus changes. Files.md is not that tool yet. But the demand for it is now visible.
Frequently Asked Questions
Can AI coding agents work directly with a Files.md folder?
Yes — files.md publishes an llms.txt that maps its folder conventions (brain/, journal/, habits/) so LLM-based agents can parse the layout without reverse-engineering anything. Obsidian has no equivalent; AI tooling must ingest the .obsidian/ JSON metadata directory to infer vault structure.
How does QOwnNotes compare for teams already running Nextcloud?
QOwnNotes is a C++ native desktop app with deep Nextcloud sync built in, plus tagging, scripting, and a hierarchical notebook model. Unlike files.md’s browser-only runtime, it runs as a system application on Linux, Windows, and macOS with no File System Access API dependency — but it has no mobile browser or Chromebook path, and it requires installation rather than opening a single HTML file.
What specifically breaks in Firefox or Safari with Files.md?
The File System Access API, which files.md uses to read and write local folders directly, has no shipping implementation in Firefox or Safari as of 2026 — not partial support, none. The app effectively cannot edit local files in those browsers. Users locked to Firefox or Safari need a native alternative like QOwnNotes or a Docker-based option like rwMarkable.
What does Files.md’s anti-‘Second Brain’ stance mean it deliberately omits?
The README quotes a viral essay — ‘The Second Brain is getting better. But the first brain is not improving’ — and uses it to justify omitting backlink graphs, automated daily-note generation, AI-assisted linking, and template-driven workflows. The explicit bet is that configuring PKM systems displaces actual thinking, so none of those surfaces exist in the app.