“Obsidian ships a new version and the developer's most popular plugin breaks.. Something that used to take 30 minutes took 30 seconds. The moment the graph view revealed a cluster of notes they didn't know were related — the tool was surfacing their own patterns. That was the aha.”
When I'm obsidian ships a new version and the developer's most popular plugin breaks, I want to build plugins that integrate cleanly with Obsidian's core experience without feeling bolted on, so I can keep plugins stable across Obsidian's frequent updates without constant maintenance.
A developer who uses Obsidian for their own notes and started building plugins to scratch their own itch. They now maintain 1–5 plugins with thousands of downloads and a Discord channel full of feature requests. They know the Obsidian API intimately but wish it was better documented. They build in TypeScript, ship through the community plugin store, and handle support in their spare time. They love the Obsidian community but sometimes feel buried by the expectations that come with a popular free plugin.
To build plugins that integrate cleanly with Obsidian's core experience without feeling bolted on — reliably, without workarounds, and without becoming the team's single point of failure for obsidian, leveraging bidirectional backlinks between notes.
A developer who trusts their setup. Build plugins that integrate cleanly with Obsidian's core experience without feeling bolted on is reliable enough that they've stopped checking. Versioned API with deprecation warnings and migration guides reduces the update breakage cycle. They've moved from configuring obsidian to using it.
Obsidian ships a new version and the developer's most popular plugin breaks. Users file 12 identical issues on GitHub within an hour. The developer opens the changelog and finds the API they depend on was deprecated without a migration guide. They spend their Saturday afternoon figuring out the new API, updating the plugin, testing across platforms, and publishing a fix. They post a release note explaining the change. Three users respond with "thanks" and one responds with a new feature request.
Maintains 1–5 Obsidian plugins with 1,000–50,000 downloads each. Develops in TypeScript using the Obsidian Plugin API. Publishes through Obsidian's community plugin review process. Handles support through GitHub Issues and the Obsidian Discord. Spends 3–10 hours per week on plugin development and maintenance. Has a day job that is not Obsidian plugin development. Uses Obsidian as their primary note-taking tool with 2,000+ notes. Has considered monetization (donations, paid plugins) but hasn't found a sustainable model.
Two things you'd notice: they reference obsidian in conversation without being asked, and they've built workflows on top of it that weren't in the original plan. bidirectional backlinks between notes has become part of their muscle memory. They're now focused on keep plugins stable across Obsidian's frequent updates without constant maintenance — a sign the basics are solved.
It's not one thing — it's the accumulation. Plugin-heavy ecosystem means assembly required before the tool is useful that they've reported, worked around, and accepted. Then a competitor demo shows the same workflow without the friction, and the sunk cost argument collapses. Their worldview — a plugin should do one thing well rather than become a feature-bloated Swiss army knife — makes them unwilling to compromise once a better option is visible.
Pairs with obsidian-primary-user for the user vs. developer perspective on the plugin ecosystem. Contrast with vscode-primary-user for the extension ecosystem comparison. Use with github-open-source-maintainer for the shared challenges of community-driven development.