I’d love for Anytype to go the Obsidian route where pretty much everything is a plugin.
The plugins released by the Obsidian development team are called Core Plugins, and by disabling all of them, you end up with just a barebones markdown editor. Some examples of the core plugins are:
Backlinks
Graph
Search
Command palette
Daily notes
File explorer
Tags
etc.
With this approach, the user can customize the whole app to their liking and they don’t end up being stuck with unnecessary features that clutter the workspace.
Yeah, if anyone has an objection as to why it shouldn’t work that way, speak up, otherwise it sounds like a great idea to me and it seems the others on this thread!
I’m gonna provide a little bit of push back to this. I personally hope Anytype doesn’t lean into plugins to that extent where core functionality is implemented as plugins. There’s a few reasons I’m hoping that’s the case:
It tends to provide a less seamless experience
When core functionality is implemented as a plugin often users can disable that plugin (after all that’s one of the main reason you might choose to implement it as a plugin in the first place). But this means that a plugin which implements a particular feature can’t rely on the existence of some other functionality provided by a different plugin. It is possible for plugins to be written defensively so that they only provide some integration with another feature if that feature is available. However this increases complexity and so discourages adding such integration.
Increased development/testing complexity means the dev team’s limited time is used less efficiently
Software development is hard. There’s a million things things that can go wrong or break which is why testing is so important. But for testing to work well it needs to have good coverage of the different possible states an application can be in.
This is where one of the major downsides of adding more app settings and core functionality plugins to an app comes in, they increase number of possible app states exponentially. If an app has 2 settings/plugins that a user can independently enable/disable that’s 4 possible state combinations to test. But if an app has 4 settings/plugins, it doesn’t have 8 possible states, it’s got 16. 8 settings is 256 possible states, and 20 settings/plugins has a whopping 1,048,576 possible state combinations.
This is a bit of an over simplification but the general principle that adding settings and core plugins tends to increases complexity exponentially is true. And the greater the state complexity, the more time it takes to build an app that works for all different states and the greater the chance of bugs slipping in. It also makes tracking down and reproducing bugs harder. If a user is experiencing a bug that is caused by their particular combination of plugins it can be difficult to narrow down the cause.
Platforms that go this route often end up relying community plugins for the implementation of a greater amount of core/general functionality than they might otherwise
If a community plugin is made for some feature that has broad appeal and that plugin becomes popular because of the usefulness of that feature then even if the actual UX provided by that plugin is pretty “meh” it’s harder for the app devs to justify putting time into developing an officially supported core plugin to do implement that since there’s already something that mostly works + you risk upsetting the community by sherlocking that functionality. The result of this greater reliance on community supported plugins for a lot of basic/very popular functionality can have some major downsides:
User experience can vary wildly
Some plugins are great, very polished, include good documentation, implemented in a generalised enough way to met the needs of many people. Others will be poorly maintained, intuitive, and bug ridden. Community plugins often tend to be shaped predominately by the needs of a plugin developer. If that developer uses macos and ios then chances are they’re not going to put as much work to ensuring that plugin works as well on windows or android. As a user all this this inconsistency can be very frustrating.
Reduced feature discoverability
Official core functionality plugins are often installed and enabled by default so there’s no discoverability issue there. But if an app comes to rely on some popular and basic functionality being implemented by a community plugin then that functionality isn’t going to be as apparent to a new user. And trying to find if an plugin to do what you want exists can be painful sometimes. You often have to try a few different plugins to find the “good” one, or (due to the greater tendency of community plugins to be more specialised) one that works in a way that meets your needs.
I know a lot of the above is based on personal observation and is somewhat opinionated. But I’m not trying to argue that the approach suggested in this topic is bad idea or shouldn’t be done, just that while it might seem like there are only upsides at first glance I do think there are some major potential downsides to consider carefully before exploring such an approch.
I don’t want to some across as too negative towards plugins especially community developed ones, plugins can be great! That one niche piece of functionality that only you and two other people want is not likely to be ever be built in the app by the core dev team. But with plugins there’s a good chance someone in the community might have made a plugin for it.
However that is the use case where plugins tend to shine the most so while I’m definitely not anti-plugins I do want to push back on the notion that there are no downsides to implementing a lot/most of an app’s general functionality using plugins.
@rocklobster i think you probably want to open a new thread for that. This one is for discussing how a plugin system could work.
@Narvey yeah that’s a good point. There’s nothing stopping you writing non-plugin code in a modular and unit testable way but writing it as a plugin will probably make it simpler to keep modular in some ways.
lol, the hate emojis thing would be related if emojis were a core feature developed as a plugin. But yeah, does seem like it was supposed to be separate.
To chime in here, one of the reasons I have used Notion and now Anytype instead of Obsidian or LogSeq is the lack of need for tinkering with third party plug-ins. The last thing I want is to spend days on end researching plug-ins, evaluating the subtle differences and interactions between them, reading about reviews and bugs, deciding which has adequate developer support, etc etc.
I very much want there to be an API and the ability to integrate and the ability to add custom integrations.
In general tho, I’d rather have an imperfect and unified system where development effort is focused and UX is consistent, rather than chasing perfection through a dark muddy world of third party plugins for core functionality.
There is also a significant part of me that disagrees with what I said above. I considered trying Obsidian with Make.md instead of Notion, and maybe I should!
I never really understood this argument against plugins.
No one is forcing you to use plugins.
You can just keep on using the app without them while people who would like to use plugins, now can.
I think others covered this pretty well. When they become dominant they can crowd out core feature development, and their development is dependent on third parties whose incentives aren’t the same as the core team.
I think plug-ins are great except when they basically pre-empt and displace core feature development. Of course, they can also serve an experimental ground for new features.
There are positives and negatives.
I guess what I mean is I want the core product to address my needs, and plug-ins to be extra nice-to-have features.
If plug-ins are a NEED for me, then the product isn’t right for me.
This of course don’t apply also to different applications, like for instance if someone developed an accounting system in Anytype, that would be awesome and useful, and not something the core team will probably ever develop.
In Obsidian tho, to make it meet my basic needs, I would need third party plugins like Make.md.
I think @callumgare makes a good case for approaching plugins with caution.
That being said, part of my rationale for being so in favor of plugins is that Anytype is almost feature complete when it comes to “core functionality.” Yes, there are some workflows still in desperate need of some tweaks, but overall, the current version has the basics of PIM tied down.
So where do I think plugins would be useful?
1. Creating custom views to interact or visualize data from a source (e.g. study cards + custom calendar widgets):
Btw, a good example of what community involvement would look like, IMO, is Figma. The product stands on its own pretty well, but the minute you need to extend it with some weird use case, someone already implemented it and made it conveniently available through a plugin.
I would counter this by saying that it depends on what users want to do.
Too many features can be distracting / bloating your workflow - depending on your use case. For starters, simplicity / minimalism by itself is a feature.
Building towards specificity alienates part of the potential user base.
I myself am updating and waiting for some features to even consider using it, yet some features that are already implemented I would never install.
I get that a plugin system can be messy, I don’t like a extension/plugin system when there are even many ‘outdated’ plugins to choose from.
Solution could be: A comment by the developers about a plugin if it is covered by the core system already (inside the plugin store). No need to have it as an up-to-date comment system, but just when some plugin appears in a bug report or when a plugin is mentioned somewhere else to the core developers, then a comment could be made about a plugin.
