Could WordPress Plugin Adoption Lower the Rate of Abandonment?

photo credit: jono dot com - cc
photo credit: jono dot comcc

In light of recent events wherein plugin authors have been receiving suspicious requests for repository access, Mika Epstein posted a clarification on taking over plugins. The plugin team does not give out plugin author emails. Instead, the team acts as an intermediary to send the author an email, notifying them of a third-party trying to get in touch.

Her note also assures developers that will never give away a plugin unless they have received the author’s explicit permission:

Your plugin is yours. We will only close it if there are security issues or guideline violations, and we will always email you about that (so remember to keep your email up to date in your forum profile!). We also will never just give away your plugin without contacting you first, and getting your approval.

Developers who no longer wish to maintain a plugin are also urged to consider giving it away to someone else before requesting removal from the repository. There is a chance that someone may be willing to take the plugin on to continue it. But how will other developers find plugins that are up for adoption?

How to Put Your Plugin Up For Adoption

There are two simple things you can do right away:

1. Add a Note to the Readme.txt File
Epstein recommends updating your readme.txt file as a first step towards letting others know that your plugin is available to be adopted.

2. Add a Sticky Topic to the Plugin’s Forums
Andrew Nacin suggested that plugin authors create a sticky post in their plugin’s forum to put a plugin up for adoption and add a link to it in the readme.txt file. Interested parties can then comment in the forums and ask questions.

Both of these suggestions are useful if someone is specifically interested in your plugin. If the readme.txt and forum sticky are all developers have to depend on, it’s unlikely that someone will stumble upon your plugin with the intention to adopt.

A Standard Adoption Tag

In the followup comments to the post, several developers chimed in to suggest that a standard tag might be a good option. A plugin tag would provide a centralized way for developers to search for plugins that need a new owner.

For example, a “needs-takeover” or “adopt-me” tag could be applied to indicate the plugin’s availability. It might even be useful to have a separate tag to indicate that the author is looking for a collaborator, which could help connect developers and prevent orphaned plugins.

I asked Samuel Wood, better known as “Otto”, about the possibility of the project designating an official tag. He said that this is unlikely, given that tagging plugins is entirely voluntary to begin with and not something that you can organize with a standard:

Anybody can create and use such a tag and add it to their plugins, we don’t have tag limits on plugins like we do on themes. If somebody wants to make it an unofficial thing, there’s nothing stopping them from doing so, but I don’t think it will take off because it’s edge-casey and relies on authors giving away their plugins intentionally instead of simply letting them die from neglect.

If an unofficial tag is to catch on, it will require a group of developers with plugins for adoption to get behind their selected tag and help to make sure that others know about it.

Adopting vs. Forking

abandoned-pluginThe recent suspicious requests aside, would any WordPress developer actually favor adopting a plugin over forking it?

Alex Mills (Viper007Bond) doesn’t think that a list of plugins available for adoption would be of much use to anyone. “Mika’s suggestion of editing the readme to say so is probably better,” he said. “As it’s unlikely it’d be useful to have a list of plugins that need new ownership.”

While adoption has its benefits, including a built in user base and history on, forking a plugin is less of a hassle, since it doesn’t require permission. Forks also usually make a good number of changes right off the bat.

Last year Jeff Chandler wrote about the growing concern of abandoned WordPress plugins. As the repository is now approaching 30,000 plugins, the discussion continues.

Too much orphan-ware can quickly add up and paint a less than inspiring picture of the repository, which is frustrating to users who just want something that works.

Even if the incidence of plugin adoption remains low, every bit counts towards making the repository a better resource. If we can providing a clear path for adoption and better ways for plugin developers to collaborate, there may be some hope for lowering the rate of plugin abandonment.

Let’s hear from our readers. Would you favor an unofficial tag for adoption? Is it best left to readme.txt notices and sticky forum posts? Have you ever adopted a plugin or had one of yours adopted?


