Handling Plugin Abandonment/Adoption

[Otto]

Side note: This isn't about "legality", as such. All plugins in the directory are GPL compatible (and if they're not, we'll just flat out remove them). So anybody can take them and modify them for any reason they see fit, within the terms of the GPL.

The question revolves around what would be the best way to handle such cases to best help the community.

I'd estimate that for 90% of them, the original author will likely respond with a "I don't care, go ahead and have somebody else maintain it" in which case it would be perfectly fine to simply grant commit to the new devs and let them have at it.

For the extremely rare case where the author says "no, I want to be the sole guy on it", then we'd very likely just tell the new authors to fork to a new plugin, without providing any upgrade path at all.

It's that other XX% where the author doesn't respond at all that is the question. And this is rare enough to be a question that is relatively unimportant in the grand scheme of things.

[chipbennett]

Side note: This isn't about "legality", as such. All plugins in the directory are GPL compatible (and if they're not, we'll just flat out remove them). So anybody can take them and modify them for any reason they see fit, within the terms of the GPL.

The question revolves around what would be the best way to handle such cases to best help the community.

I'd estimate that for 90% of them, the original author will likely respond with a "I don't care, go ahead and have somebody else maintain it" in which case it would be perfectly fine to simply grant commit to the new devs and let them have at it.

For the extremely rare case where the author says "no, I want to be the sole guy on it", then we'd very likely just tell the new authors to fork to a new plugin, without providing any upgrade path at all.

It's that other XX% where the author doesn't respond at all that is the question. And this is rare enough to be a question that is relatively unimportant in the grand scheme of things.

Can't the repository policy to be updated to accommodate whichever path is preferred (i.e. Option 1)? The repository is owned by WPORG (or Matt, or WPF, or however you want to look at it), and not the Plugin developer(s). Why can't the upload policy just state, "If a Plugin is abandoned (not maintained/supported/updated for X time period), WPORG reserves the right to give commit access to community members willing to continue development."

[Otto]

We can do anything we like, is what I was trying to say. The debate was over what is the *best* way.

[chipbennett]

We can do anything we like, is what I was trying to say. The debate was over what is the *best* way.

For what it's worth: I agree with your take on what is the *best* way. They're GPL Plugins in a community repository; forking simply due to abandonment is dumb. I'm just saying: let people know openly, and up-front - and then do what is best for end users.

[Ryan]

Method 2: Fork to a new plugin name/slug entirely and do something in core/backend-update-check to move users from the old plugin to the new one.

That is a more elegant description of what I was trying to explain earlier on.

If method 1 is used, then I'd go with Chip's suggestion about adding a brief notice somewhere during the plugin submission process so that authors know what may happen if they abandon the plugin. You could even mail bomb existing plugin authors alerting them that there has been a minor change in policy that they should be aware of.

With method 1 you so still have the slightly prickly situation of trademarks as I mentioned earlier, but that would be a rare situation, and since you mentioned that it's rare for this to even crop up anyway, it's basically a rare situation of another rare situation .... ie: it'll probably never crop up anyway so not worth factoring into discussion and the solution is simply to for the plugin.


My take on this: Method 1 is simpler and easier but could theoretically annoy someone, somewhere, sometime. Method 2 is more "correct", since it won't upset anyone. I'd be inclined to go with Method 1 though since it's easier and doesn't require adding more cruft into core.

[film_girl]

See, this just underscores why WP needs to work on moving away from SVN and other antiquated systems and onto Git (or if we want to me really awesome and and brazen, Mercurial). The genius of Git, especially with repos like GitHub is that watching, forking and merging branches is trivial.

So if I start a plugin and then don't touch it for a while, Chip can fork it and do his thing. Hey, I could come back, merge those changes into my trunk or just merge some of them. Or Ryan could come along and build his own off of Chip's branch or mine. And we could all look at what is going on on a very well structured graph.

