There’s something in the water at Automattic, and I don’t think it just started with Matt Mullenweg’s “samattical“. The last few months have seen a number of interesting changes across the company and its approach to the broader WordPress community.
When I pull the various threads, it looks to me like Automattic is making a larger strategic pivot towards “developers” and “builders” as a target audience, for itself and quite possibly for WordPress. Automattic’s products have traditionally focused on the DIY side of the WordPress market, making tools for bloggers or creators building their own websites. That’s still largely the case, but recently, things have been looking a little different.
I was able to talk to a handful of people across the company and explore some of these major changes. While I was never given an answer on Automattic’s larger strategy, if such an answer even could be given, I think there’s enough out there to frame some initial thoughts on changes that might affect WordPress (the software) going forward.
Woo Express causes Woo Distress
When Matt Mullenweg started his sabbatical, he did so with a tongue-in-cheek blog post titled “Automattic’s Big Re-Org“. While there was no big reorganization, the post did announce that each team inside of Automattic is revisiting its position within the broader ecosystem. Decisions will be made based on whether a team’s goal is to be competitive with the other hosting companies (i.e. WordPress.com, Pressable, WordPress VIP) or to be completely host-agnostic and “Help the Hosts” by growing the ecosystem (WooCommerce and Jetpack).
It’s an interesting distinction because you could certainly make the argument that more tightly coupling the WooCommerce brand to WordPress.com’s hosting infrastructure could be a tactical advantage. In fact, they did make that argument when they launched Woo Express a year ago and then rebranded the team behind WooCommerce to Woo a few months later. A new call-to-action that funneled visitors to WordPress.com hosting plans rather than just the open source software raised more than a few eyebrows in the community.
The team was fairly quick to address the criticism, with Woo CEO Paul Maiorana taking in feedback and responding openly to the community on Twitter/X. They’ve since rolled back that specific onboarding funnel.
Matt Mullenweg directly referenced this experience and how it helped lead to these new changes:
“The big tension this surfaced was Woo Express, going forward that team is switching under WP.com, and Woo.com will recommend a variety of hosts (like W.org) to get started with Woo. Now people can meet with Paul Maiorana, who leads Woo, or James Grierson, who leads Jetpack, and know they have Help the Hosts cards as their teleological goal.”
So Woo Express is officially a WordPress.com product, competitive with the “managed WooCommerce” offerings from other hosting companies and treated (more or less) the same when you visit Woo.com. The end result is that Woo/WooCommerce will act more like WordPress.org and not completely favor Automattic’s hosting companies.
Conflict of Disinterest
I can see how important that separation is, but I can’t help but wonder if a one-click install of a new WooCommerce site wouldn’t have been a much better call-to-action for end users than what they get now: a link to a “Hosting Solutions” guide and an additional burden of choice. I’m sure a Shopify-like onboarding experience happening directly on the homepage of Woo.com was a tempting strategy.
It’s not unusual for the owners of an open source project, specifically developer frameworks, to actively promote their own paid solutions. The homepage of Next.js includes a callout to Vercel, Laravel includes links to products like Forge and Vapor. Those paid products (typically around hosting and deployments) can directly subsidize more contribution to the open source frameworks themselves.
WordPress has always held itself to a different standard in this regard, and part of that tension is because of the importance of all of the hosting companies to the broader ecosystem. The fact that I can go to any number of hosts and know that they’ll not only support, but also install WordPress for me is a major reason for the success and ubiquity of the software. As much as the community needs Automattic, it also needs the support, engagement, and contributions from the broader hosting ecosystem, a reminder that much of the WordPress you see in the world does not actually run on Automattic’s infrastructure (more on that later).
It’s Time to Build (on WordPress.com?)
As part of the non-re-org, Matt announced that the WordPress.com user experience was about to change. From his blog post: “WordPress.com is going to orient itself more towards developers, and have an experience that feels similar to WordPress hosted other places, less Calypso more wp-admin.”
If WordPress.com is your only experience of WordPress, then this statement might not make that much sense. If you come from the world of self-hosted WordPress, however, you may know that the WordPress.com experience is wildly different from standard installations. WordPress.com still includes a number of premium upsells inside their version of the WordPress dashboard, including links to buy premium plugins on their parallel plugin directory. It’s been a somewhat controversial and convoluted approach, and you can still browse the WordPress subreddit and find the misconception that you can’t install your own plugins on their platform.
At WordCamp Asia this past weekend, Matt was asked during a Q&A if he would ever retire the “WordPress.com” brand name entirely to clear up the confusion. Matt momentarily pondered whether this was “an original mistake in setting all of this up” and noted that he’d even considered “moving WordPress.com to wp.com or […] trying to get w.com.” He ended the thought experiment pointing back towards these user interface changes coming to his platform to bring it more inline with self-hosted WordPress.
I reached out to Daniel Bachhuber, the long-time WordPress contributor who was recently tapped by Matt to lead the entire WordPress.com side of the company. I asked Daniel to tell me about this new vision of WordPress.com and who it might be for.
“WordPress.com has always been a platform for a variety of users,” he explained. “Over the last year, we’ve added more developer-specific features (staging sites, WP-CLI access, etc.) […] Our hosting infrastructure, powered by WP Cloud, is best-in-class, but we need to communicate that better.”
From what I’ve heard about some of the upcoming developer features, his team is not kidding around. One tool that’s been quietly pre-announced is Studio, a brand new tool to manage your local development environment. You can learn about it on the newly relaunched Developer Resources for WordPress.com (not to be confused with the newly relaunched Developer Resources for WordPress.org, led by a team of mostly Automattic-sponsored contributors, or the newly relaunched Developer Resources for WooCommerce that I’ll be getting to later. Do you see where I’m going with this?)
“The new developer.wordpress.com,” he explained, “is our place to connect with WordPress developers. We want to teach them how to use our developer tools, take advantage of our platform features, and help them achieve the best possible outcomes with their websites.”
The term “developer” is fairly broad, so I asked how they’re thinking about this new market segment internally.
“This is a really tricky question, in fact! What ‘developer’ actually means is variable based on perspective,” Daniel explained. “Our working definition of ‘developer’ is ‘someone who builds or manages sites for someone else.’ This is inclusive of the freelancer building client sites, agency developer maintaining ecommerce sites, or internal developer working on the backend of a multi-platform publishing system or decoupled site.”
As someone who has actually held each of those jobs at one point, all I can say is that his team has their work cut out for them. Luckily, WordPress.com does have the infrastructure and the talent to achieve the technical implementation. The much harder part will be establishing this new relationship with the broader WordPress developer community, basically from scratch. That’s where the team at Woo comes in.
WooCommerce Would Like to See You Now
Because Developer Documentation redesigns are in the air this year, the team at WooCommerce also announced a brand new relaunch. More than that, the developer relations team has felt much more publicly engaged, recently resurrecting their old Twitter/X account.
Jacklyn Biggin is a Developer Advocate at Woo and has been one of the most visible forces for this change. I asked her if this was part of an internal strategy to increase their outreach efforts with the developer community.
“You’re not imagining things,” she told me. “Woo’s developer community is a huge part of what makes Woo successful, and we want to provide them with as much support as possible. We’re working to improve the feedback loop between the community and the Woo team, and relaunching @DevelopWoo is a small step in that process.”
She told me about some of the new things they’re trying, like hosting public GitHub Discussions for new features and having blog comments from developers piped directly into their internal Slack. I also asked her about the new documentation.
“Historically, a lot of Woo’s developer documentation and resources were scattered across the monorepo, merchant documentation, the developer blog, and beyond,” she said. “Centralizing our documentation on our new Woo Developer Docs site aims to fix this. The current site you see isn’t a finished product – for example, we’re currently midway through migrating the WooCommerce Blocks docs to it – but we’re now in a position where we’re able to make these incremental improvements.”
WooCommerce Blocks was merged into WooCommerce core at the end of last year, making it possible to manage more of your store inside the block editor, and much of the work behind WooCommerce Blocks has directly influenced development of core WordPress features.
Docs on Blocks
If there’s one part of WordPress that’s been the most controversial, and given developers the most grief, it’s the block editor. Previously developers extending WordPress or Woo would achieve most advanced functionality with PHP. The block editor still requires that base knowledge of PHP, but adds the additional complexity of JavaScript and React now to make changes to the user interface.
As WooCommerce moves more of its functionality into the block editor, developers will need to keep up. And the team at Woo has to make sure those developers are motivated to keep up, if they want to continue to see the ecosystem thrive. Woo ultimately relies on the platform effect to remain relevant and attract new users. In general, developers will only build for the block editor if they think it’s being used, but users are waiting for developers to bring full compatibility to third-party plugins.
“The shift towards the block editor has been a pretty big change for developers,” she said, “and we’re working hard to provide useful resources. These include informational blog posts, tutorials and docs (note that these will move to the docs site soon). Over in our community Slack, we have a dedicated channel with direct access to the team working on Blocks at Woo, and we’re even hosting Office Hours focused on the new Product Editor next month.”
Daniel Bachhuber was quick to point out that emphasis on the block editor as well, telling me that, “it’s really matured in the last couple of years, and we’re excited to see the sites built with it this year. We want WordPress.com to offer the best possible user experience for block theme developers.” It’s an interesting turn of phrase. In theory, block themes shouldn’t need developers, instead offering a “no-code” experience building a WordPress site. If anything, the block editor has raised the expectations and need for developers in WordPress.
For now, it looks like most Woo stores are running on classic themes, though it makes sense that such a fundamental transformation will simply take a long time.
When I asked Jacklyn if she saw this shift towards developers more broadly in Automattic, she pointed me towards the changes happening at WordPress.com as well as a completely different side of the company, WP Cloud.
Another Automattic Host
WP Cloud is Automattic’s completely in-house alternative to AWS or Google Cloud. It’s built specifically for WordPress. It’s the underlying infrastructure of WordPress.com and Pressable, a managed WordPress host under the Automattic umbrella.
To learn more, I connected with Jess Frick, Director of Operations at Pressable. From the outside, Pressable looks like any other managed host, albeit with a particularly enthusiastic user base. Where WordPress.com traditionally marketed toward the individual user, Jess describes Pressable as “an incredible choice for developers, agencies, and freelancers who want to host multiple WordPress websites – our performance test results and customer reviews speak for themselves.”
As WordPress.com makes moves towards that same user base, it’s worth noting that there are key differences. One big tradeoff with WordPress.com’s hosting offer is its deep integration with Jetpack, which may or may not work with a particular developer’s workflow.
“The Jetpack integration is one area where I think we will continue to differ,” she explained. “While we’re obviously big fans of Jetpack – especially the security benefits – we understand that some of our customers may have other solutions they prefer instead, so Pressable makes it easy to use it or exclude it.”
What’s even more important about Pressable is their license for experimentation towards what the future of managed WordPress hosting might be.
“One aspect of our role that is possibly becoming more clear to the outside world,” she said, “is our position as Automattic’s hosting lab. We are empowered to build interesting things that other brands can benefit from, and we’re given the freedom to do experiments.”
Results of those experiments can make their way to WP Cloud. For more context, I’d recommend reading Jess’s recent explainer on WP Cloud, outlining what it is and just how involved Pressable has been with its development.
“We are both built on WP Cloud,” she explained, “and it is the platform that allows us to provide our hosting services. […] We have been using what’s now known as WP Cloud for years before it became a product itself and I don’t see a future where we use something else. It’s truly incredible.”
I’ll take one WP Cloud, please
But WP Cloud isn’t just for Automattic. It’s also slowly becoming available to other partners. Bluehost recently came out as a WP Cloud customer, offering a new cloud hosting tier to their customers. What’s more unusual about this deal is that WordPress.com is highlighting Bluehost on their pricing page.
It’s a smart way for Automattic to grow revenue by leaning into what they’ve excelled at (infrastructure) while other brands (including their own) handle the marketing and user acquisition. Bluehost was one of the hosting options tied up in the initial launch of Woo Express, and it seems clear that Automattic learned something about how to better position these relationships from that messy process.
When I asked Jess if she felt a larger shift inside of Automattic, she told me that her “personal view is that this is a natural evolution, with Automattic responding to the needs of the market.”
We’re all in this platform together
There’s so much more that I would’ve wanted to get into, from WordPress VIP to Jetpack’s “Manage” product for WordPress agencies. One year ago, the WordPress.com homepage opened with the tagline “the world’s most popular website builder”. Today it highlights their “lightning-fast hosting”. That’s two completely different visions.
Regardless of your opinion of Automattic as a company, the fact that they’re in the midst of redefining their place in the broader community is important, especially with their outsized role in contribution to WordPress and their alleged content partnerships with AI companies like Midjourney and OpenAI.
It’s always hard to say what’s going on in Matt Mullenweg’s head. The Gutenberg project is in its seventh year and still has two of four phases to go. I don’t know if anyone accurately predicted the scale and direction of the project’s current trajectory back then. In his initial manifesto on the topic, Matt said “We Called it Gutenberg for a Reason”:
“Ten years ago, agencies and developers worried that software like WordPress would ruin their business because clients wouldn’t need help updating their sites any more, and would maybe even just start building their own sites. But their worse fears didn’t come true — instead, it created new opportunities for everyone.”
As a developer, of course my theory is going to be that Automattic is starting to value the third-party developer and agency communities much more than it has in the past. That it sees itself less as a beginner’s version of WordPress, with its own Calypso-flavored interface, and more of the underlying infrastructure that agencies and builders can use to grow WordPress. That perhaps it’s turning to a vision of WordPress and WooCommerce as developer platforms for the internet, taking a role similar to other open source projects and focusing on providing infrastructure rather than competing with Squarespace.
It’s definitely a developer’s dream, an Automattic that fits in with the entire ecosystem, that values the builders, agencies, freelancers, and developers building WordPress websites, that offers its customers the same WordPress experience as the rest of us. Only time will tell where this dream leads.