JetPack: WordPress.org hypocrisy or how power gets you perks?
Last year (2010) there was a flare up regarding plugins done by MaxBloxPress. You could not use those plugins without opting in to the authors email list. This caused lot of annoyance with the users and the plugins were removed. The MaxBlogPress plugins in essence required unnecessary registration with a third-party to be able to use features that were standalone.
And here we go again another debacle, at least I think so. Some people in the WordPress world get away with stuff that others don’t.
Introducing JetPack
JetPack requires the users to create an account on WordPress.com and register their sites with WordPress.com before the plugin becomes active.
The plugin even gives the impression that all its features require WordPress.com to be able to work.
JetPack is nagging, with a HUGE box
The problem with all this is that not all the plugin features requires access to the WordPress.com API.
The following features are standalone i.e does not require WordPress.com integration:
- Sharedaddy
- Twitter Widgets
- Gravatar Hovercards
- After The Deadline
- Shortcode embeds
- LaTeX
The only features that actually make use of WordPress.com are Stats and WP.me shortlinks. So we have six features that do not require WordPress.com and just two that do.
In my opinion WordPress.org should require the plugin authors, ie Automattic et al, to remove the requirement for WordPress.com registration for features that don’t actually require it. You might ask why, well not doing so is in my opinion hypocritical. Others have not been allowed to have plugins that uses “optin for no reason” in the WordPress plugin directory, why should this plugin be allowed too?
Is the JetPack way a good user experience? Is this a practice that should be allowed in the WordPress.org plugin/theme directory?
Voice your opinion in the comments.
The beauty of open source and the GPL is that anyone could split these features out into their own, non WP.com versions. It’s an added, annoying hassle, but it is possible.
Also, many of the features are already available as separate features:
- Sharedaddy
- Twitter Widgets
- After the Deadline
- Shortcode embeds
- LaTeX
The only non-API feature that’s not a standalone plugin is hovercards. But that can be added with a couple of lines to your theme, and a lot of us have been doing that for a while already.
All of this is beside the point, though. In principle, I agree with you that it’s a dangerous double-standard to ban one system that requires an external registration for no reason but allow another just because it’s distributed by the major players in the WP ecosystem. That said, I am using JetPack on one of my sites … it’s easier to install/maintain one plug-in than it is to install/maintain 8 … and I already had a WP.com account for stats.
Eric´s last [type] ..Re-Evaluation
Actually Gravatar Hovercards is standalone its in the plugin directory. Haven’t located a standalone LaTeX plugin. The one that comes with JetPack communicates with WordPress.com via on demand image generation. Don’t need the site to be registered though for it too work.
Automattic’s stand-alone LaTeX plug-in lets you use either their server or your own local LaTeX setup: http://wordpress.org/extend/plugins/wp-latex/
I just hadn’t seen the standalone hovercard plug-in yet. So, really, it looks like you can get everything JetPack contains separately …
Eric´s last [type] ..Re-Evaluation
The same goes for Akismet and their Stats plugin which both need an API key, and they have been available from the official plugin repository for ages.
I really think that users should decide if they want to use such a plugin — be it registering for a third-party API or a mailing list. I guess that Matt will argue that API key is different because it provides part of the plugin’s functionality while email addresses are used solely for marketing.
The issue isn’t the fact that an API key is needed. There is nothing wrong with requiring an API key if your plugin interacts with a 3rd party service which both Akismet and the WordPress.com Stats plugin do.
Don’t mistake API key for License Key or Activation. An API key is standard practice when interacting with an API and those plugins don’t work without interacting with that API. The anti-spam functionality of Akismet doesn’t happen within the plugin code itself, it interacts with the Akismet servers via the API and to do that it needs to have an API key to interact with the service.
There is nothing wrong with that.
The issue with JetPack is the majority of the features do not require WordPress.com interaction in order to function because they are self contained plugins that don’t interact with a 3rd party service. Only a few pieces of JetPack require WordPress.com interaction… and that is when the API or activation functionality comes into play.
The issue is rendering the entire plugin useless unless you connect with WordPress.com despite the fact only parts of the plugin actually require this in order to work.
If the entire plugin didn’t work without WordPress.com integration because of API usage, it would be perfectly fine. But that isn’t the case.
It imposes artificial limitations and makes it seem like you have to have a WordPress.com account in order for all of JetPack’s features to work when in fact… you don’t… but they force you to if you want to use JetPack.
If you or I did that with a plugin, do you think it would be approved in the repository?
IIRC, *none* of the MaxBlogPress code actually needed registration to function. The problem with these was others plugins made to bypass that reg. requirement.
A plugin utilizing third party stuff is fine if it actually needs it. The MaxBlogPress plugins required the user to sign up for a spammy affiliate marketing mailing list. That is the issue, not the third party requirements.
No, I don’t think so.
I knew that people will start arguing about registering for an API key vs. anything else, for that matter, as being two different things.
In theory, I could have a plugin that needs an API key for requesting a precise time and date from my server. Is it reasonable? No! Who’s will decide it?
Secondly, I must provide WordPress.com with my email address to use this plugin and I must agree to WordPress.com TOS. Why can’t my plugin include registering for a service with different TOS?
Oh, and I just noticed that when registering for a WP.com account they allow me to “Subscribe to our blog to learn about new themes, features, and other news.”
How is this different, exactly? Are WP.com TOS better than any other TOS?
@Kaspars: Yes, but subscribing is optional.
I took a quick look at some of the MaxBlogPress plugin code. The problem there is that the plugin is disabled until you go and sign up on their mailing list, at which point it sets an option from 1 to 2 to “turn on” the plugin. It doesn’t do any information transfer. There’s no API key. Those plugins don’t communicate with home base in any way. they just make you sign up for a spammy mailing list.
I consider that to be substantially different from a plugin that actually contacts an external service to get its work done. Even when the plugin doesn’t need to contact the external service for every single feature.
Take my own Simple Facebook Connect plugin for example. Not every “sub-plugin” actually takes to Facebook. The SFC-Follow widget, for example, does nothing more than make a widget which shows an image with a link in the sidebar. That’s it. But it’s useful for some, so I included it. You don’t technically need to set up a FB App just to use that widget, but it’s part of the package, so why not?
Jetpack may not technically need the WP.com connection for all aspects (or even *most* aspects) of the plugin, but it needs it for some of them. None of the MaxBlogPress plugins need an external service for *any* of their functionality. That is a non-trivial difference, IMO.
There is nothing wrong with having your plugin dependent upon an external service. There is something wrong with requiring your plugin to sign up users for unnecessary spam. This isn’t about open source or any of that, it’s about not hosting spammy BS plugins on wordpress.org, and I’ll stand behind that every time.
@otto
Philosophy or not it is a double standard. I see no difference between forcing a user to sign up to email list and forcing a user to create an account they don’t need. Both ways also gives you access to the email so you can send emails to the users.
Also its not spam if you agreed to get it. Thats the whole point of the can-spam act.
It is a trivial difference. Its a matter of principles really. Don’t force wp.org users to create accounts unless they actually need too in order to use the plugin i.e the plugin as a whole uses external apis etc.
Twitter Widget, Sharedaddy, Hovercards, LaTeX, and Shortcode Embeds are self contained and don’t need a WP.com account to work (that I can tell from inspecting the code) but the way JetPack works is NONE of it works unless you first connect it to your WordPress.com account.
Don’t response that it’s all one plugin so it’s ok. Acting like the various elements of JetPack are really one plugin is silly. They aren’t. They are individual plugins bundled together to activate together.
There is no reason why they couldn’t have enabled the functionality that doesn’t require WP.COM integration out of the box and then only required WP.COM integration for the pieces of functionality that actually, you know, need it.
@Carl: “Decisions, not options”.
It is possible that in the future they’ll make the wp.com aspects of that plugin more optional. I cannot say. I know exactly as much about it as you do (really).
That said, the “simple” aspect of it falls very much into the WordPress philosophy. If 80% of users are going to want to use the stats, then you don’t make it an option, you just do it.
You can disagree with the philosophy all you like, but it is written down as such. Users prefer things to “just work”, not to have to configure a bunch of options themselves.
Otto:
The problem isn’t that Plugin components are enabled by default; the problem is that the Plugin *could* have been written in such a way that the non-WPCOM-API-dependent components worked *out of the box*, and only the API-dependent components required WPCOM activation before they would work.
There is absolutely no programmatic reason that the non-API-dependent Plugins MUST remain deactivated just because the API-dependent components aren’t active.
Two other problems:
1) I have used WPCOM Stats Plugin for years, without this unnecessary “connection” step. It wasn’t necessary as part of the stand-alone Plugin, and technically isn’t necessary now.
2) I strongly suspect that, at least eventually, the *only* version of each JetPack component that will continue to be updated will be the JetPack version, and that the stand-alone version will cease being updated.
The bottom line here is the double standard. Automattic are being allowed to engage in practices in which other third-party developers are prohibited from engaging.
Chip Bennett´s last [type] ..Incorporating the Settings API in WordPress Themes
Grateful that this point was raised. I don’t know, but suspect that a lot of folks already have a wp.com login. I was simply pleased that so much functionality could be had so easily, thrilled actually.
And I suspect that most folks might feel the same way and then not give the closer scrutiny found in this post and comments. It’s great to hear dissenting views and alternative perspectives.
I see the point, but I think I will just get back to work and share the good news with my clients.
Yeah thats kind of the problem. Most see the point but like the plugin so accept the solution.
It would be good if there was better guidelines for what is acceptable and what is not. From this plugin experience we now know that combining non-free stuff with free stuff is fine.
There are dozens of plugins in the repo that require third party services to do their work. That has never been an issue.
Combining multiple plugins into one to provide a unified experience has also never been an issue.
Don’t confuse the issues. MaxBlogPress was (and is) *SPAM*. Simple as that.
Its not the issue we’re discussing.
And this is also not the issue we’re discussing.
No one is. The issue at hand is combining plugins and requiring the user to create user account for standalone features that does not require it.
Quoting you from the MaxBlogPress discussion at WPTavern
The same goes for WordPress.com. The whole thing can be as a way to inflate the WP.com user count and collect emails to potential customers.
MaxBlogPress were not spam. Bad practice but not spam.
Spam is unsolicited bulk emailing. Everyone signed up and confirmed subscription to his email list. He had a double optin list etc, no violation of the CAN-SPAM act. Anyway the discussion is not about MaxBlogPress behavior but wp.org and Automatiic.
That definition is overly simplistic and I do not agree with it.
Yes, because it’s such an evil thing for Automattic to offer everybody a bunch of free functionality and server time for stats collection. What evil geniuses they are, to, for the mere act of getting an account, to give you all this free code for you to run! Why, with your email address, then they could actually send you email, if you opted in at signup time! Those diabolical bastards!
Seriously?
Again, there’s nothing wrong with requiring a third party service. Even you admit that Jetpack actually *uses* their servers to do the work. Maybe not all of the work, but at least some of it. That isn’t marketing, that’s functionality.
@otto
If you agree with it or not is a mute point. What I wrote is the definition of spam. You can’t just make up your own definitions and then discuss from that standpoint. Thats postmodern pseudoscience. http://en.wikipedia.org/wiki/Spam_(electronic)#E-mail
You have to give them your information. You give personal information and you get stuff. Thats not getting things for free. And what they do is the same as MaxBlogPress did. You disapprove of MaxBlogPress but argue from a position that the Automattics way is for some reason holier and beyond reproach.
And for the last time I have no problem with that.
It is marketing if you require registration for functionality that does not require it. Its obvious that JetPack is used as leadgeneration. And now with their 99 dollar transfer service its even more obvious.
And another, somewhat-related question: what makes JetPack so special that it warrants a top-level Admin Menu entry?
Why isn’t JetPack subject to the same guidelines – as written in the Codex – to which every other Plugin is asked to adhere? To wit:
JetPack is nothing more than a meta-Plugin. Shouldn’t it put its menu entry under “Settings”, or perhaps “Tools” or “Plugins”?
Chip Bennett´s last [type] ..Incorporating the Settings API in WordPress Themes
Dudes,
I think you’re overreacting here. Let’s look at the facts:
1) The JetPack plugin requires a wp.com account to activate stuff even it doesn’t need (the parts that don’t need to connect to wp.com).
2) There’s an issue about menu placements, etc.
3) It seems that the issue of the MaxBlogPress was/wasn’t the same: there’s no agreement to this.
Keep in mind:
1) You don’t *have to* use JetPack. If you don’t like it, opt out. There’s functionality you can have without JetPack installed.
2) “You give personal information and you get stuff. Thats not getting things for free.” Since when is an email address currency? You can create another email and never check it, period. Or you could set up a filter to remove emails to trash.
3) Automattic, for good or bad, is giving additional functionality. That’s not a bad thing. So they concluded that MaxBlogPress’s email list was spammy; I’m sure they did it in the interest of their users.
4) If you know some PHP, maybe you can edit the JetPack plugin (it’s GPL, right?) and disable the parts you don’t like.
Don’t get me wrong, it is good & healthy to see differing points of view, but let’s not get carried away. Whether it’s a matter of “philosophy” or not is somewhat beside the point. Let’s not drown in legalese and be practical.
@el.tio.ska
1) Keep in mind you didn’t have to use MaxBlogPress plugins. And the standalone plugins in JetPack will be discontinued.
2) Emails are currency, personal information is currency. Just think of Facebook and its privacy policy changes, check out Google and their AdWords policy with regards to use of Free and email optins.
3) Automattic didn’t conclude it. The admins at wp.org did. It was not the spam claims that got it removed.
4) I have no interest in the plugin at the moment. There are Twitter rumors that the connection requirement was an “oversight” and it will be “rectified” in future version. So future will tell is forking is needed. It shouldn’t have to be because from my perspective the plugin inclusion goes against wp.org praxis.
You don’t *have to* use Jetpack? Are you sure?
Today a some wordpress sites such as mine didn’t display the wp-stats and instead the following message showed:
Your WordPress.com account is not authorized to view the stats of this blog. Currently access to stats is broken for some users and we are working on fixing this. Your stats are still being counted and will be visible once we restore access for your account.
When you google it, a hoard of sites come up with a so called “fix” to the “bug”.
What is the fix?
Install Jetpack.
Coincidence?
Thats weird. Probably due to the change in activation procedure. Not enough testing.
So we now have: “Future upgrades to WordPress.com Stats will only be available in Jetpack”. Anyone know of a stats plugin which won’t require Jetpack?
I have the same issue as Kim . . . future upgrades to stats only available in Jetpack, yet that’s the only part of Jetpack I’d be interested in . . . so why am I forced to have a “heavier” plugin than I need????
There is JetPack Lite (http://wordpress.org/extend/plugins/jetpack-lite/) containing only Stats and WP.me Shortlinks modules. All other modules removed (files and code), but it still requires you to set up an account with WordPress.com and give them your details.
One reason for running a self hosted blog is that you are in a position to control access to your own data, rather than handing it to a third party.