WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 4 months ago

#16838 reopened enhancement

Excluding Akismet from Future WordPress Releases

Reported by: sc0ttkclark Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.1
Component: Plugins Keywords:
Focuses: Cc:

Description

This issue was more mute prior to the shift in Akismet's 'keying', which previously just required you to have a free WP.com account to hook up to the API. Since Akismet now charges for access, or solicits fees by default for Personal website activations (when you go through the sign up process, it defaults at something like $5 with a slider that lets the person choose how much they want to pay). It's not immediately apparent that 'free' is an option within the slider, but that's not the primary issue here - I digress :)

The issue is that Akismet is no longer free for EVERYONE. It's only an option for Personal sites, and in certain cases. What if someone has multiple personal sites? They click that option and they are categorized into a Professional plan, which has a fee associated to it.

Since the plugin directory itself has officially been described (and in practice) to have a restriction that explicitly prohibits functionality be disabled from a plugin behind a Paywall, why wouldn't that apply in this case?

I certainly don't mean to rock the boat, but this brings up a number of important questions.

The plugin has a potentially confusing signup process that does lead people otherwise categorized as Personal site owners, to pay for the service while it's advertised under the plugin description that it's 'free' for Personal use. This produces a grey area of sorts, which puts this plugin under a sort of Paywall, which could be alleviated in a minor way by modifying the signup process. It still doesn't clear the air on how the Paywall for professional sites can be officially allowed versus a full Paywall. Perhaps someone who officially represents the WP.org Plugin Directory or WP.org can clarify the undocumented (not shown at http://wordpress.org/extend/plugins/about/) Paywall restriction for future reference.

Besides the plugin itself now finding itself in this grey area, it's bundled with WordPress by default and presents what could be described as an unfair market advantage for Automattic's product offering, sort of like anti-competitive business practices. I feel weird saying that, but I'm not throwing stones here. Just saying what it feels like, even if the core developers say it should be included, I'd say it now doesn't cover the 70/30 rule (or whatever the amount is).

If Akismet is allowed to remain in the plugin directory as is, and within WP core, then would other plugins be allowed to be included in the plugin directory that follow the same Paywall model and signup process?

Change History (30)

comment:1 scribu3 years ago

There are several plugins in the wp.org directory that are "light" versions of paid plugins.
I distinctly remember Matt saying at one point that these types of plugins are welcome on Extend, as long as they provide at least some functionality by themselves.

The trouble with Akismet as it is now is that it doesn't do anything without an API key, so it's just a wrapper for a paid service. Are these types of plugins welcome now?

Let's say they are. Now, is it fair to bundle such a plugin in WP Core?

One can of course argue that by bundling Akismet, more revenue is generated for Automattic, which in turn can invest more in wp.org

Version 0, edited 3 years ago by scribu (next)

comment:2 toscho3 years ago

  • Cc info@… added

comment:3 jkudish3 years ago

hmm, these are some interesting points.

my 2 cents:

The trouble with Akismet as it is now is that it doesn't do anything without an API key, so it's just a wrapper for a paid service. Are these types of plugins welcome now?

I definitely think it still has it's place, as it always has in the plugins directory (it's always required an API key I believe)

Let's say they are. Now, is it fair to bundle such a plugin in WP Core?

No. Since it isn't a fully free plugin, I think it would be misleading to have it in core

comment:4 travisnorthcutt3 years ago

  • Cc travis@… added

comment:5 westi3 years ago

"The issue is that Akismet is no longer free for EVERYONE."

Akismet was never free for everyone - it was only every free for personal users and still is.

comment:6 nacin3 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from new to closed

My opinion on this is nuanced, and, I like to think, practical. I'm for the eventual unbundling of Akismet. But I think, as a practical matter, we need to make sure that users do not suffer in the process. There's a reason Akismet is bundled in the first place: spam is bad, and it's perceived as our problem by our users, and it's a problem we can at least try to offer a solution for. We first need infrastructure in place in various locations to handle better installation procedures and other features that can mitigate the practical effects of its unbundling.

I think there is a time and place for a future discussion. I don't think it's now, or on Trac. Ultimately, this decision needs to come from the core team. Therefore I am closing this as maybelater.

