Excluding Akismet from Future WordPress Releases

[sc0ttkclark]

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?

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

But then, the same argument could be made for any WP-focused company, including theme shops.

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

"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.

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

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.

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

Related: #15769, #16100

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

Related: #16033

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.

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.

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

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.

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?

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.

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.

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