What is the etiquette around forking existing plugins?

[philpax]

We have a few people attempting to fork plugins that currently exist or have been abandoned. We should clarify what our position on this is, and what we're willing to help out with.

[MKhayle]

My sentiment there is that it shouldn't be supported (aka not included on main repo, nor receiving support about it in dev channels) unless the dev behind the fork respected some guidelines, as :

• The plugin must have been abandoned for X months OR
• The original developer accepted the fork to take over the spot of the new current existing version of the plugin OR
• The original developer explicitely asked for someone to take over the project indefinitely

In addition to these, if they submit it to replace the original plugin on main repo :

• The plugin must follow main repo guidelines (and abide by the general rules of the main repo)
• The fork developer abides by the guidelines (if they exist) that the original developer may have laid down
• The fork developer may not add a ko-fee/patreon/monetization thing in it without the consent of the original developer

I will, of course, have forgotten some edge cases, but most of them should be within this territory, feel free to add anything about it that I have covered yet

[reiichi001]

I somewhat disagree with Khayle's opinion.

Personally, I don't think there's hard in helping someone make a personal fork of a plugin provided their fork would also match our plugin guidelines. Otherwise, we'd effectively be locking users out from contributing to the plugins they enjoy.

Ideally, plugin forks should be treated and expected to be upstreamed in most cases, unless the developer/maintainer has already made a clear stance on not accepting outside help. (But that kinda defeats the purpose of FOSS and may need to be discussed separately).

In terms of forks as user should:

1. Fork the code
2. Make their personal dev branch[es]
3. Compile and test as a devPlugin
4. Push their changes to their repo
5. If it's something that they think could/should/would be upstreamed, make a PR

We have multiple plugins that can do some of the same things. (Owofy vs SillyChat is an easy example). I feel like forks of maintained plugins could in same cases be treated similarly, but further discussion on how to best separate "personal fork" from "fork and rebrand" may be needed.

In the event that the plugin in question is no longer being maintained, that's an entirely different topic and should be directed to discussion on incompatible plugins that @kalilistic has been working on.

[kalilistic]

I think we should allow for a scenario where someone makes significant changes to an existing plugin to the point it has novel features.

This will help bring healthy variety to our plugins and gives users more choice. For example, I haven't touched Price check in awhile. If someone came out with a new version with more display options and polish that would be okay to me. If they added one option and renamed it - that would not be.