Jetpack, I wish I could love you

Dear Jetpack: I really want to love you, but you make it so hard

Jetpack, I wish I could love you
Logo from

When I first heard about Jetpack, I was excited about the potential for features to be shared with users. It seemed like a clever setup with its various modules in one plugin. But Jetpack just keeps managing to get under my skin. A little gripe here and a little gripe there typically isn’t enough to get me upset, but Jetpack consistently disappoints in a variety of ways.

Let me preface

I am using Jetpack on this site. I really love some of its features. My favorite is the new gallery carousel. You can see it in action below. I’m not trying to rail against all things Jetpack. I’m just trying to make some notes, and express some frustrations.

Jetpack is not completely free.

Sure, I don’t pay money for Jetpack. But Automattic gets to advertise paid products, like VaultPress, via Jetpack. Jetpack also requires me to have a account even if I don’t want to use any of the modules that actually require such a connection. There is inherent value to Automattic in that registration, and a slight loss of privacy for me. And privacy is valuable.

From what I can tell, only four modules need to function:
  • Stats
  • Comments
  • Subscriptions
  • shortlinks – and I’m not even sure this one requires it

Why do I have to have a .com account so that I can use a few modules like latest tweets, After the Deadline, shortcode embeds, or gallery carousels? That’s frustrating. I’d love to enable these modules for a lot of client sites, but it’s just rarely worth it when I have to create them a account, which they don’t need, won’t use, or even understand. Not to mention, it feels “icky”, for lack of a better word, that I have to connect to .com for features that shouldn’t require it.

edit: according to Matt on a Jetpack blog post, 10 modules connect to .com. See the links in the comment below.

Jetpack could get some major feel good points by letting me use it without a .com connection for all the things that don’t need a .com connection.

Some good plugins have been sent to the graveyard

You may tell me I’m being unreasonable for the connection to .com, and tell me that if I don’t want to connect, use something else. After all, there are plenty of alternatives! And you’d be right. There are alternatives, but some of the best plugins for these functions are the plugins that got gobbled up into the Jetpack version.

And when they got put into Jetpack, they stopped development on the non-Jetpack .org version. Here are some that have done so:

But these were all Automattic plugins, quit complaining

You’re right. Each plugin above has Automattic’s name on it. These are plugins that people liked and relied on. With Jetpack, each plugin has discontinued support on the non-Jetpack version (as far as I can tell – or they’ve said so themselves). To my knowledge, none of these require connection to in order to function, yet I must now have a .com account to use them. Sad.

To me, this goes against the very first statement in Jetpack’s launch post: has grown into one of the most amazing cloud architectures in the world. This has enabled blogs hosted here to have features unavailable on self-hosted WordPress installs.

Breaking WordPress UI best practice

People look up to Automattic and the work they do. I know I do. It makes me sad when I see them breaking the rules we so often try to encourage following in the .org world. The Jetpack UI is a prime example of this in action.
Jetpack needs to be brought down a notch Lead Developer Mark Jaquith created a plugin called Menu Humility to get Jetpack to chill out. Think about this, is Jetpack really more important than my posts tab? I think not.

Also, Jetpack likes to depart from traditional WordPress settings pages, and standard notifications UI. When you activate the plugin, you get a big cloudy box on the dashboard and plugins pages telling you to connect to You can disable it, but it deactivates the plugin. Compare that to the Gravity Forms nag to update with the traditional mild yellow warning box. Gravity Forms is much less obtrusive.

Once you go to the settings page, it presents itself in a completely custom manner, and does its best to make it hard to find where to deactivate modules. (hint: click “Learn More” and the “configure” button changes to “deactive”).

Here are some screenshots of these things in action:

Oh yeah, and most of this stuff auto-activates

Jetpack has a bad habit of assuming we want every new feature. Until they came out with the comments integration, they were auto-activating every new feature. Even features as big as the Grunion contact form integration.

I think it’s safe to assume most websites had a comment form solution figured out, but Jetpack figured they’d autoactivate it anyway. That enduces slightly more than mild frustration. I mean, they could have at least done a check with is_plugin_active() for say, Gravity Forms and Contact Form 7. It’s not like millions of people use those or anything.

