Have you ever wondered what it takes to support a WordPress plugin with a million active users? At the beginning of 2015, Matt Mullenweg highlighted Jetpack as one of the most important tools in helping WordPress remain competitive and preventing the decline of its market share.
The team surrounding Jetpack is laser focused on adding compelling features that will help self-hosted sites get everything they need in one convenient pit stop. Whether or not you believe the future of WordPress is hinged on Jetpack’s success, there’s no doubt that the professionally-supported plugin has helped self-hosted sites to thrive, with much less effort required on the part of site administrators.
With 36 modules currently available in the plugin and a never-ending support queue, the distributed team behind Jetpack meets up regularly to build teamwork and keep things running smoothly. At WordCamp London 2015, a good number of the newly expanded team met in person for the first time.
I had the opportunity to sit down with a few Jetpack representatives, including team lead George Stephanis, support specialist Carolyn Sonnek, and pit crew team member Jesse Friedman to discuss what it takes to keep Jetpack going strong.
Managing the Jetpack Support Load
Since their last meetup in August, the Jetpack team has experienced quite a few shakeups. Automattic’s BruteProtect acquisition added five new team members to the pit crew, bringing their numbers to 10. The Jetpack Manage team, which ties into WordPress.com, has 10 members and is led by Beau Lebens. There are also 10 additional team members allocated for supporting Jetpack user happiness.
Stephanis always tries to include someone from support, as they represent those who are on the front lines with users every day. The happiness engineers are also divided into sub-teams to manage a support queue that often adds up to several hundred tickets per day. Requests pour into an email inbox from the plugin itself, as well as the WordPress.org support forums.
Jetpack team members are also active on Twitter and Facebook where they triage requests and help to move users to a more traditional support avenue. The happiness engineers are currently working on a quicker turnaround for support.
“Right now our goal is to get under 12 hours, and then once we hit that goal, we’re going to go to five hours, and then on to 1 hour someday,” Sonnek said. If you take a look at the plugin’s support forums, you’ll find that nearly all of the issues are resolved or in process, which is a rarity for WordPress.org plugins. It takes 10 team members to keep it that way.
Automattic is aware of the number of people currently using Jetpack but will not be disclosing that information publicly. “We use those numbers internally for reference for how we are doing, or to see if there has been some change that has resulted in an uptake of new connections or something along those lines,” Stephanis said.
“In the end it’s a number, and a number without context is very easy to take out of context. [pullquote]Instead of dwelling on the numbers, we’re much more interested in what adoption looks like.[/pullquote]” He said that the total number is comparable to the million installs reported by WordPress.org but is probably somewhat less if you account for test sites and hosting partnerships where the plugin is automatically installed but not yet active.
Jetpack Focus for 2015: Iterating and Polishing of Current Features
For the past few years the Jetpack team has managed a unique balancing act of prioritizing support while fixing bugs and tackling new features at the same time. Many recent releases have introduced new modules, but the team is switching gears in 2015 to focus on keeping the ride smooth.
“Our focus for the next year is largely going to be on iterating and putting the next bit of spit and polish on features that are already in,” Stephanis said. “A lot of the things we’ve launched need a v2; they need a second pass on it.”
This new focus will be a change as compared to the previous breakneck speed with which the team was cranking out new modules.
“There are couple of minor things that other teams are working on that will probably get rolled out to WordPress.com and will probably get synced down to Jetpack as well,” he said. “But there’s no large ticket features that we’re currently focusing to get into Jetpack and get launched.
“This is very much a year focused on building up the team, building up familiarity with our internal processes and cultures, and addressing some long-standing technical debt that we’ve been kind of swamped with paying down.
“But now with the resources we currently have, it’s much easier to focus on the core product offering and how to explain that,” Stephanis said.
Pushing for Goals Over Deadlines
Stephanis has been leading Jetpack releases for awhile, but recently the team has started rotating release leads in preparation for his upcoming paternity leave. I asked him if he still feels the weight of pushing out code to millions of users at release time.
“Every time,” he said. “I’m just thinking – What edge cases have I missed? Have I forgotten to do something? Have I updated the translations? What if we’re not compatible with some other plugin? What if there’s a name space conflict and we white screen some sites?”
With a massive user base using a myriad of different themes and plugins, there’s always the chance for some unforeseen conflict. The support team has to be prepared to handle that.
However, Stephanis believes the many problems with releases can be prevented by making sure you’re never in a rush.
“If you’re forcing it through to get it out super quick, you’re not giving your subconscious the time to turn things over in its own time,” he said. “I’m not saying intentionally slow down the development process, but [pullquote]making sure you’re never overly rushed by deadlines is one of my best ways to ensure that we’re not having oops moments[/pullquote] or shipping something and then two hours later go ‘Oh we forgot the…’”
As part of this approach, the team focuses on goals and testing more than meeting an arbitrary release schedule.
“We set goals more than deadlines,” Stephanis said. “Yes, it’s nice to have deadlines and goals but if you’re overly concerned about the deadline, the quality can slip. We make sure we’re not shipping anything unless we’re really comfortable with it, we’re confident, and we’ve tested it.”
The team aims to do at least a one-week translation freeze before releases and generally catches a good deal of bugs during the freeze.
“We have a fantastic Jetpack beta group that we pass releases out to and explain everything new that’s coming,” he said. “Some of the edge cases they turn up just blow my mind.” Having that cushion of time to focus on compatibility and cross testing is essential to mitigating Jetpack’s conflicts with other plugins.
“[pullquote]Very small issues become very big issues when you’re running at scale with millions of users[/pullquote],” Stephanis said. “If something is only hitting one tenth of one percent, guess what, that’s a couple thousand users now.”
With an ever growing user base, the cost of a mistake or conflict gets even more expensive in terms of support. This is where the Jetpack team has learned that not rushing really pays off. The goal, in the end, is not about hitting a release date but rather providing a smooth experience with the release.
Overcoming Negative Perceptions of Jetpack
One of the constant struggles for the Jetpack team is addressing the negative perceptions of the plugin, especially criticism from the development community.
“There are still a lot of folks who don’t understand what we’re actually trying to accomplish,” Stephanis said. “I occasionally get questions like, ‘With as many things as Jetpack is doing, how are individual plugin authors meant to in any way compete against this?’
“The answer to that is we do a lot of general things aimed at raising the tide that lifts all the ships, but we don’t go in any way in depth. For example, I don’t think the contact form module in Jetpack has in any way hindered the sales of Gravity Forms.
“Developers still have the ability to pick one aspect and go incredibly in depth on it – yes, we have related posts, but if someone wants to do a plugin that just does related posts and really knocks it out of the park, we’ll be able to get folks started on the idea of it. Then they’ll get comfortable and will be much more willing to move to a premium version that they find elsewhere.”
Stephanis also emphasized Jetpack’s extensibility. Plugin authors are even at liberty to utilize the WordPress.com infrastructure while extending Jetpack features. Despite having 36 different modules, the goal has never been to add every possible feature.
“One of the things we fight perception-wise is the concept that Jetpack is bloated,” Stephanis said. “Which is an easy thing to think when you see what appears to be 30 some different plugins that you can turn on and off.
“When they all tie together with the common core, one plugin can be just one line of code or one plugin could be humongous. It’s very easy to fall into the idea of: ‘I turn off a plugin and that’s going to make my site go faster, right?’ But the fact of the matter is that everything we do in WordPress and life is always going to be a matter of trade offs.
“If you do something else, it’s going to affect your site in some fashion. Just by the very fact that you’re adding some level of complexity. It’s more of a question of if you want this feature what’s the best trade off you can get for it. Sam ran a couple comparisons and published them on the group blog comparing our commenting form and several of our other features to WP plugins. In comparison, we wind up coming out a little bit ahead.”
The download size of Jetpack, currently at 8.2MB, is often a concern for many users.
“The code base gets a lot of misunderstanding,” Stephanis said. “The translations are about 2/3 of it and the Custom CSS module includes a megabyte in and of itself, because we include some JavaScript and CSS to make it pretty as you’re editing it, SASS and Less precompilers, the CSS sanitization library, all of which for the vast majority of page views isn’t even loaded.”
At the moment, three quarters of Jetpack sites are using English, which means that two thirds of the download size is irrelevant to three quarters of Jetpack users. Getting translations on demand is a major goal for the plugin, but the team has to work with WordPress.org to make it happen.
“We are waiting on support from WordPres.org to let us use a GlotPress instance to manage our translation flow and then it’s just a quick switch to start serving it up on their end,” Stephanis said.
Until that is resolved, the cost of supporting a global user base will continue to be an extra 5MB on the initial download. Apart from some vocal opposition from developers, most Jetpack users do not seem to mind the size of the download or the number of modules. The features it provides in one package are too compelling and convenient for most of the plugin’s users to notice the download size.
Jetpack also gives self-hosted sites access to the infrastructure available on WordPress.com for features that might otherwise create a toll on budget hosting providers, such as related posts and the free Photon CDN. However, Stephanis believes that the quality of maintenance and support are the most compelling reasons to use Jetpack.
“One of the biggest gripes most folks have with the WordPress.org plugin repository is that there are so many abandoned plugins,” he said. “These are plugins that either have bugs and never get attention or plugins that, if something breaks, you can never get support.
“By far the biggest advantage and the best reason to use Jetpack is the fact that we have 20 active developers between Beau’s team and the pit crew itself, and an active crew of about 10 support folks that are daily focused on enriching the experience, fixing any issues that come up. That, by far, to me is the biggest selling point, the biggest advantage over using 30 different plugins where the code quality may be more questionable.”
Yay! It was great to meet few of them in WordCamp London. Thanks for the comprehensive behind the scenes articles, Sarah.