19 Comments


  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.

    Reply

  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.

    Reply
  3. Ted Clayton

    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.

    Reply

  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.

    Reply

  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 WP.org 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, WP.org 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 WP.org 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…..?

    Reply
  6. Daedalon

    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.

    @curtismchalehttp://wordpress.org/plugins/wp-db-backup/ 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.

    Reply

  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.

    Reply

  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.

    Reply


  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 WP.org 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?

    Reply
  10. Ted Clayton

    @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. ;)

    Reply

  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.

    Reply


  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.

    Reply

  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.

    Reply

  14. @Otto – Yes, there is that downside to GitHub forking so that probably wouldn’t be appropriate for WordPress.org 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

    Reply


Leave a Reply