Plugin Adoption/Takeover Rules

#1

First draft of plugin adoption/takeover rules are below

There are two types of plugins which are available for adoption:

  1. Plugins tagged by the developer as available for adoption.
  2. Plugins which have been abandoned by their developer are eligible for adoption.

Plugin Adoption
Plugin developers who will no longer be developing/supporting a plugin are encouraged to put the plugin up for adoption; this is done by adding the Adopt tag to the plugin.

To adopt a plugin, you need to make reasonable attempts to contact the current developer and request to adopt the plugin. The following methods may be avenues of contact:

  1. Send an email
  2. Leave a comment on the plugin support page
  3. Open a GitHub issue

The current developer can transfer ownership of the plugin within the plugin directory and GitHub; once you have ownership of the plugin you can work with it as you would a plugin you started from scratch.

If you do not hear back from the developer in a reasonable time (such as three weeks) you can follow the Takeover procedure outlined below.

Plugin Takeover
To takeover a plugin, you need to make reasonable attempts to contact the current developer and request to takeover the plugin. The following methods may be avenues of contact:

  1. Send an email
  2. Leave a comment on the plugin support page
  3. Open a GitHub issue

The current developer can transfer ownership of the plugin within the plugin directory and GitHub; once you have ownership of the plugin you can work with it as you would a plugin you started from scratch.

If you have made a reasonable attempt to contact the developer and not heard back, the Plugin Directory moderators can reassign ownership within the Plugin Directory.

To be eligible for takeover via moderators, one or more of the following conditions must be met:

  1. Critical or important security issues exist which the developer has refused to fix.
  2. The plugin has not been updated for more 2 years (updates include supported version number being updated).
  3. The plugin is tagged with the “Available to Adopt” tag.
  4. No active developer is listed.

However, before you contact the moderators, you need to do the following:

  1. Create a new GitHub repository.
  2. Update the code to current standards, fixing any issues (particularly security issues).
  3. Any major amendments to a plugin must include upgrade steps for current users so that sites are not broken when upgrading.
  4. Submit your completed code to the new GitHub repository.
  5. Email details of the new repository and amendments to the Plugin Directory moderators at [email protected]

Moderators will review the changes and then make attempts to contact the current plugin developer to enquire about allowing takeover using the developers contact information available in the Plugin Directory. If the original developer does not respond in a 14 day period, the plugin may be reassigned in the Directory by the moderators.

Takeover may be rejected for one or more of the following reasons:

  1. The requested plugin is deemed too high a security risk; such plugins may instead be removed from the Plugin Directory.
  2. The plugin contains a trademark, copyright or project name held by the current developer.
  3. The requesting developer does not have sufficient experience for the complexity of plugin.
  4. The requesting developer has had multiple rule violations.

If the original developer rejects the adoption request, this will be honoured, except in the following circumstances (when the moderation team reserves the right to reassign the plugin):

  1. Critical or important security issues exist which the developer has refused to fix.
  2. The plugin has not been updated for more than 2 years (updates include supported version number being updated).

If a plugin takeover is unsuccessful, then a fork is an acceptable, and recommended, alternative.

Questions around adoption/takeover of plugins can be made to the Plugin Directory moderators via email at [email protected].

7 Likes

#2

Really nice job drafting this document, @azurecurve! I would expand it a little so that more than just abandoned plugins can be adopted. Sometimes, a developer wants to move on from a project. Developers should be able to flag those plugins as adoptable without having to formally abandon them.

4 Likes

#3

Good point, I forgot about that. A mechanism for it is definitely needed.

I’ll see if I can get it updated at lunch time.

3 Likes

#4

I have updated the original post to add a section for adoption; the section that was originally there has been renamed to takeover.

3 Likes

#5

I’ve added a line about forking being acceptable and recommended if takeover is rejected.

4 Likes

#6

I’d like to add 2 points to the discussion:

  1. Plugin ownership change

You should add a rule regarding change of ownership. Plenty of times when WordPress plugins changed hands, new owners updated plugins with malicious code causing nothing but trouble. Display Widgets plugin is one example.

Maybe ownership change should trigger code review, but not at the commit when new owner is listed, but a randomly picked version in near future.

And, if plugin is found to have malware, it will be rolled back to a clean version but bumped up in version number to trigger update notifications. Removing infected plugin from repo doesn’t remove plugins from infected sites, which is what happened with Display Widgets. There needs to be a better way to mitigate this for users.

  1. Abandoned plugins

There needs to be a policy for abandon plugins. First, at a certain point they should no longer be available (3-4 years without updates maybe). Second, it would be good to have a policy to re-assign ownership of an abandoned plugin to a willing and verified developer to take over maintenance of the plugin. Original owner should be contacted 3 times, and if they don’t respond or they do agree to it, then ownership will be reassigned. I think something like this was discussed before for WP few years back, I vaguely remember it.

  1. Bonus: Limit liability

As any agreements, you should limit CP’s liability. WP doesn’t have anything, but that doesn’t change the fact that all agreements should have limited liability/discalimer clauses. It should at least limit CP’s liability when plugin is removed and developer suffers profit loss, so they can’t sue. It sounds crazy, until it happens. I’d rather be crazy than sued :joy:

3 Likes

Plugin Directory Rules
Plugin Directory Rules
Limitation of Liability
#7

Excellent points @viktor. Note I’ve moved your reply to another thread, since we were already talking about adoption/takeover rules here specifically, and the majority of your reply is about that.

1 Like

#8

Thanks, makes sense.

1 Like

#10

One thing to point out about “abandoned plugins”: How to determine that? Is it just estimated whether the plugin is not being updated anymore for X years? Because that does not really work out - there are quite a few plugins around that simply do not need updating, eg. the Regenerate Thumbnails plugin (not updated for over 8 years until recently), which “just work”.

cu, w0lf.

1 Like

#11

In another thread, it’s been discussed that the readme (or equivalent file) will/should get a version bump indicating that it has been tested with the latest version as new CP versions are released. In this way, even plugins that don’t require actual code updates can avoid falling into abandonment status.

2 Likes

#12

In the suggested rules, I included that a plugin that hasn’t been updated for 2 years, critical issues exist which the developer refuses to fix, no active developer is listed or the plugin in tagged to be adoptable.

If the issue is it hasn’t been updated in more than two years, but the developer is contactable and says “no” to the takeover then it couldn’t be adopted as it is not abandoned. If the dev isn’t contactable then it has been abandoned.

3 Likes

#13

Cool. Thats indeed a nice, easy way out of that dilemma :slight_smile:

cu, w0lf.

0 Likes

#14

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.

6 Likes

automatically bumped #15
0 Likes