Why I don’t have a problem with Jetpack

Want that magical tl;dr? Jetpack is for users, not developers.

I don’t know if I’m madly in love with Jetpack, or if I’m ever madly in love with a plugin, but with all the negative things I see from the WordPress development community on a regular basis, and some genuine interest in this topic, I figured I’d write about why I don’t have a problem with it. To be honest, I roll my eyes a little bit when I see yet another round of abuse from my fellow developers. I use it, my husband uses it, WordPress.com uses it, and so long as I remember to be a user, it’s great. My frustrations, like many of those of others, only come when I start approaching it like a developer, much like how I get frustrated with my MacBook Air only when I realize that 4GB of RAM wasn’t, in fact, enough at all and I can’t replace/upgrade it myself. If I really want to care about that above all else, then maybe I better not be an Apple user 🙂

Jetpack is not made for developers, and I don’t think it pretends to be. With that line of thinking, I believe it’s just a bit silly of us to get all affronted as developers so long as it’s secure and the codebase continues to mature, just like with any other project. It’s the kind of plugin that’s made for people who almost don’t know what a plugin even is, and have no concept of what others mean or disagree when we throw out our beloved “plugin territory” line when looking for something they want their site to do. Try reading some feature requests on core Trac sometime, and those come from people who managed to figure out to come to Trac! Anyway, as I always say, these users just want it to “clicky-clicky-worky”. I think Jetpack does just that the vast majority of the time, and technical annoyance points like some new modules auto-activating or having to connect through a WordPress.com account are a part of that successful behavior. We’re a vocal minority, you guys, and we should recognize that.

Most users, especially ones just getting started with the web, have a pretty standard set of things that they want their site to do, and it’s smart to put those common desires together in a one-stop-plugin. If Jetpack claims to be for everybody ever, then maybe-probably I’d have a problem with that. I’d also be surprised if a plugin started claiming anything at all 😀 I don’t think Jetpack exists to make your life as a developer easier, and while I’m sure/know that there are myriad ways in which it could be better for developers, I think it does need to be recognized that there is a focus on user-facing features and that time spent by Automatticians tends to go there. Maybe we can get in the spirit of open source and contribute back as developers when we find pain points (especially those of us who have to use it in replicating an environment), or maybe we can expect more for free, or maybe I don’t know what, really.

Getting my more technical complaints out of the way just so nobody feels as though I am criticizing them for being a critic (because I’m not – criticism is healthy, even when I personally might think the volume a little silly): I think some parts of the UI could be better, I’m not a big fan of the consolidated top-level menu because I think users think about and look for labeling suggestive of the features as opposed to Jetpack as a bundle, I hate the slippy-slidy-earth-moving-hidden-UI method of deactivating a module just like everybody else does, and no, local development is not always easy, although there is a way for modules that don’t rely on a connected account.

For the record, I deal with Jetpack on local and restricted staging development environments just about every day, as it’s a part of how we set up to do .com VIP development, and find that there are often equal annoyances like dummy Twitter accounts for testing things that we’ve hooked in to, say, shortlink generation, whether or not we use a .com/Jetpack feature to tweet that link in the end. Or, I mean, oAuth, or SOAP, or lots of other things, especially in PHP. There’s always something annoying or difficult in development, Jetpack or no, and to me one plugin doesn’t deserve an exaggerated share of complaints. Complaints, sure, but it seems pretty lopsided, at least in the public arena, and especially from those who aren’t really forced to deal with it as a part of their client development. Yes, I hate that we don’t have a perfect replicated environment to develop on, and abuse it soundly in our IRC channel, but I do the same for anything we can’t exactly replicate internally and stab at blindly.

