Opened 14 years ago
Last modified 7 months ago
#16838 reopened enhancement
Excluding Akismet from Future WordPress Releases / Plugin Directory
Reported by: | sc0ttkclark | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 3.1 |
Component: | Plugins | Keywords: | needs-refresh |
Focuses: | sustainability | 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 (56)
#3
@
14 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
#5
@
14 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.
#6
@
14 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.)
#10
@
14 years ago
Found it: "We will hopefully unbundle for 3.2." (Nacin 2 months ago)
Related: #16033
#11
follow-up:
↓ 12
@
14 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.
#12
in reply to:
↑ 11
;
follow-ups:
↓ 14
↓ 16
@
14 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.
#14
in reply to:
↑ 12
@
14 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
#16
in reply to:
↑ 12
;
follow-up:
↓ 17
@
12 years 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?
#17
in reply to:
↑ 16
@
12 years 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.
#18
@
12 years 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.
#19
@
12 years ago
+1 for readdressing this issue. @Nacin et al, is now a reasonable time to discuss this?
#21
follow-up:
↓ 25
@
11 years 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.
#25
in reply to:
↑ 21
;
follow-up:
↓ 26
@
11 years 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.
#26
in reply to:
↑ 25
;
follow-ups:
↓ 27
↓ 29
@
11 years 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.
#27
in reply to:
↑ 26
@
11 years 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 suggestion to not bundle Akismet in the WordPress download package.
#29
in reply to:
↑ 26
;
follow-up:
↓ 30
@
11 years 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.
#30
in reply to:
↑ 29
@
11 years 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.
#32
@
9 years ago
Whenever it comes to Akismet in germany, you can read it's illegal or needs customization like using this Plugin: https://wordpress.org/plugins/akismet-privacy-policies/. If you don't plan to drop it, maybe include this plugin for german language users or talk to Frank Bültge (He is a german WP-Developer) to commit these changes to the source code of 'original' Akismet.
#33
@
9 years ago
- Milestone Awaiting Review deleted
- Resolution set to maybelater
- Status changed from reopened to closed
@Presskopp: I would recommend contacting Akismet directly to voice your concerns: https://wordpress.org/support/plugin/akismet
Restoring the maybelater
designation here. Tickets do not need to remain open for discussion to continue.
#34
@
8 years ago
8 months gone without reply
https://wordpress.org/support/topic/excluding-akismet-from-future-wordpress-releases?replies=1
#35
@
8 years ago
- Resolution maybelater deleted
- Status changed from closed to reopened
Yeah, but thank god we got Emojis meanwhile. I think that was missing for most of us. :-/
#36
follow-up:
↓ 38
@
8 years ago
- Resolution set to maybelater
- Status changed from reopened to closed
As noted in comment 33: Tickets do not need to remain open for discussion to continue.
No discussion explaining why this is a good decision to make has taken place. If you would like to present some new information that would cause a different decision to be made, please comment with that information rather than reopening the ticket.
#37
@
8 years ago
Also worth noting that the support topic should rather be called "Add privacy policy" (something Akismet would need to change) instead of "Excluding Akismet from core" (something core would need to change) and I think that's what Drew meant above.
#38
in reply to:
↑ 36
@
8 years ago
No discussion?
Sorry, but right from the start people made clear that it´s kind of unfair/a thin line to walk on if Automattic is allowed to bundle its plugins with the WP Core, while no one else would have that chance. No matter whether Automattic puts that money back in the development of WP or not, there are lots of companies making money with/through WP.
This is even more problematic as it is not quite clear whether you have to pay for the license or not. As mentioned before, people could have more than one blog and could then be hit by the rating as a commercial site.
Furthermore there are legal problems for probably all countries in the EU. Most users are not aware of these legal problems, which you could see as the users problem, but I see quite some responsibility on the side of Automattic, too. It´s like putting a loaded gun somewhere and then saying you could not expect that people would find and fire it. It´s just naive and a bad excuse to say it´s just bundled but not activated from the beginning on.
Removing Akismet from the standard bundle is a core task. Just drop the akismet folder and it´s done. Whether or not Akismet should be improved and get a privacy setting or whatever. That doesn´t matter regarding the aspect whether WP is clean from the beginning on or is already "bloated" with stuff from people/companies who have influence in the development process.
#39
@
8 years ago
The key question is "Why is Akismet included when no other company's plugin is included?"
Maybe the alternate is to ask "What criteria should the community use to decide what plugins should be ADDED to WordPress core?"
It should be a different ticket, but we could easily add it and discuss there.
#40
@
8 years ago
I don't see the good sense in shipping a plugin, which users from the EU-countries, especially Germany, will not use, or if they do, even get the risk of punishment by law!!
It's not Akismet is good or bad itself, it's the ground where you put the seeds.
The logical step in my eyes is cutting it out, maybe leaving a message "To protect your site from spam, we offer Aksimet blabla..."
I don't think it's like a loaded gun, but when WP is a sexy hitchhiker, then Akismet is the troll coming out of the shrubbery the moment you stop and open the door ;-)
#41
@
7 years ago
- Keywords needs-refresh added
- Resolution maybelater deleted
- Status changed from closed to reopened
To bundle Akismet in some countries involves legal issues regarding the storing of sensible data of users. And, furthermore, not make sense to include a plugin that requires a registration in a third party service.
Is a comparative grievance with other plugin developers and companies.
We all love Automattic and Matt involvement with WordPress but this is an incongruity and must be excluded for future releases ASAP
Hugs!
#42
@
7 years ago
I agree that this is a really easy thing to fix and it is sending the wrong message.
No company should have any privileges to use the core as its own personal marketing space.
The reason that Automattic and Matt are who they are makes this more important to fix.
Hughs too!
#44
@
7 years ago
I agree with @fernandot, @expertoswp and @bogdanpreda as well as @sc0ttkclark and @jkudish. Akismet should be removed from the WP core since it is a paid service, and no one has that privilege, besides it involves legal issues.
It is simple, WordPress.org is free and Akismet is not. If we follow that path, why not to bundle any other paid plugins? As @Presskopp said, Which would be the criteria for bundle plugins into the core?
#47
@
2 years ago
Akismet is already a featured plugin. I still continue to believe that bundling Akismet with WordPress isn't that much different from people discovering it from the Featured plugins on the plugin add new screen.
I like what Akismet does and I'm a fan of the idea behind why it was included originally -- but we've proven over time that no other plugin meets the criteria for bundling.
Akismet has enjoyed it's historical placement. Why wouldn't we bundle a security plugin with so many sites getting hacked/malware infected? If we don't bundle other plugins for these kinds of reasons, then we have no choice but to move forward with unbundling Akismet in a future WordPress release.
#48
@
2 years ago
+1 to reconsidering this. Deciding which plugins are "critical" sets up a system of winners and losers. @sc0ttkclark makes a great point about security which, depending on the user, could be argued is a much greater threat to the average WordPress user.
#49
follow-up:
↓ 51
@
2 years ago
@sc0ttkclark
Why wouldn't we bundle a security plugin with so many sites getting hacked/malware infected?
Why wouldn't we? Well, if Automattic were to acquire a security plugin that had a monthly subscription upsell then I am sure a justification for bundling that plugin with WordPress would likely emerge.
#justsaying
This ticket was mentioned in Slack in #core by presskopp. View the logs.
2 years ago
#51
in reply to:
↑ 49
;
follow-up:
↓ 54
@
2 years ago
Replying to MikeSchinkel:
Well, if Automattic were to acquire a security plugin that had a monthly subscription upsell then I am sure a justification for bundling that plugin with WordPress would likely emerge.
#justsaying
Looks like that didn't happen when Automattic acquired WP Scan, though.
I don't think that kind of "assumptions" really serve the purpose of this ticket.
As said during today's devchat, this proposal needs a decision from WordPress.org leadership. The ticket will be mentioned in today's devchat meeting summary so we'll hopefully get some news from project leadership soon.
In the meantime, let's keep this ticket open for discussion :)
This ticket was mentioned in Slack in #core by peterwilsoncc. View the logs.
2 years ago
This ticket was mentioned in Slack in #core-privacy by paapst. View the logs.
2 years ago
#54
in reply to:
↑ 51
@
2 years ago
Replying to audrasjb:
I don't think that kind of "assumptions" really serve the purpose of this ticket.
It's not an assumption. He's using logical deduction to make a point. It's not correct/useful to the discussion, to frame it as an assumption.
He's saying that if we accept the argument/justification for keeping Akismet bundled with WordPress - then that argument can be extended (at any point in the future) to justify including other plugins from the same source. Using the already-accepted justification, or even a stronger justification (eg. if it's a security-related plugin).
The fact that this has not happened until today, is neither here nor there, as far as the argument/justification for keeping that door open goes.
It's a privilege. In the Latin sense: a private law. An individual exemption.
This ticket was mentioned in Slack in #core by presskopp. View the logs.
19 months ago
#56
@
17 months ago
The WordPress Foundation, a 501(c)(3) Charitable Organization, operates this website. Its mission states:
The point of the foundation is to ensure free access, in perpetuity, to the software projects we support.
Its project are, without ambiguity:
- WordPress (which links to WordPress.org)
But its projects are not:
- Akismet
- Jetpack
From IRS.gov:
A section 501(c)(3) organization must not be organized or operated for the benefit of private interests, such as the creator or the creator's family, shareholders of the organization, other designated individuals, or persons controlled directly or indirectly by such private interests.
If I'm not mistaken, it wouldn't be permitted to give special treatment to commercial software and services. Promoting non-commercial community-driven software, such as bbPress and BuddyPress, is allowed.
I think removing Akismet from being preinstalled, and removing it and Jetpack from the Featured plugin list/category would be in line with the organization's requirements.
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.