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].


#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.


#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.


#4

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


#5

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


#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:


Limitation of Liability
Plugin Directory Rules
Plugin Directory Rules
#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.


#8

Thanks, makes sense.