How To Adopt A Plugin Or Put It Up For Adoption

The other day, I was performing a plugin search for something to help me remove all the Post Revisions I had accumulated over the past few months as part of my clean-up process. Unfortunately, the plugin I used in the past was no longer available but it’s how I found that out that was the interesting thing. While the plugin was listed, the description said the plugin was empty and no long available. Just for giggles, I tried to install the plugin and nothing happened. Upon looking at the Trac changes for the plugin, the last thing the plugin author did was delete all the files. After getting in touch with Otto about the plugin showing up in search results, he removed it but told me it wasn’t the proper way to go about closing a plugin down. So what is the proper way?

How To Orphan A Plugin:

Plugin authors have the ability to not only add other authors to the commit team but also hand over the entire plugin to someone else. Removing all the code related to the plugin is frowned upon because someone else could use that code either as a fork or the foundation for a similar type of plugin. But if you really want to have your plugin removed from the repository, sending an email to with your request should do the trick. If a plugin author decides to orphan a plugin that I’m using, I would really appreciate it if in the last update, somewhere within the readme or change log it stated that it would be the last version released and that it would no longer be supported. This would give ample opportunity for me to look at alternative plugins.

Adopting A Plugin:

There currently is no official way to adopt someone’s plugin. There has been some discussion in the past about creating an orphaned plugin program but those ideas never materialized. One of the reasons why the program never saw the light of day is because there were so few people wanting to adopt a plugin. Otto recommends trying to contact the author, and if that fails, email the plugins team Show that you have code changes already made, as a good will thing, because what we don’t want is somebody taking over a plugin and making just superficial changes while putting their own name on it, sort of thing. So the plugins team verifies the code, tries to contact the original author, wait a reasonable time, etc.

WP Recycle:

There used to be a third party site that dealt exclusively with abandoned plugins called WPRecycle. It was an offshoot of but it looks like the website has since gone offline. I’m going to try to get in touch with those behind WPRecycle to figure out why the program failed or why the site has gone offline.

While researching for this post, I came across an article published by Matt Jones on the Digwp website. Even though it was a pitch for the WPRecycle program, he came up with a stat that showed 1/3 of the plugin repository at that time had the 2 year update warning. I wonder what those numbers are like today with 25,369 plugins in the repository.

It’s worth noting that a plugin update can occur with no code changes taking place. If only a readme file of a plugin was changed this would count as an update and would reset the 2 year warning.

Just What Is Abandonment?

It’s hard to talk about plugin abandonment because there are no hard set rules that dictate when a plugin is officially abandoned. This was one of the biggest problems the core team faced when they discussed the requirements needed for a plugin to reach this status. A plugin with good code that doesn’t need to be updated for extended periods of time could be considered abandoned even though it wouldn’t be.

Do you think orphaned plugins is a growing concern or is there a natural process in place that prevents this from ever becoming a serious problem? I would only consider it a serious problem if we reach a statistic where 50% or more of the plugins in the repository are abandoned. However, what if the total amount of plugins in the repository is 50,000 and 50% of those are dead? That still leaves us with 25,000 active plugins. What would the numbers have to be for a tipping point of users not finding the extensibility that has helped make WordPress as popular as it is today?

Let’s continue this conversation in the comments.


