POLL / Discussion: taking over a plugin
-
With the XMLTools fork announcement, it got me thinking about the right etiquette for taking over a plugin. So I set up this poll to hopefully allow mulitple answers per person. I’m curiuos to see what other people think “reasonable” behavior is.
-
… So far, I know I feel okay if you have permission of the original author, or if it’s been abandoned a long time. Where that cutoff is, I am not sure; 5 years for sure, but probably even 2 years wouldn’t bother me – so the 3 years of XMLTools abandonment is probably sufficient. But 1 year seems aggressive: what if it’s just a really stable plugin that doesn’t need a lot of updates, or if the owner is working on it, but just hasn’t had a release in a year.
If the fork uses a new name, I know that GPL and similar completely allow publishing it; thus, putting a new entry with the new name, without replacing the old entry, is reasonable.
The gray area for me is when to decide to point the nppPluginList to a fork that has taken over the old name.
-
I am not sure. As long as a plugin works with the current version of Npp, I see no reason to remove it from the plugin list just because feature X was not implemented.
In general, I think a new name is always better to avoid version_mismatch_feature_not_avail discussions.
-
I can’t help but think immediately of this case:
New version 1.5 for Elastic Tabstops
in which a plugin author practically demanded to use the same name as an existing plugin, got permission from the previous author, created one release, and promptly abandoned it, ignoring all issues and releasing no further versions.
The old version of ElasticTabstops worked on 32-bit, but not 64-bit since Notepad++ version 8.3.
I’m really not crazy about the idea of a new plugin, with a new author, new code and new functionality, replacing an old one. Since the original author gave permission, it’s hard to argue that Notepad++ should have refused… but I wish it hadn’t happened. Under 32 bit, the old one still works better than the new one, but it is no longer accessible from Plugins Admin.
Transferring a repository should be OK. (I don’t know much about it, but at least on GitHub it’s possible, with consent of both old and new owners.) That would imply both consent and continuity. (Edit to add: Allowing a fork of the original plugin to use the same name going forward, with the original author’s permission, would fall in the same category. If the original author is unreachable, I’m inclined to think the same “burden of proof” standard I suggest below should apply.)
Where there is a completely new repository, I’m inclined to think the initial versions should have a new name and/or not be included in the plugins list. When the plugin has proven itself by being in actual use — ready to leave “beta” — then, if the original author agrees or is unreachable, and the new author and the community agree that it is a proper replacement rather than a different plugin, allow it to take over the old name.
Bottom line, I guess I think we should default to not allowing reuse of plugin names, and the “burden of proof” lies on the new plugin and its author to demonstrate that it is a proper replacement for the old plugin and that the author of the old plugin either consents or is unreachable. Not so much a set of rules, but a set of principles — which should be feasible, because reusing a plugin name should be very unusual.
-
@PeterJones said in POLL / Discussion: taking over a plugin:
what if it’s just a really stable plugin that doesn’t need a lot of updates, or if the owner is working on it, but just hasn’t had a release in a year.
At least for a GitHub project, why not raise an issue? If the author fails to respond in a reasonable length of time — say, 30 days? 60 days? — consider the author unreachable.
Serious issues with no responses for a long time lend weight to the notion that the plugin is abandoned. If there are no outstanding issues that have gone unanswered for even a few weeks, the plugin might be working properly.
Just my personal opinion, but as I wrote in my other comment, I feel we should default to requiring new names; the “burden of proof” is on the new plugin and its author that it really is an appropriate replacement if they want to use the old name.
-
@Coises said in POLL / Discussion: taking over a plugin:
Just my personal opinion, but as I wrote in my other comment, I feel we should default to requiring new names; the “burden of proof” is on the new plugin and its author that it really is an appropriate replacement if they want to use the old name.
A new plugin name is not ideal if you’re aiming for wide distribution, such as when the new version addresses a breaking change upstream. The Plugins Admin dialog will only suggest an update if the names are the same between the old and newer versions.
The unfortunate case of Elastic Tabstops is probably too rare to inform a guiding principle. I had early doubts about the new version, but only something like formal acceptance criteria would have found the defects before unsuspecting users did. In one respect, transferring the name with ownership made finding the defects more likely.
-
I’m not entirely sure how to vote on this because - if with the permission of the original author, I don’t think a new name would be required. However, any other option should have a new name
