When a plugin is radically changed, what are the ethics/WordPress TOS?

Are there unstated ethics or applicable WordPress TOS that apply to this scenario?

As far as I understand, no.

As you correctly analysed the guidelines cover trademarks, security, not opted in tracking etc not functionality or amount of compatibility testing.

As all plugins are GPL then anyone can create derivative works of the earlier version and are under no obligation to use the updated version.

And as many user have been doing, if they don’t like the new version, leave respectful reviews of why they don’t like it.

I think there is an implicit danger in autoupdates of plugins, this as you described, where significant functional changes are made, or in some cases just mistakes in code breaking sites.

It’s not unheard of in such situations for someone to fork development of an older version as a “classic” version of the plugin. As long as all GPL provisions are met and the fork is substantially different than the current version, while I cannot speak for the plugin review team, I’d expect them to at least consider inclusion of such a fork in the WP repository.

Of course you need a new plugin name and there’d be no initial user base, but if there are enough disgruntled users, word will quickly spread through social media. Don’t spam the current plugin’s forum and reviews with links to the fork though, that’s not cool. Let social media do what it does best.

Autoupdates are great when security patches are involved. When major functionality is changed, not so much. We need to weigh the benefits vs. risks for our particular situation in deciding to allow autoupdating or not.

I was a big fan of the plugin auto-updates and used it for about 75% of all plugins on over 40 websites. Now I deactivated auto-updates for all plugins because I don’t want such a bad surprise again. I think a lot of people will lose trust in auto-updates and this is very sad because its a great feature to make websites more secure.

I asked the plugin review team about their opinion about this rebranding. This is what they answered:

`What plugin authors decide to do with their plugins is not really our concern. It may be unpopular, but unless it’s doing something actively malicious, it’s allowed.

The plugin changes may be unpopular, but that’s how things work. People can stop using the plugin or switch to another plugin. All these plugins are free, after all. We’re not paid for them. Nobody pays anybody anything, we only host a free repository here.

Also, remember that these plugins are all open source. The code is entirely free. If somebody wants to take the older version of the code and submit it as a fork for users to switch to, then that’s entirely plausible too…

Sometimes, you have to let people figure things out on their own. Simply telling a plugin author that a full overhaul with a bunch of new stuff is a bad idea isn’t really going to get you anywhere. They have to screw it up themselves and have the people tell them so, in order for them to figure out where they went wrong.`

I do think the biggest ‘victim’ here as you say, is loss in trust of the auto-update system.

There is not enough granularity for a plugin developer to indicate that it is a security update / minor update or major functional change.

This problem is rare, but when it happens on a popular plugin it can have a significant impact.

Another approach could be staged roll outs.

Premium deployment platforms already have staged roll-out capabilities, where a plugin author can specify a limit in % or absolute terms of users that will get a new release. This allows a popular plugin to release say 5% and see what the impact is. Not as a substitute for testing but as a safeguard against unexpected consequences.

The current WP plugin repo is an all or nothing thing – coupled with auto updates and popular plugins = danger.

@alanfuller @matthiaspabst @bcworkz I really appreciate you and the plugin team taking the time to reply. I definitely agree with the team in principle. My remaining worry is along the lines of Alan’s, that various classes of users may be at a loss when an unexpectedly large change happens.

Related to that, I wouldn’t mind seeing a “recalibration” of the prominence of old versions of plugins. I get the sense they’re purposefully tucked away to discourage reversion (one has to know to go to the plugin page, click Advanced View, scroll to the bottom, download the older version without being able to see its changelog, and upload/replace by FTP), when another option might be to have reversion functionality within the /wp-admin/plugins.php interface. And I’m not a developer myself let alone a security practices expert, but as someone responsible for multiple WP installs and who has to choose whether and when to update a plugin, I’m not sure I see a significant difference in value between an old version with a known security issue and a new version with inevitable unknown security issues.

Lastly, as a practical matter, the team’s suggestion that “People can stop using the plugin or switch to another plugin” often isn’t, well, practical. For many users at least. I’m sure that’s a common objection. Plugins become “sticky” as people build their sites and practices around them, and people often choose one plugin over another because it does something no other plugin offers. What’s that term from economics…friction? There’s a lot of friction in changing plugins, some big costs, whether you’re a single user, small internal team, or big external audience that have come to rely on certain functionality.

Anyway, thank you all again for letting me reboot a debate that’s been going on since the 1970s. ??

I agree. I just had a plugin “User Registration, User Profiles, Login & Membership – ProfilePress (Formerly WP User Avatar)” do a 180 change in what the plugin is for, and it auto-updated and is slowing the site down for a plugin that is no longer what it was intended to be when it was loaded.

More of a Bait and Switch by means of the auto-update system… Sad!

@doctormicro In fact, that’s the plugin that got me to start this conversation. That support forum had quite a few reactions. Here’s one of the three now-locked threads about it.

I think it would be a shame if this discussion focussed on one specific plugin because the value of this discussion is improving the overall community.

I can think of three possible solutions, in addition to my staged roll out suggestion ( well maybe 4 – but the 4th won’t happen )
1. have in core a ‘roll back versions’ capability as @andrew2968 suggests – there already is a roll back plugin of course https://en-gb.www.ads-software.com/plugins/wp-rollback/
2. have a staging environment built into core, where updates are done ( auto or not ) to staging and only when staging is signed off can the updates be applied to main
3. Have a granularity control on plugin ( theme ) autoupdates – were the plugin author can specify if they feel the update is suitable for auto update ( e.g. security fix ) or not ( e.g.major functionality change )

The 4th won’t happen and I don’t think it should happen, change the way the plugin repo is managed. The management process of the open source project is run by volunteers and they already have an unacceptable level of threats from bad people, related to the minimal control they assert over what plugin goes into the repo or stays in the repo. If they became assessor of what is acceptable functional change then that would only get worse, the conclusion being that you would not get volunteers so the ultimate result is the repo becomes a commercial market place, with authors paying to be accepted and I would guess users paying to have access – and that wont happen.

• This reply was modified 3 years, 6 months ago by Alan Fuller.
• This reply was modified 3 years, 6 months ago by Alan Fuller.

it would be a shame if this discussion focussed on one specific plugin

Indeed. If this thread devolves into grousing about that plugin, this topic too will be closed as unproductive. Even general discussion about what could or should be is a bit outside the intended purpose of these support forums, but as long as it benefits the community at large I’m willing to let it continue.