In yet another defensive move against Automattic plugins, Mark Jaquith released Manual Control to prevent this assumptive behavior by Jetpack. Unfortunately, only a couple thousand inside-baseball WordPress fanatics are likely to know about that.

Mark Jaquith’s plugin banner for “Manual Control”

Hopefully, hopefully, Jetpack got the message on this behavior though; because to their credit, both Comments and Carousels didn’t come auto-activated. But I’m not sure if it’s because of community revolt or the revolt that would have happened if they hijacked every Jetpack users comment forms. Either way, thanks for not doing that on those add-ons, Jetpack. Let’s keep it that way.

Some “Woah” moments

Some aspects of Jetpack aren’t really related to “Grrr, this is evil”, but just unexpected behavior that bothered me a bit.

When I turned on Jetpack comments to try them, I was surprised that it replaced my entire comment form, and anything else that was hooking into comments. So I lost my buttons that allowed people to subscribe to comments and whatnot. Not that big of a deal, but kindof disappointing.

Jetpack also somehow connected to the wrong .com account, and apparently my stats were for my domain, but connected somehow to a domain I set up Jetpack on for a friend’s site. I didn’t know it until I was getting errors by would-be commenters, who couldn’t comment. When I reconnected under the proper .com account, I lost all my .com stats : ( Mega sad-face. Now my end-of-the-year email about how my blog did will be even more depressing. I’ve been told that this is not near as uncommon as you may think.

Oh, have you enabled Jetpack comments? Go to a post in incognito mode or while not logged in. Leave a test comment. It’s even better if you try it from a slow connection. When you submit, the entire page redirects to, and back again. That was pretty frightening to me when I first saw it. Who knows what a random commenter would think: probably that something wrong happened, before they click out of your site.

I had another client at work I was setting up a latest tweets widget for. This isn’t the hardest thing in the world, but I wanted to use a service I thought would stay up to date with Twitter’s inevitable api changes down the road. I chose Jetpack, only to realize I was in trouble. See, our dev sites are password protected. To use the tweets module, I had to connect to .com (see above for why that’s super annoying). Well, I couldn’t connect to .com because the site was password protected. So that means I can’t style this simple tweets widget! Grrrrrrrr. Perfect example of why I shouldn’t have to connect to .com for front-end facing stuff that doesn’t need it.

Is Jetpack getting a special privilege to be in the .org repository?

I am no legal or license expert, and I really hate getting in on such debates. However, just reading the plugin guidelines for, it seems Jetpack skirts awfully close to the limits on a number of things.

I don’t want to spend too much energy on this topic, as it’s not my primary point of contention with Jetpack. But I’d encourage you to read both the posts and comments on both WPCandy and WPMU regarding the business importance of Jetpack for Automattic.

I wonder if other plugins that require connections, like the WP App Store, and WooDojo, would be allowed in the repository. If I had to guess, they’ve probably tried. Are they really that different than Jetpack? if WP App Store only acts as a storefront and isn’t offering anything for free, then that’s flat out against the plugin guidelines, but WooDojo is basically the same as Jetpack. I wonder why it’s not in the plugin repository.

And I find this tweet interesting:

I should say I know zero inside information on these topics, but I think it’s worth bringing up.

I’m not just trying to bitch

Jetpack, I really want to love you. Really, I do. But these issues just add up. And they keep me from activating Jetpack on all of my client sites. I’m sure that’s not a big deal to you, since all the big hosts install it automatically. I’m only one person in about 2 million downloads.

But I look up to Automattic, and I really like everyone I’ve ever met that works there. I have an enormous appreciation for what they do for the WordPress project. This appreciation extends from the newest employees that have done great things for .org in the past, to Matt. I didn’t write this post to start a flame war, or incite controversy. I just want to publicly express my feelings about Jetpack – why it’s dissapointing right now, and let you know I think it could be great. But it’s not right now. Maybe a couple of people agree with me.

I expect a little better from you. I’m sorry if that comes off as harsh.