Following on from this thread about out-of-date plugins:
How are community plugins currently curated?
Would it be possible to ask developers to provide a compatibility statement—similar to WordPress plugins—confirming that the latest version of their plugin has been tested to work with XX version of Obsidian?
Would it be prudent to remove plugins from the directory if they aren’t updated for XX months? The old plugins would still be available on GitHub for anyone who wants them, but decluttering the plugin directory would save some users from installing incompatible plugins.
There has been a bit of discussion on the Discord server related to this.
The short version is:
This should be handled on a case by case basis
There are many plugins that have not been updated in months, but still work as they use stable APIs
Plugins are removed from the plugin list by request of the original author
if a plugin is no longer maintained by the author a change of the associated GH repo can be requested
There was a initiative to collect a list of all plugins and if they are compatible with Live Preview/Mobile, but that is not active anymore
(Obsidian Community Resource - Google Sheets), having plugin authors provide compatibility themselves, retroactively, would probably be a similar story.
Plugins are removed from the plugin list by request of the original author
Feel Obsidian needs to be proactive in removing plugins that have been—or appear to have been—abandoned.
Too much lint left in the system is making things increasingly murky.
Reserve the plugin directory for plugins with recent updates.
Users can still find old plugins on GitHub.
If a developer is no longer active and / or simply doesn’t ask for the plugin to be removed, will it stay in the plugin directory forever, even if that leads to frustration for countless users?
Many developers encourage users to ‘sponsor’ plugins. Think it reflects poorly on Obsidian if users are financing plugins that don’t work or that stop working after a short period of time. Think it makes users wary about sponsoring any developer (or even the app itself), which is a real loss for active developers.
It’s also a pain for users who design their work around plugins that then get abandoned—although most of us know the voluntary nature of much of what happens in and around Obsidian and the risks that that brings.
For me, these issues are beginning to add too much grit to the work that I do in Obsidian. I am trying to cut out community plugins and to stick with the core offering only, but that also means that I am having to use other apps and that I am slowly drifting away from using Obsidian. Last year, I recommended Obsidian to everyone I know. Now, I don’t. Perhaps I’m an outlier, but from the users I know outside this forum, I don’t think I am.
Angel
EDIT
As an example (NOT a direct criticism of one developer), this plugin has not been updated in fifteen months; it does not work with the current editor; and issues are unacknowledged by the developer. It is still in the plugin directory, and it is still asking for sponsorship from users. And trusting users expect it to work because they find it in the plugin directory. Can that be right and fair? How can that look good for Obsidian?
I think this is a bad idea.
One of the few plugins I use is old and has never been updated. Still works perfectly.
This isn’t a solution for the very reason you are raising the plugin directory as an issue.
Now, I do see issues with the current system. It’s a mishmash of Github, links and access through the program. Even the forum for some.
Some issues mught be solved by users being able to leave comments in the directory itself. It’s a subset of users who will raise an issue on Github. The comments could done through a link to a forum thread; each plugin in the directory having one automatically.
As far as i know, plugins need to be approved to show in the internal community plugin list. But, if outside this list, they can also be installed (directly from Github page).
Maybe the approval system needs to have a periodic re-approval: for example, after 6 months the developer needs to request a renew based on the current obsidian version.
Without any triage system, the list becomes obsolete.
But the developer could confirm it as still functioning and keep it active.
Think there should be a way to remove plugins that no longer function and are not being maintained, other than waiting for the developer to withdraw them.
Anyway, for me, I’m trying to stick with the core app only and am slowly drifting away because of what I perceive as a mess. My loss.
Not necessarily. That describes a top down system. An open API allows the system to evolve. There’s no reason why developers can’t produce a plugin that incorporates ratings or anything else that occurs to them. Still early days yet.
Yes, it’s a top down system, as the approving system. There’s nothing new here.
For me the main question isn’t the “age” of the plugin, only the compatibility information.
Perhaps we could add the date of the last update near the number of the version in the description of the plugin in Obsidian.
Like already said some pluging are “old” and still do work fine but this could be an useful information for somebody willing to base his workflow on a couple of “out-of-date” plugins.
There have been cases before where the original maintainer could not be reached.
In those cases a new maintainer wanted to take over, and requested a change in the plugin list, which got granted.
This process got started by users over in the discord.
A similar thing should be possible with plugins where no new maintainer can be found.
But first try reaching out to the original maintainer and try to find a new one.
But having a a regular reaproval process would not be a good idea I feel like, since that would be even more work for the Obsidian developers.
A automatic process is also not something I would do, since plugins that have not been updated in months might still work.
And then you run the risk of removing a perfectly working plugin, just because the maintainer did not respond in time.
Sure, no more work for Obsidian developers. But, as community plugins, there’s no way to add permissions to great developers / plugin reviewers in the community (like you) to implement a system of reapproval/review by the community?
Don’t want to create an onerous process, but think a triage system would benefit the app, active plugin developers, and users.
Easier to do this now than much further down the line when there are even more plugins and clones competing for attention.
If a plugin only works partially (such as in the legacy editor) that should be clear to users when they install. Too much to have a statement from the developer saying what version of Obsidian the plugin has been tested with?
And an out-of-date plugin that doesn’t have engagement on the part of the developer but is still asking for financial support just looks like a scam, which reflects negatively across the board, IMO.
I do agree with that, such a thing already exists for mobile compatible plugins.
I already linked the google sheet where the community tried to declare this for all the plugins, but if you take a look at it now, months after, not that many plugins are categorized.
So finding out if plugins do work in the new editor will take a bit of time, but it is something that should be done.
Since this would be declared in the manifest file of the plugin(which is stored in the GitHub repo) all plugin authors would have to declare that themselves/accept a PR.
This is is a thing that should be done by all developers, not sure in what form.
The plugin you are referencing has
The current API of this repo targets Obsidian v0.10.0.
in the Readme.
But it could be written better(Not everyone knows what an API is).
In my plugins I have a minimum working version as a badge, I think I will also add a badge for the last known to work version soon.
The main problem with that is maintenance, the developers will have to be constantly testing their plugins if they work with Obsidian, which depending on the size of the plugin and the time restrictions some developers have(most are students or have a full time job) can be a bit much.
The messaging with this should be something like “working with vX.Y.1 guaranteed” so that users on vX.Y.2 know that it should most likely also work for them.
Fair point, I have seen that often enough with abandoned Open Source software, so I have come to accept that many just stop working on it, without updating the Readme to reflect that.