19 responses to “How To Adopt A Plugin Or Put It Up For Adoption”

  1. It always sounds like a great idea to update the readme file, but I have to admit that I almost never read them. I think that an admin notice about the last version with support is a much better option.

    Another issue we have (though I have no idea how widespread it is) is 2 year old plugins that don’t show up in search anymore, but work for their intended use just fine. WP-DB-Backup is a great example of that. Works just fine, but to install it you have to go to the .org repo and download it.

    I have no solution since the 2 year mark seems like a great way to tell if a plugin is still around but it’s not a blanket way to tell if a plugin is dead.

  2. @curtismchale – Yes, this is something Otto pointed out in our conversation:

    Yes, the yellow/orange 2 year old warning means that the plugin will not appear except in exact-match searches. If your search exactly matches the name or slug of the plugin, then I think it will still appear at the top of the list, but it cannot appear in a search otherwise.

    Of course, the author can just update the plugin to get the date updated, so the 2 year warning tends to be indicative of a plugin that hasn’t seen any change in a while. This doesn’t necessarily mean it doesn’t still work though.

    The admin notice sounds like a better idea of notifying users. As a user, I just want to be notified any way possible about the last version.

  3. Abandoned plugins tend to be a little extra-interesting, because they tend to be honest dork-ware.

    This category of software includes a disproportionate ratio of projects that were begun by someone who encountered an unfilled need, or opportunity, but who lacked well-developed skills with either programming in general, or coding within the WordPress environment in particular, or commonly both. And the time to continue a committment … really, the dominant factor in this dynamic.

    The dork-inventory is notably rich in efforts to address a narrow niche which will not lend itself to profit or fame. It is just not unusual to go looking for a nicely-defined functionality coded-up as a plugin, and find that it just plain doesn’t exist … or if it does (uh-huh/uh-oh) it’s old, unloved, and clunky.

    The original ‘idea’ behind such plugins tends to be free of the various ‘ulterior’ motivating factors that become the drivers of plugin development, within other common social contexts.

    So dorks tend to create plugins under more-idealistic motivations, but their implementation tends to be junk. But they also tend to use programming-techniques that are easier for other low-brow coders to follow; and which don’t necessarily have to be “poor” technique. I can actually see & tell what they’re doing, code-wise … unlike, unfortunately, some ‘proper’ plugins.

    Kinda-obviously, this situation has been recognize for a long time, since targeted efforts to at least save, preserve, archive these ‘nice try – no cigar’ plugins have been around for a long time.

    I myself keep a /plugins-arc directory in /wp-content, with several hundred entries, some long-gone from Extend. Periodically, I log out, rename /plugins to /plugins-off, and rename /plugins-arc to /plugins, log back in and perform an Update. Sorting the directory by Date shows what has remained untouched, and what is regularly Updating.

    [Populate /plugins-arc by first deactivating the titles to be archived, in Admin. Then login out and move each plugin directory to the /arc directory. Watch that your MySQL doesn’t get too loaded with abandoned Tables.]

    I know a lot of this stuff I archive is trash (even originally, and now badly outdated, to-boot), but it’s interesting trash … for which there is often in fact still not a good replacement, in the official WordPress repository.

    There are some strong upsides to simple dork-ware. It’s worth paying attention to, and saving.

  4. I know a lot of this stuff I archive is trash (even originally, and now badly outdated, to-boot), but it’s interesting trash … for which there is often in fact still not a good replacement, in the official WordPress repository.

    This harkens back to the question I proposed where the plugin repository has 50,000 plugins but 25,000 are considered dead, there are still 25,000 to choose from which is still enough to provide ample choice for a given piece of functionality, right? It’s interesting to hear that despite there being so many plugins in the repository, there are instances where one plugin fills a niche and one plugin only.

  5. As a plugin developer myself, there are several reasons my I might want to orphan a plugin.

    1) The functionality is now part of WordPress core.
    2) I no longer have the time to dedicate to maintaining support for a plugin.
    3) I lost interest in the plugin – it’s hard to be motivated to develop a plugin you’re no longer excited about :(

    In the first instance, that’s great, there’s no reason to continue using the plugin. My approach to this would be to add a message to the top of the readme.txt file to say that it is no longer required since WordPress version X and update the plugin so it automatically notifies the user in the admin or deactivates itself if appropriate. See Compact Taxonomy Checkboxes for example – I have just updated with a more descriptive message :)

    Having said this, there is no reason why someone may not want to take over the plugin and build on it further to enhance the WordPress core version of the functionality, so I think it’s important to make it clear in the message that you are willing to transfer commit access.

    In the second instance I would just add a message to the readme.txt as mentioned above so other developers are aware that I am willing to pass on commit access if someone else wants to continue development.

    It would be nice if a plugin could automatically display such a message, maybe if you tagged it with “seeking-committer” or something?

    That could then also be used to provide a list of plugins that are looking for people to contribute. That doesn’t just have to be orphaned plugins either. I co-contribute on a few plugins after approaching the authors and would like to see more collaborating like this in the community. It may help to reduce the likelihood of plugins being neglected.

    The main problem is those plugins where a developer seems to have just disappeared.

    I have actually re-written 3 plugins which had not been updated in ages. For each I have made numerous attempts to contact the original authors through any contact channels I could find which included a lot of Googling and detective work, still without any response.

    One of these I have since released as WP Mail From II, although it bugs me that I had to revert to doing this for such a simple plugin rather than the more practical solution of taking over the original plugin.

    I have actually since been contacted by that author so I may now be able to get commit access, but it does remain an issue that people do just drop out of the community, sometimes to the extent that they are completely un-contactable.

    I did contact to see if it was possible to take over the plugin and the advice was:

    The best path right now is to fork the plugin. Submit the new plugin for hosting as ‘wp mail from revisited’ or something akin to that, and we’ll review it and add it.

    Sadly, unless the original author wants to hand it over, we won’t do it for them.

    I completely understand that. The principle of forking a plugin is fine but it doesn’t help people who may be using that previous version of the plugin if that no longer appears to be maintained.

    Maybe as well as showing the 2 years message, might consider pointing users to a fork of the plugin if one is created? (I’m thinking a proper fork of the old plugin, not just another plugin with similar functionality)…

    …but then won’t want to be seen to be ‘recommending’ certain plugins.

    If it was more like GitHub, developers would be able to fork old plugins and old plugins would reference plugins that had been forked from them. Now there’s an idea…..?

  6. I have no solution since the 2 year mark seems like a great way to tell if a plugin is still around but it’s not a blanket way to tell if a plugin is dead.

    @curtismchale shows 14 people saying that it works on latest WP versus 2 who say it doesn’t. This statistic can be used to decide whether a plugin should be hidden or not. If at least two out of three say that it works, it should be worth listing.

  7. @Ben Huson – Ben, I can clearly understand where you’re coming from when you say “several reasons my I might want to orphan a plugin.”

    I plan on killing a few plugins which can no longer be used and loading some of the others on Github / giving it up to other developers who are interested.

  8. @Ben Huson – The “we won’t do it for them” varies depending on the case. I have, and will, do exactly that if the case warrants it.

    However, I do tend to go to somewhat extreme efforts to track down the original plugin author first, giving them months to respond, trying alternative venues like email, twitter, facebook, blog posts, and yes, I’ll resort to snail mail if I have to.

    We really don’t want to take anything away from somebody and have them come back and be pissed at us, so I’ll verify with certainty if at all possible.

  9. @Otto – Thanks for clarifying. I completely understand and agree that ideally you shouldn’t take anything away from anyone.

    It’s one of the reasons why GitHub forking is great as it’s easy to discover other branches of a plugin if development on the one you’re using seems to dry up, but doesn’t take anything away from the original author. I’m guessing won’t be heading that way anytime soon?

    You say you’ll resort to snail mail – that really is going the extra mile :)
    Have you actually had to resort to snail mail before?

  10. @Jeffro

    This harkens back to the question I proposed where the plugin repository has 50,000 plugins but 25,000 are considered dead, there are still 25,000 to choose from which is still enough to provide ample choice for a given piece of functionality, right? ‘ ‘

    Do you think orphaned plugins is a growing concern or is there a natural process in place that prevents this from ever becoming a serious problem? ‘ ‘

    No, dead plugins in the repository are not a ‘real’ or ‘actual’ problem, because the objection to this type of ‘plugin-litter’ is primarily of a moral character.

    First of all, because there are 25,000 plugins in the repository, obviously we do not look at ‘all those plugins’ (dead or alive) to find the one(s) we want. By definition, ab initio, we in every real sense do & must ignore the presence of 99.99% of all the existing titles, live ones & dead ones alike. Long before we hit the first 5-digit count, the day was gone when we could ‘look through the plugins’.

    Secondly, usage of the repository falls into several readily-recognized strategies. In the most common cases, folks either; (a), know the one they want because they read a recommendation for a given plugin, by name; or (b) they want one because their friends or those they think are cool have it, and they want it too (by name); or (c) they have recognized/identified a issue, enhancement or functionality by name, and search for those plugin solutions that address the topic-of-interest, by name.

    People who are browsing Extend, comparing collections of topically-related plugin-titles, building lists of search-terms into the repository (for giggles) … are all fairly advanced operators, none of whom (and more you can lump with them) are impaired or inhibited in their chosen activities, by the presence of abandoned plugins, even at high percentages. No more so than all the jillion uninteresting, repetitive articles on Google News, which we just surf right on by, no problem.

    Let’s mention here quickly, that besides orphan-ware, we also have several kinds of plugins that are up-to-date, properly-made and work as advertised … but which can pose a variety of real, objective hazards to those who use them. Dead-ware is pretty-well inert, but in fact there are ‘live’ plugins that can actively give us headaches, gut-aches, butt-aches, etc.

    The person who notices the abandoned or outdated titles in the repository and ‘reacts’ to this simple reality is usually displaying nothing more or less than good-old-fashioned “moral indignation“. “What is all this – this crap doing in here!?!”. To which Mr. Spock would logically & correctly answer, “It’s not doing anything. Obviously. Why do you ask?”.

    There can be strong frustrations that come with managing any web-presence. It’s been a long time since WordPress was a ‘small, simple’ blogware. Who has not been tempted to rip the entire computer outa the wall and heave the damn thing through the window? Just speaking rhetorically, of course.

    What finer scapegoat could you ask for, than ‘Those – those stupid dead plugins all over the place!!’?

    Put the computer down. Relax. Abandoned plugins are not a moral outrage. ;)

  11. One idea that should be looked at is splitting the main repository pool into 2 or more sections.

    Any plugins which have not been updated for 2 years should be in a separate search pool for those who want to leave them out of searches. That single action would simplify plugin maintenance for most of us.

    This might be a little bit like having specialised search category that filters out plugins by last update if there is a field or some other item that could be flagged to do that.

    All the plugins would stay on the repository but some would get more traffic than others.

  12. @Tal Galili – Wow I even commented on that article :) Well, fast forward to 2012 and we are still talking about the very issue you brought up. I think abandoned plugins are just a by-product of open source development. Do you have any additional thoughts on the issue?

    @Jason Kemp – This already happens. If a plugin is not updated within 2 years, it will be de-listed from normal search results. The only time you’ll come across it is if you search for the exact plugin name or come across the exact page for the plugin.

  13. @Ben Huson – Not had to use snail mail yet, but damnit, I care. ;)

    As for Github, I often find exactly the opposite. It is *frequent* that I run across some project on Github that is a clone of a clone of a clone of a badly made clone, and finding out the original project is an unbelievable exercise in frustration. Git’s very nature of “copy the repo” only really exacerbates the nature of this sort of thing, which is annoying in any open source project to start with.

    Forking of plugins doesn’t happen often enough to be a particular issue, since most plugins that people would want to fork are supported well enough by the plugin author that they accept patches and such. It’s pretty rare that we get asked to take a plugin over. As I told Jeff, I can only think of like 5 or 6 times that this has occurred.

  14. @Otto – Yes, there is that downside to GitHub forking so that probably wouldn’t be appropriate for where there is already a large amount of plugins with similar/crossover functionality – being able to easily fork these may just lead to even more confusion and overlap.

    What about the idea of standardising the use of some tags like “seeking-committer” or something so that authors could ‘advertise’ in some way that they are looking for help with a plugin.

    I know that this would not necessarily be a sure way to eliminate orphaned plugins as it would still rely on an author adding this tag, but it may provide a way to promote more collaboration among plugin developers? I guess we could just start doing it and see if it takes off and standardise it if it seems to become used.

    Could also use tags like “seeking-translator” etc


Subscribe Via Email

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