@steve, yeah, . I was in that thread as it was happening and still feel bad about it.
This issue needs careful handling. I know Aria said it wasn’t just that conversation that made her decide to leave, but I understand why this point is so personal and important for her and other devs. In addition to that misunderstanding/conflagration, I’ve seen plenty of “vCv wilL sTeAl yOuR cOdE” comments outside this forum, which indicate that the existing policy is not well understood at all.
I’m assuming that we’re dealing with open-source plugins using one of the standard open-source licenses (GPLv3, BSD 3-clause, MIT, CC0, to pick the ones mentioned in the docs). I’m also assuming that the bar here is entry into the Library (which is how the existing plugin ethics guidelines are enforced), so out-of-Library enforcement doesn’t need to be considered. That’s actually helpful, because the Library isn’t that large and it’s maintained by a small group of reasonable, well-intentioned people. (@Squinky.Labs, I think that this is the step that prevents your Scenario 2; my understanding is that Andrew and @cschol , and whoever else has access to the Library repo, maintain the slug list manually, possibly with some script assistance).
I agree that a clear policy should be spelled out ASAP. With V2’s release approaching, this is about to cross from theory to reality over and over again. Below is an attempt at drafting one.
Andrew’s on record as saying that he’ll respect explicit language in the repo saying “don’t upgrade my plugins without my permission” (even if the language is outside the official license) so I think that case is clear; if a dev wants to be the only one who’s allowed to upgrade their plugin(s), they should say so. That seems fine to me.
So, for me the question is: what would a dev who was on an extended vacation during an API change, and whose plugins were upgraded, want to come back to? I think the sensible default is a minimal upgrade that they can regain control over at will. For that to work, I think Andrew and the library maintainers should create an explicit process for, essentially, fostering a plugin. It could work something like this:
- a version upgrade is taking place which requires that an open-source module’s source code be changed to be compatible, AND
- that module’s developer is unreachable, meaning they have not responded to X attempts to contact them over Y time period, AND
- that module’s developer has not opted out of this policy with a note in the module’s repository, THEN:
- With VCV’s approval, a volunteer developer will be allowed to fork and make source-code changes to the module before resubmitting it to the library under the same slug, AS LONG AS:
- The source code changes consist only of:
- Minimal changes necessary to allow the plugin to run in the new version of Rack;
- (possibly) Simple implementations of new optional features (such as bypassing and tooltips for V2), as long as those implementations are of high quality and do not involve significant new design decisions; AND
- Text is added to the forked repo indicating that the source code changes have been made in compliance with VCV’s “abandoned plugin” process and briefly describing the process.
- The original developer, if they reappear, is free to either:
- Adopt the changes and resume control of the project; OR
- Reject the changes and perform the upgrade themselves; OR
- Elect to remove the plugin from the new version’s library unless or until they perform the upgrade themselves (as if they had included “do-not-adopt” language in the first place).
- This process will provide an extremely limited exception to VCV’s “no-clones-without-permission” policy, as the fork will, from an ethical standpoint, be considered a community-based upgrade, not a clone.
A key point here is that without the original dev’s permission, those modules are only going to be given the minimum amount of attention necessary to make them run in (and maybe interoperate with) a new Rack version. Under the proposed policy, if a volunteer developer wants to take a project forward, they will need to do it in the normal open-source way, giving it a new name and identity (per the no-clone policy), crediting the original code, and asking for a new slug.
I’m sure there’s no way around this Again, from my perspective, the Library maintainers are the people who matter here. They’re the ones whose judgment is enforcing the existing no-clone rule. That’s also a judgment call, probably a more complicated one than what we’re contemplating here, and in my opinion it’s worked out quite well. The Library is full of official versions of hardware modules, many of them free; there are plenty of inspired-by modules which definitely aren’t clones; and, as far as I know, there aren’t any hardware companies who are currently angry at Rack. Even out-of-Library enforcement has worked; I think Andrew noted somewhere that Floats (as updated) would be allowed into the Library if its developer wanted that.