There are also things like plugin conflicts, which happen to everybody. I don’t think anybody can claim to have never written a plugin without a mistake or possible conflict, even people who ostensibly deal with WordPress all day every day. I know I can’t, have no idea if I could even test for conflicts against all 22,942 plugins in the .org repo as of this writing (my fault or not), and it would be ugly for me to judge the people (yes, they are people, and as far as I’ve met, wonderful people) who work on Jetpack as a part of their job at Automattic. If we want to point the Automattic-should-know-and-do-better finger, all I can say is that I don’t believe much in statements like that – the only thing I believe in is getting better via hard work and owning up to mistakes, which I find the team (is it a team?) does when actually communicated with rather than reading negative comments second-hand like we “accidentally” dropped a note we were passing in grade school. Developers are always going to have opinions, and it’s not an easy task to ignore what you may actually completely agree with as a fellow developer in favor of your true or proclaimed audience, and I would rather respect that focus while encouraging forward motion. Basically, I don’t want to bash; I want to suggest something that might be better, because that’s how I’d like to be treated. I’m also prone to telling people how I feel as directly and exactly as I can, so I think it can certainly be said that I am projecting some of my own personal preferences and personality here. I mean, it’s my blog!

Let’s take the Publicize module as an example of one that is on by default. There are all kinds of things that I find myself wishing it would or wouldn’t do, but those things I wish are things I’m only aware of because I’m specifically internet-tech-oriented and with other non-Jetpack integrations going on, like IFTTT tasks set up that sometimes create conflicts or feedback loops and my own YOURLS domain. So, maybe Publicize isn’t the feature for me, or I need to take the time to dig into its hooks for my own site, or discover that it doesn’t have hooks I need and find the right person to nag about it if I want to commit to my complaint. Complaining that it exists and is turned on (with nothing connected) is sort of like complaining that OSX ships with a color picker that no longer gives out hex values, minus the earlier-feature-that-got-taken-away part. Yes, it’s lame if that’s what you need a color picker for, and complain away, but there are better and more appropriate tools out there if you really have that specific need and as a power user, I’m perfectly happy to use them instead because it’s just plain better for what I need. It’s easy enough to not open the application, or in the case of Jetpack, either not authenticate anything or turn off that module (slippy-slidy-earth-moving-hidden-UI notwithstanding).

So what does Publicize do for your clicky-clicky-worky user? The biggest benefit I see, besides the whole broadcasting thing, is that it removes the intermediary step of setting up oAuth applications. I’m a developer, and I find that setup stuff almost impossibly confusing, especially on Facebook with all those Open Graph actions and whatnot. Have you tried setting up the Facebook plugin? Does it do what you want even when you make it past those hurdles? It didn’t for me or, perhaps more likely, I missed a hurdle. (Otto, I miss Simple Facebook Connect, even though I understand.) When it comes to Twitter, maybe it’s not completely true just yet, but as their API becomes more and more locked down and difficult to access, somehow I get the feeling that authenticating through .com may just come in handy.

Jetpack commenting, which some may know as Highlander from .com development, did not come turned on by default, but got its own share of abuse for routing through a .com site. I have no idea if it still does it, and to be honest, I’m not sure it bothered me even conceptually. If you’re noticing things like a redirect, then it should probably also be pretty clear to you that something external is happening to make social media logins and email notifications work out of the box. Social media login integration is approximately negative 17% fun, and potentially voluminous email across an unknown and crazy wide assortment of hosting environments is perhaps even less fun. Again, I’m not coming down on anybody for being concerned about the external routing, because I understand, but I think this is a case where it’s also pretty easy to understand why it works that way and to use something else if it is a deal-breaker or otherwise particular concern of yours. If it doesn’t do that routing anymore (seems unlikely), or it’s less noticeable, then great! They iterated and made it better. How much more can you really ask for, especially as a hopefully-empathetic developer? 🙂

As I’m trying to come up with a conclusion to this rambling post, I find myself worried that vocal critics are going to feel as though I am turning around and criticizing them. I’m really not trying to, I promise. I’m a huge critic, both of the thing that I work on the most and of myself. After all, why would you commit to working on WordPress itself if you didn’t want it to be SO much better slash hate it just a bit? What would my everyday motivation be if I didn’t constantly think I could be and do better? In any case, I find all the different perspectives quite interesting, and as somebody who has no interest in creating the next Jetpack, have no real desire to be loudly judgmental, as I don’t envy the task. I just feel it’s important to consider perspective. In this case, it’s the perspective of the clicky-clicky-worky user that matters the most, and I think in that regard, the only problems to have with Jetpack are those of when a feature is actually broken or perhaps being impatient to see what it will do next.