To answer potential critics now who may point out that at the moment a majority of the individuals on the core team work at Automattic, each individual earned their position here based on merit, not anything else, and their condition for being here in that capacity is thinking and acting independently. Potential for a conflict, sure. Actual conflict, no way, and I will verify that and stand behind that, as will Mark Jaquith. Mark and I have discussed Akismet at length (very recently, in fact) and we hope that this topic will come up again in the future when the time is appropriate. Possibly after some improvements in 3.2.

Also, no, Akismet should not be removed from the plugin directory. There is a line, and it's perfectly on the proper side of it. (There have been some recent questions with regards to other plugins, so perhaps we can work on enumerating more detailed guidelines.)

Last edited 3 years ago by nacin (previous) (diff)

comment:7 sc0ttkclark3 years ago

  • Summary changed from Excluding Akismet from Future WordPress Releases / Plugin Directory to Excluding Akismet from Future WordPress Releases

Okay great, we've got a discussion going that is leading to some answers. Why is it not time (now, as in the upcoming 3.2 schedule) and why is it not on Trac? What is Trac for? To discuss bugs, features, and enhancements, right? What am I missing in the process to getting a change to go through into WP core, being on the core team?

@westi - I was not aware of the non-free aspect of Akismet prior to the change, but it's certainly a different situation with the new signup process. By the way, the plugin itself wasn't always non-free, it appears prior to 2005 at some point an API key wasn't even required, which changed when the Automattic Spam Stopper plugin was renamed to Automattic Kismet / Akismet.

@nacin - There's a better way that's out there for handling the user's inherent need for a plugin to make up for issues that Spam can bring up. But how does someone outside the WP core team get this ball rolling the right way?

I wanted to clarify that the removal of Akismet from the plugin directory was stipulated if it was itself breaking the undocumented rule for plugins with a Paywall.

@nacin said: There is a line, and it's perfectly on the proper side of it. (There have been some recent questions with regards to other plugins, so perhaps we can work on enumerating more detailed guidelines.)

Great to know there's some leeway here, sad to know it's going to take a bit to have it fully documented in the Plugin 'About' page guidelines. There's been so many discussions about this I'm not sure why someone with WP.org access hasn't copy / pasted together the additional points necessary for the guidelines amendment.

The bundling of Akismet within WP Core may bring many features, but it could be argued that other plugins, one of which is maintained by Mark Jaquith, offer similarly important features for preventing spam without a Paywall. The bottom line is that WP has clearly headed in the direction that isn't explicitly tied to Automattic, like the Trademark transfer itself pointed out. I understand Automattic funds quite a bit of WP development, but it's inclusion of it's own Paywalled plugin (especially the signup process as is) seems to put itself in an unfair advantage within the eco system. It would be a different case if this plugin wasn't behind a paywall OR offered minimum functionality on it's own outside of the API that helped reduce spam. Since neither is currently the case, either Akismet should change or WP should.

comment:8 hd-J3 years ago

  • Cc contact@… added

comment:9 hakre3 years ago

IIRC Prior 3.1 release it was said that akismet will be removed after 3.1.

Related: #15769, #16100

comment:10 hakre3 years ago

Found it: "We will hopefully unbundle for 3.2." (Nacin 2 months ago)

Related: #16033

comment:11 follow-up: travisnorthcutt3 years ago

If it's not feasible to undbundle for 3.2 for whatever reason, what about eliminating the reinstall-on-core-upgrade behavior (for Akismet and Hello Dolly)? I know that's been discussed, but I'm not sure what the current status of that idea/path is.

comment:12 in reply to: ↑ 11 ; follow-ups: nacin3 years ago

Replying to travisnorthcutt:

If it's not feasible to undbundle for 3.2 for whatever reason, what about eliminating the reinstall-on-core-upgrade behavior (for Akismet and Hello Dolly)? I know that's been discussed, but I'm not sure what the current status of that idea/path is.

That's pretty much certain to happen.

comment:13 layotte3 years ago

  • Cc lew@… added

comment:14 in reply to: ↑ 12 hakre3 years ago

Replying to nacin:

Replying to travisnorthcutt:

If it's not feasible to undbundle for 3.2 for whatever reason, what about eliminating the reinstall-on-core-upgrade behavior (for Akismet and Hello Dolly)? I know that's been discussed, but I'm not sure what the current status of that idea/path is.

That's pretty much certain to happen.

I opened a ticket for that certain to happen task: #16862

comment:15 hakre3 years ago