12 responses to “Could WordPress Plugin Adoption Lower the Rate of Abandonment?”

  1. If a rating and works/doesn’t-work system was built into the WordPress plugin list / framework, then could pull a plugin if it hasn’t been updated in X days/months/years *and* it gets too many “doesn’t work” reports. If it’s old, but it works fine, then no need to pull it. The current rating and works/doesn’t-work system on isn’t used by the majority of users, and so cannot be counted on for accurate metrics. A built-in system of reporting would be the way to go, IMHO. ;-)

    • The ratings/reviews aren’t that reliable, though, because sometimes people rate poorly because they wish the plugin would do something else. Or they review it as not working, when really it does work but they didn’t read the instructions to configure it or are having some kind of conflict. Ratings and reviews are too subjective to be useful in identifying non-working plugins.

      • I saw one plugin where the owner (IIRC a company with a premium version of the plugin) interacted with all low ratings to see if they could help the person. Obviously they wanted to protect their plugin ratings but I felt that it was a clever proactive move.

      • People rate poorly because they end up on the plugin page trying to fix their problem. People who *are* satisfied do not rate or report the version is “working” because they don’t have to go back to the plugin page on If the rating and work/don’t-work system was more easily available, we would probably see more balanced and accurate results.

  2. Here’s an interesting thought…. Say you wrote a plugin that does ABC, but because your readme, settings, etc. are all poorly written/documented, most (if not all) of your users believe this plugin does DEF. Would they be wrong in reporting the plugin “does not work” because it doesn’t do DEF? Should that plugin be pulled because everyone says it doesn’t do DEF, even though it might do ABC really well?

    What I’m trying to say is that maybe all “doesn’t work” reports are valid for different reasons — a plugin, after all, is more than just the sum of its code. ;-)

  3. If a plugin is truly abandoned, then forking is the only way to go (I just did this for a plugin in the repository, there was no response from the previous author).

    Forking makes more sense in general I think, owners that don’t have the time to maintain their plugins seldom have the time it takes to develop a relationship with someone new to get to the point of trusting them with their hard work.

    The problem of the repository going stale should be looked at separately, if a plugin really hasn’t been touched in 2 years for even minor updates (like testing with new version of WP and updating the readme) then perhaps it makes more sense to move them to an “Archive” repository that would be searched separately from the primary one.

    Movement between each repository would be automatic and would be an incentive to make sure you update your plugin at least once in a while.

      • That’s a good start, but it’s not enough I think. To users and developers it still looks like a single repository.

        I have a couple plugins I use that are flagged this way and it never occurred to me that they weren’t “in” the plugin repository. I never even noticed that you couldn’t search for them.

        Separating them even farther visually would help getting people thinking the right way about them. Perhaps a separate “Archived Plugins” menu item on, have a landing page in the main repository for archived plugins that “redirected” you to the archive repository and maybe force a manual download/install process in the archive repo.

        Any way, just some thoughts.

  4. I’m a plugin author with 7 plugins in the Repository, published over the last 18 months. I have seriously considered adopting a few plugins that could be easily made to work properly, but haven’t been touched by their authors for two or more years. But my definition of adoption is different. And might make acceptance by the author easier to come by.

    I always wanted to be another author, and wouldn’t dream of having the original author’s name removed from the repository listing, as he/she deserves the credit. Which is why I’ve generally shied away from forking.

    As for contacting the original author, allowing existing plugin authors who meet some criteria (e.g. – have updated at least one of their plugins — maybe just the readme.txt to say it works with the current version of WordPress — in the last 6 months) to do this themselves, with no intervention by WordPress folks. Without revealing the e-mail address of the original author, but with some feedback if the e-mail bounces, so they know the e-mail address is likely out of date, but definitely did not reach its destination, allowing them to try some detective work of their own to try and find the author. If this is not enough to prevent spamming, then some sort of automatic monitoring that shuts anyone down who contacts more than say a half dozen authors in a 48 hour period might work.

    But, in the final analysis, I’m just another person who hopes perhaps against hope that there is a way to improve the quality of plugins from the perspective of the person trying to just find a plugin that performs a particular function, install it, and forget about it.

  5. As a plugin developer myself I am guilty of letting a few of my early lesser used plugins slip into abandonment and I’ve added a message to the readme files to make it clear the plugin is no longer being developed but would welcome anyone wishing to adopt it.

    From the other side of the fence I have encountered quite a few plugins which would be of real value to me but which have not been updated in a long time or which have been abandon and are riddled with errors and don’t work in recent versions of WordPress.

    I have had moderate success in both adopting and contributing to old plugins by hunting down the author through various means starting in the forums, then moving to more detective work in Google and on Twitter to track down some recent contact details – a bit of determination and persistence can pay off.

    I have adopted and been given joint commit access to 2 plugins in the repository and forked 1 for which I could not track down the owner.

    I like the idea of an “adopt-me” tag but understand why this is not like to become official. No harm in using it anyway.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: