Handling Plugin Abandonment/Adoption

[Jeffro]

So the core WordPress team had a pow wow meetup and one of the things that was discussed passionately amongst them was the issue of plugin abandonment and plugin adoption.

http://wpdevel.wordpress.com/2011/01...-the-core-com/

I have many questions that I'd like to ask regarding this particular issue.

First, many users or developers complain that the plugin repository is filled with old code and plugins that have 3 inches of dust on them. From an ethical stand point, should there be an automatic way of taking abandoned plugins and putting them up for adoption? In my opinion, it would be very hard to consider anything automatic regarding the process as ethical which is why I believe the choice of adoption should be left up to the plugin developer.

The next question I have is, despite leaving the choice to the plugin developer, what if that plugin developer forgets or has no interest in putting their code up for adoption? After lets say one or two years of no updates, should the plugin developer be overridden allowing the adoption process to occur?

What if the plugin that was created behaves and is coded in such a way where no updates are needed for an exceptionally long time? Should plugin authors be forced to at least provide a minor bump to reset the time before adoption occurs? What if some plugin authors do this as a way to not give up their plugins but also not update them as well as keep them on the repository? I doubt this would happen but it's a possibility.

I was thinking that the system could incorporate a way in which some plugins would fall under certain circumstances would then be placed in an archived area of the repository that was not accessible to the normal plugin search both on the site itself and from the back end of WordPress.

It seems more and more that introducing any system such as the one I describe does nothing but introduce more problems and a more stringent way of doing things which is probably not good in the long run.

What is the simplest and most open way of accomplishing a good plugin abandonment/adoption system?

[johnkolbert]

Without reading the core teams opinions on it, here's mine:

Any plugin in the WP.org repository can be forked (Wikipedia link). In my opinion, this should be the only method in which a "take over" should occur. If a plugin hasn't been updated in a long time and you want to update it, fork the current code and create your own plugin based on the original.

Perhaps the WP admin area could have a way of notifying users if a plugin they are using has been marked abandoned and been forked, but this could lead to notification overload.

Of course, WP.org can remove plugins for any reason. They could set up guidelines such as if your plugin (or theme) hasn't been updated in two years AND doesn't support the latest version, then it is grounds for removal from WP.org. Developers should be given ample notification with time to respond before the removal occurs.

Just my thoughts on it.

[Ryan]

Most of my plugins have my trademark tacked on the front of the plugin name. If someone tried to claim it as there's without confirming with me that it was okay, that would leave us in a rather prickly legal situation.

[dgwyer]

When I was first checking out WordPress I was like a kid in a candy store, installing Plugins all over the place. It wasn't until later I realised that half of them would not work out of the box as they were outdated! Some of them I really wanted to try and was disappointed there was no automatic way to filter by the version of WordPress you are using.

Also, as there is soooo many Plugins around these days it would be good to filter out any that were not tagged as working with the latest version. Personally I wouldn't dream of installing a Plugin for WordPress 3.1 (when it comes out soon) that was last updated for say WordPress 2.8! Just wouldn't trust it not to break something.

I think this would be a pretty good way to encourage Plugin developers to keep their code updated with the latest WordPress version or at least tag it so people know it works with the latest version, even though the code itself does not need much updating (as may be the case for a lot of Plug-ins).

[trishacupra]

Great topic. One I've been thinking about myself.

First of all, there needs to be a way to limit the search results (by default) in the WP Plugin Directory so only plugins compatible up the the latest version (or higher, regarding great devs testing on betas) show up - with perhaps bit of a leeway for about a week after a new update, so you don't get 'no results' moments after a new update!

That would be a great incentive to active devs who want their plugins to show up in the search results.

But, you should still be able to change your search results to include all plugins.

Second, since all plugins in the directory are GPL, anyone else can pick up development (but by forking it with a new name). Matt himself forked b2 to create WP.

So, I see old abandoned plugins as an opportunity for new devs to pick them up and improve them, if they're at all salvageable.

But we really don't need ancient plugins cluttering up the directory when you do a search. It's just illogical and annoying.

What do you think?

[Ipstenu]

There would be a lot of grunt manpower involved, but take every plugin not updated since 1.x and check it. If it works, let it stay. If not, remove. Once you're done with that, do the same on 2.x

That should take the cruft down a bit.

But. I'm torn on the idea of adoption. In a way, I wish we could since that's the best way to get people using the OLD one to know that there's a NEW version. On the other? It's odd taking something over from someone else without talking to them. Maybe a line in your readme.txt that lets the developer say "If abandoned, this pouting can be adopted by anyone." or "If abandoned, just fork."

[Ryan]

TIn a way, I wish we could since that's the best way to get people using the OLD one to know that there's a NEW version.

Something could be written into the plugin updater to alert users that there plugin has been abandoned and recommend they shift to another one. A smooth upgrade path could even provided for them by simply having the forked version deactivate the old version and delete it automagically. So to the end-user it would be much like a regular upgrade, except they'd get a "change plugin" message instead of an "update" message.

[Ipstenu]

Wouldn't someone still need to edit the original plugin to get that alert in? Or ... Maybe a "related plugins" list that pops up when you upgrade? That reeks of advertising, and would be hard to maintain...

[trishacupra]

You know, that's very simple to solve.

Right now, on your plugins page, you get this meta information about each plugin - this example is Akismet:

Version 2.5.2 | By Automattic | Visit plugin site

You can see what's missing - it should include the compatibility information like this:

Version 2.5.2 | By Automattic | Visit plugin site | Compatible up to WP 3.0.4

Even better would be if it turned red if it was incompatible with your current version. Of course, just because it doesn't claim compatibility with the newest versions doesn't mean it's incompatible, but that's why I say leave it out of the search results if the dev can't update the compatibility info (How hard is it to do that? If it's complicated, it needs to be made simple).

Imagine you saw this in your Plugins section:

Version 2.5.2 | By Automattic | Visit plugin site | Compatible up to WP 1.5

That would stop you in your tracks and make you think, right?

[Ryan]

No, you wouldn't need to modify the original plugin. WP.org could maintain a list of plugins which have been forked due to inactivity, then WordPress would read that list and if you are running one of those plugins, it would serve a message suggesting you upgrade to the forked version. You wouldn't even need to make it obvious it was a fork, it could all be done seamlessly if it was deemed appropriate (personally I'd like to know if I'm moving from one plugin to a slightly different one though).