As clarified by dd32 in #16862 and #14484, the ticket related to that task is acutally #14484. So that's a second core dev who is supporting that said change. This will hopefully show some traction with it.

comment:16 in reply to: ↑ 12 ; follow-up: MikeSchinkel16 months ago

  • Cc mike@… added

Replying to nacin:

Replying to travisnorthcutt:

If it's not feasible to undbundle for 3.2 for whatever reason, what about eliminating the reinstall-on-core-upgrade behavior (for Akismet and Hello Dolly)? I know that's been discussed, but I'm not sure what the current status of that idea/path is.

That's pretty much certain to happen.

This discussion was back targeting 3.1, yet 3.5 was just released. Might it be addressed in 3.6?

comment:17 in reply to: ↑ 16 SergeyBiryukov16 months ago

Replying to MikeSchinkel:

This discussion was back targeting 3.1, yet 3.5 was just released. Might it be addressed in 3.6?

The reinstall-on-core-upgrade behavior was addressed in #14484.

comment:18 aaronholbrook15 months ago

  • Cc aaron@… added

It's been two years and this somehow remains is a 'maybe-later'. I would like to push to see this unbundled from core, or at least having a full discussion surrounding this issue.

comment:19 travisnorthcutt15 months ago

+1 for readdressing this issue. @Nacin et al, is now a reasonable time to discuss this?

comment:20 MikeHansenMe15 months ago

  • Cc mdhansen@… added

comment:21 follow-up: chipbennett5 months ago

  • Cc chip@… added
  • Resolution maybelater deleted
  • Status changed from closed to reopened

Perhaps this could be added to the list to consider for 3.9?

Three years seems like more than enough time to figure out a path forward for removing a commercial Plugin from WordPress core.

comment:22 SergeyBiryukov5 months ago

  • Milestone set to Awaiting Review

comment:23 kopepasah5 months ago

  • Cc justin@… added

comment:24 jdgrimes5 months ago

  • Cc jdg@… added

comment:25 in reply to: ↑ 21 ; follow-up: daveshine5 months ago

Replying to chipbennett:

Perhaps this could be added to the list to consider for 3.9?

+ 1 for considering this for 3.9!
In the above discussion there are already mentioned a lot of aspects that go with it.
Still, there are more aspects tied to it, especially regarding the whole "privacy" topic. There are some countries (e.g. within European Union) that require website owners to declare all kind of stuff in privacy TOS pages. Akismet handling falls under that, for example in Germany. Also, since plugin is only free for private use, there's the problem that in some countries only a few website would fall under category "only private use". For example, blogs are a publication and would require full imprint/TOS pages, and therefore not considered "private". This could lead to a lot of conflicts.

So bundling the plugin should be avoided to not bring site owners in conflicts; the plugin should be optional in any way.

comment:26 in reply to: ↑ 25 ; follow-ups: Denis-de-Bernardy5 months ago

Replying to daveshine:

Replying to chipbennett:

Perhaps this could be added to the list to consider for 3.9?

+ 1 for considering this for 3.9!
In the above discussion there are already mentioned a lot of aspects that go with it.
Still, there are more aspects tied to it, especially regarding the whole "privacy" topic. There are some countries (e.g. within European Union) that require website owners to declare all kind of stuff in privacy TOS pages. Akismet handling falls under that, for example in Germany.

Akismet is hardly the only thing in WP core that flunks in this respect. There's also WP core updates which sends more home than is needed, plugin and theme updates which collect stats too. And, of course, let's not forget Gravatar and pingomatic. But this is a very old and bitter discussion -- it left open wounds awaiting to sprinkle gruesome puss all over the place.

The question on hand is whether to allow a commercial entity, irrespective of how in bed it is with wp.org, to bundle a commercial product in WP core.

The argument against (by an Automattician?) is a weasel-worded yeah, it's true, but hey, we need to replace it with adequate spam protection. If that's the only argument against, then please... it seems easy enough: cookies for comments, hashcash, done?

I'll happily supply my (proper) hashcash implementation if so.

If not, well, let's get real here: this will die out like the privacy-related discussions from several years back: yawn... troll... maybelater... beating a dead horse... yeah, horse is dead...

Suggesting wontfix, personally. Not that I think it should be in core. Just that I predict it'll stay in there. Just like update stats, gravatars, and pingomatic before it.

comment:27 in reply to: ↑ 26 daveshine4 months ago

Replying to Denis-de-Bernardy:

