What if WordPress, growing as an operating system for the web, spawns distributions and spins, like Linux? What do nine years of Jetpack teach us about Automattic and WordPress — the project and the dot-com? Rethinking how we think about SaaS, hosting, and the WordPress ecosystem…
Speaking at Pressnomics in 2015, Matt Mullenweg, asserted that without Jetpack, WordPress’ market share would be in decline. Why? Because “naked” WordPress wasn’t competitive with SaaS site builders like Wix and Squarespace. On Twitter last month, Jeff Chandler reminded the WordPress community of Sarah Gooding’s terrific article stemming from Matt’s remark seven years ago. It took on new significance in the context of recent market share discussions.
Jetpack surely helped fan WordPress’ growth — especially with many millions of entry-level users.
Whether Matt was overstating its importance or not, Jetpack surely helped fan WordPress’ growth — especially with many millions of entry-level users. The downside was how it blurred the distinction between SaaS WordPress (.com) and self-hosted WordPress (.org) to compete with SaaS Wix, Squarespace, etc. That never sat well with the larger WordPress community — the fraction of us in the largely .org half of all WordPress users who know the difference between .org and .com.
Apropos of nothing Rob Howard hasn’t already said about shark-infested red oceans, I’ve been thinking about the consequences of trying to mirror your main threats (like SaaS website builders and hosting companies) rather than making moves only you can make (combine SaaS and open source) while drawing on a superpower — the goodwill and creativity of a diverse and inclusive community based around a shared, open source project.
For better or worse, that may sum up where Automattic, other large WordPress companies, and the WordPress ecosystem are now in terms of threats and opportunities.
Lessons from nine years of Jetpack — acquiring, consolidating, and now decoupling plugins
2015 was a long time ago. Jetpack itself is 9 years old as of June 25. While I was reviewing some of its history, I remembered Steve Burge shared his thoughts about Jetpack’s importance to WordPress’ market share back then too. The questions he asked and the comment discussion that followed his post are still timely and relevant — especially his observation about the threat of SaaS…
The real threat to open source’s market share is SaaS. To survive, open source projects need to offer some of their own centralized SaaS tools otherwise they’ll lose the low and middle end of the market.
…and his prediction — or hope — for open source:
The most successful open source projects in 2015 will […] combine the best of open source and SaaS. It’s worth remembering that WordPress powers over 20% because it has a SaaS product already. WordPress.com users are about 50% of all WordPress users already, so it’s fair to say that WordPress is already a SaaS-first product.
Except that .com/.org thing.
That .com/.org thing…. if only it could be a happy marriage!
One is SaaS and one isn’t. Jetpack was and is a way of combining them — if only it could be a happy marriage! Install Jetpack and you have a SaaS+self-hosted WordPress hybrid — whatever “self-hosted” means in the age of “managed WordPress hosting.” (Hold onto that thought; I’ll come back to it.)
What if Jetpack had stuck with a decentralized approach from the start?
Jetpack debuted with easy-to-install SaaS tools and their APIs for developers. Everyone from no-code site builders to developers and agencies could leverage the WordPress.com network on WordPress.org sites hosted anywhere else. It was and still is a great idea. It just never caught on with the WordPress professional community. For reasons.
Imagine what might have happened if that was how Jetpack worked from the start and had focused more on developer API support for its various services.
Jetpack grew and grew in size and scope — sometimes by acquiring popular free plugins that provided unique features and then died as independent projects after being acquired. Complaints about performance and bloat grew too, along with Jetpack’s features. Jetpack became a tiny app store for Automattic inside WordPress. Even brand new users were confused — and upset. Post Status joked WordPress itself would be packaged within Jetpack. It was called a “Trojan Horse.” Critics were harsh — for reasons.
Multiple forks of de-SaaSified Jetpack sprang up and quickly died. Slightly longer living forks of Jetpack modules repackaged its features as individual plugins, stripped it down to a single feature, and allowed modules to be selectively de/activated — something Jetpack eventually reincorporated. And now Jetpack is decoupling all its modules as individual plugins so users savvy enough to do so can pick and choose which features they use for a particular site.
It’s the right thing to do. The smart thing. It always was.
Imagine what might have happened if that was how Jetpack worked from the start and had focused more on developer API support for the last decade.
At a time when many developers feel the focus in WordPress core development on Gutenberg has created deficits and technical debt in other areas — especially those specialized in PHP and concerned with back end, server-side WordPress — it’s a shame Jetpack didn’t immediately live up to its potential for widespread developer support. But maybe it still can.
You can’t please everyone, especially when they don’t know what they could do with your product
Recently we’ve been hearing concerns that WordPress’ market share may have declined for the first time. People looking for a simple blog or basic development framework miss having a lean WordPress option. Ghost and Substack have a solid grasp on the market for membership-based, monetized publishing. It’s drop-dead simple: a blog, newsletter, and restricted content all working together seamlessly out of the box.
Pressable, WordPress.com, and WordPress VIP all use the same data network and similar architecture; they’ve all consistently aced the gold standard of performance benchmarking in all pricing tiers.
You may be as surprised as I was to notice WordPress.com offers pretty good solutions nowadays to these perceived feature gaps. You can create a feature set similar to Ghost or Substack in a relatively quick and easy way. Expect these to continue to be refined in the future — especially if WordPress.com integrates some form of a WordPress-based Tumblr blog as a “lite” option.
Repackaging Pressable as a third “Business” (code-optional) tier of traditional “managed WordPress hosting” next to the current “Professional” (no-code) plan would be logical too. Pressable, WordPress.com, and WordPress VIP all use the same data network and similar architecture; they’ve all consistently aced the gold standard of performance benchmarking in their pricing tiers.
Automattic properties like Pocket Casts and Day One could make new flavors of WordPress.com the best way to podcast or journal. As the plugin/block marketplace evolves and continues to open slowly at WordPress.com, there’s increasing opportunity for others in the ecosystem to sell their products across channels that seem likely to expand if the ecosystem remains strong.
There’s a lot of potential and a lot that’s already in there, but if you’re a .org person, you may not have looked. Not that you’ve been given many good reasons to, especially at key moments like a major pricing change. It’s hard to look back over the years and not ask if what got Automattic and its portfolio of its brands where it is will take it where it needs to go without painful changes. Walking the tightrope of SaaS and open source, it’s always a balancing act between centralization and decentralization — not just in products but organizational structure and management.
What actual distinction is there between “Managed WordPress Hosting” and “WordPress-as-a-Service?”
If you don’t need to “self-host,” why not WordPress.com? But then, what is “self-hosting” when it’s being “managed” (i.e., not by you) that makes it different from SaaS WordPress? WordPress.com has way more in common with any managed WordPress host than either does with “less-managed” (or “mostly left to you”) server control panel middleware like ServerPilot and SpinupWP as they exist now.
There’s really not much more needed than marketing and fresh interfaces to get people to realize WordPress.com is managed WordPress hosting — and arguably the first to do it before the term existed. (If you care about that kind of thing.)
A game of cathedrals and bazaars they can’t fully control
WordPress SaaS is Managed WordPress is WordPress SaaS. That seems likely to be how “SaaS and open source” will converge not just for WordPress.com but other major managed WordPress hosts who offer extension marketplaces and turnkey “custom” WordPress installs for common use-cases.
Pippin Williamson and Austin Ginter have addressed the upsides and downsides to this future scenario. […] It could be more competitive or collaborative. It has to be some of both.
If things go that way, it might work out like the Linux ecosystem, with the major WordPress hosting platforms acting as “derived distributions” (and maybe offering something like Fedora spins) of WordPress core.
Pippin Williamson and Austin Ginter have addressed the upsides and downsides to this future scenario — possibly an ecosystem of ecosystems that expands the total marketplace — with multiple marketplaces. Brian Coords’ shopping center analogy is apt — or a maybe cluster of cathedrals, basilicas, and chapels each facing a series of bazaars they sponsor, host, or loosely control. (In such a zealously religious, maybe overchurched culture, the bazaars are bound to be bizarre.)
A puzzle and game I’ve had sitting on my coffee table for years…
It could be more competitive or collaborative. It has to be some of both. How well will they play together, support developers, help WordPress businesses and common users do creative work and grow their businesses?
What is “open?” Who do you trust? How do we do this together?
Maybe a decade ago, WordPress (the community/project/ecosystem) was too SaaS-led for its own good. Trust issues followed inevitably from the brand being tied to Automattic, and inside a SaaS product, your limited level of control (which is nine-tenths of ownership) is clear. Inside a hosting panel, or the WordPress admin, or WP-CLI connecting to “your server” you may think otherwise. The reality is virtually the same. The experience — and how you think or feel about it — is very different.
As always, the important and perennial questions are, “What’s really “open?” Who do you trust? How do we maintain this big messy thing… together?” Because, after all, we are impossibly knotted together.
As always, the important and permanent questions are, “What’s really “open?” Who do you trust? How do we maintain this big messy thing… together?” Because, after all, we are impossibly knotted together.
Clearly, you can’t please everyone all of the time. But try to think of a brand other than WordPress (in open source, tech, or beyond) with such popularity, growth, and market dominance that has a community always ready to see the glass half full or have a go at each other. It’s a culture of altruists who fear mercenaries lurking everywhere. And the fingers point in all directions. For reasons.
But try to think of anything comparable — a commons — that’s this big, diverse, and decentralized with lots of opportunities for everyone. Chronic discontent may just be the weather that goes with that. Let’s call it “constant questioning,” to put the accent on the positive value in it.
Dan Knauss is the Editor at Post Status. He’s a writer and editor, sometimes a teacher and open-source web app consultant. He’s currently above ground in Edmonton, Alberta trying to keep it gnarly.