Now we’re a little further down the road of defining how the directory will work, it’s clear that these are really just 2 sides of the same coin.
If the ownership changes the GPG signing key must also change; it’s associated with a GitHub identity. We should send an email to the GPG key address periodically to confirm the user has access to that email address.
That doesn’t cover every situation - e.g. if a plugin is sold with the domain name - but when we find out they’ve not stuck to the rules we just blacklist that signing key. From there we decide what to do on a case-by-case basis - fork, de-list, verify, or some something else.
Abandoned plugins don’t get adopted, they get forked. This is a directory, not a repository, so it’s the only choice we have.
When a plugin is forked the directory will present the fork as an upgrade from the previous version; this is a perfect example of why dependency and update resolution must happen server-side.
This is all the technical side of things - how we determine if a plugin has changed hands, been abandoned, etc - still needs agreement. There will be plugins where no-one is interested in forking them; by default they’ll drop out of the search results even if they still work.
For example, if users report plugin X still works perfectly even though it’s not been updated in 8 years, I think it should show up in the search results with a clear description of its status - likely abandoned but reported working.