Akismet is hardly the only thing in WP core that flunks in this respect.

The difference to all that other stuff is, that Akismet is a commercial product, plus has the privacy issues on top of all that. This combination of these two aspects with Akismet is the problem here, I was pointing out above. In Germany for example, only a very very small minority of sites are considered private (b/c of what I wrote above), so the majority of site owners has to pay (which I have no problem with!). So, to avoid discussions and confusions, therefore I am suggesting to not bundle Akismet in the WordPress download package.

Last edited 4 months ago by daveshine (previous) (diff)

comment:28 daveshine4 months ago

  • Cc daveshine added

comment:29 in reply to: ↑ 26 ; follow-up: bpetty4 months ago

Replying to Denis-de-Bernardy:

we need to replace it with adequate spam protection

Akismet is bundled by default, however, it's never been activated and running by default. It's literally no different than if it hadn't been bundled to begin with, it just gives Akismet the unfair advantage over other free and commercial options it competes with (and this is part of the problem as well).

There literally isn't a single other free spam plugin that we could bundle that would actually be effective unless it also follows the same model as Akismet with using a 3rd party service to analyze and rank spam comments. Anything else would be defeated terribly within months of releasing it, and we'd be back at square one anyway.

I don't believe we have any requirement to provide another bundled replacement. I believe history has proven that there needs to be some diversity here, and with that, WP needs to have a requirement that it doesn't unfairly favor any single solution (by bundling it by default).

I'll happily supply my (proper) hashcash implementation if so.

Your hashcash plugin only works effectively right now specifically because it *isn't* bundled by default with WordPress. The second that changes is the second your plugin becomes useless for fighting spam. The same goes for Cookies for Comments. Trust me, you don't want that to happen any more than I do.

comment:30 in reply to: ↑ 29 MikeSchinkel4 months ago

Replying to bpetty:

There literally isn't a single other free spam plugin that we could bundle that would actually be effective unless it also follows the same model as Akismet with using a 3rd party service to analyze and rank spam comments.

Well, once WP-API gets incorporated into core a continuously effective peer-to-peer plugin could be implemented that would not require such a service. The peer-to-peer service could have a set of 10+ volunteer central servers like how the 10 root DNS servers work. And such a plugin would also potentially enable trackbacks to be usable again by allowing site owners to validate legitimate trackbacks using oAuth and block spammy ones.

Such a plugin could even optimize for spam by site topics/content and then outright block (vs. tag as spam.) For example, I have a blog about WordPress plugin development and posters who use the author name "Hollister Outlet" or "Abercrombie" should be outright blocked vs. tagged as spam. However having 'WordPress" in the name should not be a concern per se on my blog. But for a fashion blogger, the reverse is probably true.

A peer-to-peer plugin could even possibly orchestrate a denial-of-service attack on the spammer!
(Or not. I can wish. :)

Maybe this could be a potential Feature-as-Plugin? Having a viable alternative certainly would remove reason to ignore this ticket.

Anything else would be defeated terribly within months of releasing it, and we'd be back at square one anyway. … I don't believe we have any requirement to provide another bundled replacement.

I respectfully disagree with that. See above.

I believe history has proven that there needs to be some diversity here, and with that, WP needs to have a requirement that it doesn't unfairly favor any single solution (by bundling it by default).

Agree with that. Unless the solution is a core (and extensible) feature. Then I think a single solution is preferable; remember pre 3.0 vs. custom post types?

-Mike
P.S. BTW, I recently wrote a Spam Blacklist plugin because I was getting over ~500 Akismet spam-tagged comments a day on a very low traffic blog. The plugin mined the 100,000+ spam I had received to create a block list by author, IP, email and URL, and if blocked it throws up a screen offering to whitelist the person if they contact me.

It was a blunt force approach to solve my problem and has many issues so it's not a general solution but the core concept was to block (vs. just spam-tag) what is easily identifiable as spam on my unique blog given the history of spam on my blog and the topics I write about, and then letting the commenter know their comment was blocked so they can contact me to allow them to be whitelisted.

So I think having a peer-to-peer spam plugin architected and built for core that takes into consideration each site's content could go a long way to finally resolving the ongoing spam problem in addition to satisfying the concerns raised by this ticket. FWIW.

Last edited 4 months ago by MikeSchinkel (previous) (diff)
Note: See TracTickets for help on using tickets.