The plugin problem: when your app needs 20 add-ons to work

Each plugin is a dependency on a solo developer. Each update is a chance for something to break. You're maintaining a software stack, not taking notes.

The plugin model sounds appealing: a minimal core app that you extend with exactly the features you need. No bloat. No features you don't use. Complete customisation. The marketing pitch is compelling.

In practice, the plugin model means you're responsible for assembling and maintaining a software stack. Each plugin is developed by a different person or small team, often as a side project. Each one has its own update cycle, its own quality standard, its own documentation quality, and its own likelihood of being abandoned when the developer loses interest or gets busy with other things.

The typical productive Obsidian setup has fifteen to twenty plugins. Daily notes. Tasks. Web clipping. Templates (Templater, not the built-in version). Dataview for queries. Calendar. Image auto-upload. Kanban. Git sync. CSS snippets. Reading time. Footnotes. Each one requires:

Discovery: Which plugin serves this need? There are often two or three competing options. Read the GitHub pages, check the download counts, read community reviews, test each one.

Configuration: Each plugin has its own settings panel with its own conventions. Some are simple (toggle on/off). Some are complex (Dataview requires learning a query language).

Compatibility: Plugins don't always play well together. A keyboard shortcut in one plugin conflicts with another. A file naming convention in one plugin breaks another's assumptions. Diagnosing these conflicts is detective work.

Maintenance: Obsidian updates sometimes break plugins. Plugin updates sometimes change behaviour. Abandoned plugins stop working when the API changes. You check for updates, read changelogs, fix broken configurations, and occasionally replace plugins whose developers have moved on.

This is systems administration work. It has nothing to do with taking notes, managing knowledge, or doing the work the tool is supposed to support. The time spent maintaining the plugin stack is a tax on every other use of the tool.

Built-in features vs plugin ecosystems

Fabric ships with everything built in. Search, AI assistant, canvas, collaboration, web clipper, voice notes, self-writing docs, RSS feeds, agents. No plugins. No dependencies. No breakage after updates. Every feature is developed, tested, and maintained by the same team, which means they work together reliably and update together without conflicts.

The question isn't whether plugins are powerful (they are). The question is whether you want to spend your time maintaining a plugin stack or doing the work the tool is supposed to enable.

Frequently asked questions

Aren't plugins more flexible than built-in features? Plugins offer more customisation. Built-in features offer more reliability. If you value customising every detail of your workflow and are willing to maintain the result, plugins win. If you want a tool that works reliably without maintenance, built-in features win.

What about Obsidian plugins that are well-maintained? Some plugins are excellent and well-maintained (Dataview, Templater). But even well-maintained plugins can break on Obsidian updates, conflict with other plugins, or change behaviour in ways that require your attention. The maintenance is reduced but not eliminated.

Does Fabric have any plugin or extension system? Fabric provides MCP for programmatic access and connections to external tools. But core features (search, AI, organisation, notes) are built in rather than requiring add-ons.

What if I need a feature Fabric doesn't have? Feature requests can be submitted and the team actively develops new capabilities. The trade-off: with built-in features, new capabilities arrive through product updates. With plugins, new capabilities arrive when a community developer builds them, which may be faster or slower depending on the feature.

Is the plugin problem unique to Obsidian? No. Any tool with a plugin ecosystem (VS Code, WordPress, Figma) has a version of this problem. The difference is that for a notes/knowledge tool, the core functionality (search, organisation, retrieval) is what plugins typically provide, which means the plugin dependency is central rather than peripheral.

How many plugins does the average Obsidian user have? Community surveys suggest 10-20 plugins for regular users and 30+ for power users. Each one is a dependency that requires attention over time.

What about the Obsidian community? The Obsidian community is one of the best in the productivity space: helpful, creative, and productive. The community's quality doesn't change the architectural reality that plugin-dependent tools require more maintenance than tools with built-in features.

Can I gradually reduce my plugin dependency? Yes. Many users who switch to Fabric find that the built-in features (semantic search, AI, smart organisation) replace the functionality they were getting from 5-10 plugins, reducing the maintenance overhead substantially.

Related reading: Obsidian setup takes forever, Obsidian is not for everyone, Why second brains fail, Obsidian doesn't work for teams. Related pages: Fabric vs Obsidian, Best Obsidian alternative.