Why and How I Rewrote These Obsidian Plugins

> Unfortunately for the Obsidian team the main result of this blog post has been to draw people’s attention to some long standing concerns about their plugin system.

As someone on the Obsidian team I don't consider that unfortunate at all. On the contrary, I feel incredibly lucky that anyone cares! Obsidian has followed complaint-driven development from the start [1]. I'd be more worried if people stop complaining.

There will always be some set of things that bubbles up to the top of the community's priority list. The plugin ecosystem has bubbled up to the top of the list, so you can expect to see improvements. The solutions we have in mind are sourced from the many smart people in the community who are also invested in this challenge.

Of course the bottleneck is that Obsidian only had two developers, now four. So there are only so many things that can be improved every year. It's fun to go back through shipped items on the Obsidian roadmap [2] to see a reflection of what the community was complaining about at the time. Obsidian has come a long way.

I also think it's good that people are becoming educated about the tradeoffs between safety and freedom. Obsidian is incredibly malleable and powerful, but that comes at a cost. It's tricky to make a chainsaw that cuts trees but not arms.

What this blog post highlights is that the landscape has radically changed since 2020 when Obsidian launched. It's now viable to use Obsidian without plugins, and if you want to add functionality yourself, it's become trivial to add a feature using LLMs, and have the code completely in your control.

[1] https://blog.codinghorror.com/complaint-driven-development/

[2] https://obsidian.md/roadmap/