I won't argue this makes it any better for end users who are using old or abandoned plugins, it wouldnt. But it would make the process of starting a fork of an existing plugin easier because even if you used a totally different name, savvy users could still follow the dots and see where it started from. If the Github (or Gitorious since WP is so down with FOSS and Stallman and whatnot) backend was just a "developer" view (IE, not what you see when you mainly interact with stuff now, just as the SVN repo is mostly obscured), it might not even add to the confusion.

Beyond managing forks, Git (using Gitorious or Github) would be an excellent way for developers like Dougal to let people know they made a change to their code and offer it for inclusion in the main branch. I might be AWOL and never see Dougal's patch, but Otto might and decide to either use Dougal's patch or roll it into his own fork he is building a promoting.

I talk to web developers every single day. By and large most love WordPress (unless they are Ruby diehards or have a real thing for Django or Python or whatever) but many of my most skilled contacts (like, either work for top development shops or do project quotes that start at 6 or 7 figures) rarely manage to give back a lot of their code (plugins created for clients or even side projects they do themselves) via the official repos because the process is too convoluted. They have to use SVN, which is fine except most already have the best shit in Github so that means remembering to push the Git changes to SVN too and it makes finding other devs to collab with way harder too. So many have whole ecosystems on Git that might get an occasional plugins update.

Now this goes beyond the scope of the problem, which is, how to handle abandoned plugins. I see both points in Otto's explanation, and while I tend to agree with him that moving someone to a replacement plugin seems, well, weird, I also understand the weirdness of having someone take my shit, change my name and get all my users, only for me to come back from Tahiti and go, yo, what the hell holmes. Edge cases to be sure.

Frankly as a user I'd rather see a pop-up that said, Plugin-X Has Not Been Updated in X Days. WordPress.org believes the plugin is abandoned and cannot ensure its future compatibility. Plugin-Y performs many of the same functions of Plugin-X and is currently maintained. Would you like to migrate to Plugin-Y?

Offer a quick DB dump of the old plugin as a download if you want to be super cool.

In any event, much of the front facing things are edge cases. What tends to happen with old plugins is that they break or stop working and users search for a new one. The smarter plugin devs include stuff like "fork of Plugin x" in the description or meta tags.

[Otto]

Git wouldn't make it any easier than SVN. Forking/branching, as a process in a repository, has nothing to do with what we're really talking about. What's being discussed is really more about the name/slug in the .org-plugin-namespace. That's it, really.

[WraithKenny]

From a user point of view, having old/abandoned plugins not show up in searches, and upgrade paths to newer (forked-or-adopted) versions (via the upgrade notices maybe) is the important parts. Keeping the old abandonware somewhere is great, but shouldn't be easily findable by people looking for up-to-date stuff.

I'm also OK with handing the keys over to new guys after a certain period. I'm not sure anyone was promised that the hosting was forever, to be stored without modification, and that the original owner "owns" the slug to his plugin... Notification to users and honest attempts at contacting the original author seem all that would be proper in a case of abandonment.

Any news on progress of this?

[Otto]

In order for there to be any progress, the issue would have to actually come up. It almost never does, most plugin devs want to write new code, not maintain old code.

[Elpie]

One point has been raised several times in this thread. It jumps right out at me - the issue of people not seeing the trail, and issue of plugin developers not keeping the original developer's name. This is something that has bugged me for a long time. WordPress plugin devs often show very little understanding of how GPL works, or what forking (or even taking over an abandoned plugin) really means. Original developers frequently don't include a copyright notice so later forks aren't always to blame.

But the thing about copyright is that it has to be owned by someone. Simply saying, "this is released under GPL version 2" is not enough. There should always be a clear trail back through the developers.

I betcha I could go to the repo now, grab a bunch of plugins, smarten them up, and release them saying I am the developer of xyz. When the developer comes along, screaming, the onus is on him to prove the work is his/her copyright. If the code never states who the copyright holder is they leave themselves wide open to their work being copyright by someone else. The copyright holder is the only person who can change the license too so its not as if there are no implications to ignoring notices.

There are very few plugins that can be traced back. Authoring names should always be included, and should always be kept. If a plugin is based on a work done by someone else credit should be given.

I also prefer to see plugin names changed when they are forked. Names get associated with the original copyright holder and forking, with a new name, provides more transparency.