#1

Use case or problem

Most users would want to leave safe mode ON and not want to rely on third-party plugins.

Proposed solution

This guy does Obsidian a great favour. Obsidian Plugins (0.9.10) — My top plugins in the Obsidian app - YouTube Please incorporate the top plugins he uses (especially note refractor and tables) as part of core plugins. Or figure a way to analyze the most downloaded third-party plugins and incorporate them as core plugins.

Current workaround (optional)

I turn off safe mode every time I must use note refractor.

Related feature requests (optional)

4 Likes
#2

You are suggesting to move the safety responsibility of 3rd party plug-ins to the Obsidian devs. That is not a good thing: the Obs devs should not be distracted by investigating 3rd party plug-ins for compatibility and safety.

2 Likes
#3

I have no experience with this type of thing and am just thinking out loud so please forgive me if this idea is insulting to even consider. I know the plugin developer’s time is also valuable and they deserve control over the potential benefits of their creations.

I am just looking to see what people’s reaction to this hypothetical is. Basically, is there any chance it wouldn’t be an undue distraction for something like this to happen where a plugin creator might be willing to continue to create plugin as third party but hand over complete control over current version so that it can be core and therefore more useful and widespread, supporting Obsidian and the community.

I know it is likely the distraction that @Klaas mentioned 99% of the time, but maybe there are special cases that wouldn’t require the plugins be really up-kept, and they aren’t overly complicated. Like, I guess if the creator of a plugin that served a much sought after need was willing to just hand their work over no strings attached and the developers, with the creator’s input if they wanted, could over time more quickly approve and maybe implement as part of the core. There definitely would likely be no promises made by the developers since this would be completely voluntary on the plugin creator’s part. And, it wouldn’t be updated and could risk being broken as Obsidian changes and consequently removed from the core. As I type all of this, I know how bad it sounds, but still am optimistic.

I think, possibly even with all the what ifs and sacrifices, as Obsidian grows, the potential for this scenario to give the plugin a much larger chance to be a hit and necessity in the platform may make it worth it. And also, potentially more importantly, the third party version can still grow with new additional features and a more widespread user base as the original version gains popularity. At that point it may be at the community’s request or in the interest of the developers to work with the plugin developer to make that plugin really work in the changing core and likely benefit this person in some way. At the very least they would be heavily lauded and hopefully rewarded by the community at the very least which basically brings me back to the current setup.

Sorry for the ramble. I just didn’t want to discount this idea so quickly because I definitely can relate to users who may feel very conflicted about making a plugin a too big part of their workflow.

Thanks.

#4

@I-d-as: you have made a good point. In fact, there is already 1 plug-in (I forget which one) that was developed by someone and soon afterwards was incorporated in Obsidian. When that happens, Licat takes over responsibility.

In fact, it could be that Licat would like to expand native functionality of Obs and someone’s plug-in could be the answer, as @ijac suggests.

So, yes, reconsidering the issue I agree that this could be useful.

Having said all that, I personally don’t see the difference between having a native plug-in and a 3rd party plug-in. At the end of the day it is about extending functionality, one way or another.

2 Likes
#5

I agree that I don’t necessarily want the developers to be overly distracted with incorporating third party plugins as core plugins, but I can completely relate to what @I-d-as says about conflicting feelings over becoming overly reliant on a third party plugin that could at any point stop being developed & eventually cease to work. It is for this reason that if I don’t have an absolute essential need for a third party plugin I won’t use one (and thus far have used none).

I suppose I could be persuaded to use a third party plugin that offers a convenience that I can manually achieve with Obsidian should it eventually be no longer maintained.

I understand both sides to this.

1 Like
#6

But considering that all plugins are available on Github, if development was abandoned on a given plugin, it would be easy for someone to fork the code and begin developing their own updated version that they would then maintain.

1 Like
#7

@larosajohnson: true, but there’s no certainty someone would start forking.

#8

There is also no certainty that Obsidian will continue development either. That’s the risk we take in using software :man_shrugging:t5:

1 Like
#9

@larosajohnson: true, but the tandem Silver/Licat have a longer, steady track record (don’t forget Dynalist) than any of the plug-in developers. So, if we’re talking about risk and uncertainty the balance comes out in favor of the former.

Having said that, I am not concerned about plug-in continuity. I use what I need, and if the plug-in dev stops, so be it.

1 Like
#10

I really hope my Rust-based plugins become a top plugin, so now the Obsidian devs need to learn rust! I guess my point is it may not be technically feasible to for the core team to take over a foreign codebase without some predefined constraints on implementation.

2 Likes