The problem in WordPress isn't what you think it is. It almost has nothing to do with code—and yet it's all tied up in code and software architecture.
The Problem in WordPress
Notice I didn't write, “The problem with WordPress.” I really like WordPress and all that comes with it. But I think there are two problems, both stemming from the same core dynamic. And both resolved, or at least helped along, by a single approach.
I'm going to take you on a journey of how I've been thinking about this. So if a longer post isn't your style, come back tomorrow for a shorter one.
Have you been paying attention to what's been going on in education in the US?
If you have, then you've likely noticed that the solution to help education get better (more standardized testing), ended up being the thing that started destroying education. “Will this be on the test?” has been the resulting question we've heard more than ever from children – as our scores and standings across the globe has been dropping.
I know, you're thinking, what does this have to do with WordPress?
Well, if you know WordPress, you know about the four freedoms. And you've likely heard of the GPL. That's the software license that articulates what you can and can't do with the software. It protects the four freedoms. And that is a good thing. The GPL is a good thing. Don't get me wrong.
Part of the issue is our focus
But the result is that our eyes have all be focused on the code. The code is everything. We spend a ton of time talking about the GPL and the code and what our rights are, as it relates to the code.
So the thing that was supposed to save us, has been slowly taking our focus off of what's really, seriously, important. And that is the businesses we serve and support. The clients. The ones we talk smack about. Or get frustrated with.
We're a community that spends time talking more about code and “how” something is coded, or the “WordPress way” than the problems we're solving.
More importantly, I can't tell you the number of times I hear that someone is going to build a plugin to solve a problem when an existing solution exists and is doing well, but isn't a native WordPress solution. So instead of using Asana or Basecamp, we'll create a WordPress plugin so that you can do it in WordPress.
As if “doing it in WordPress” is something we should aspire to. But honestly, that's just more focusing on the technology and code for its own sake, than looking to solve the problems that have yet to be solved.
I can't put this all to blame at the feet of the GPL. And I want to be clear, I love the GPL. But our community seems overly focused on code and building everything in WordPress, while serious businesses and problems still exist and we're not looking up. We're navel-gazing.
So is that the problem in WordPress? Almost. Part of it. But not all.
Give me a second here.
Another part is architecture-related
While I can't blame all of the problems on the GPL, and while it sounds like maybe I'm blaming the developers in our community, I'm not. Instead, I put the rest of the blame on the software architecture of plugins.
Yes, I know how crazy it is to say that the problem in WordPress is both the fault of the GPL and plugins – two of the things that have made WordPress as amazing as it is today.
So give me a second to walk thru what I'm talking about (if you're still here).
The architecture of WordPress plugins is pretty simple. You code a file (or set of files) and put them in a place where someone can download it and then apply it to their site.
And that disconnect between the developer of the plugin and the user of the plugin is at the core of my argument.
This issue might have been resolved if the community was focused on businesses and business problems. But in the absence of that focus, this architecture approach exacerbates the issue. Because it leaves developers without a feedback loop to articulate the real business problems (or successes) that are happening with their code.
Today, for the most part, a plugin developer has no idea if their plugin is powering a million-dollar site or a $50 dollar site. They have had, for the most part until recently, no idea if their plugin is even still active on a site. They have had, for the most part, no notion of where their plugin was working well or where it was failing. And for the most part, they've had no idea if that failing part was mission-critical or not.
We've written tons of lines of code without any feedback loop.
Which has resulted in tons of lines of code that have also been sold poorly.
Because without context and feedback loops, it's virtually impossible to segment your audience and therefore message or price effectively.
We've all been flying blind
I don't know how you would evaluate the GDP of the WordPress ecosystem. I won't go into how I think about it. But I can tell you this.
In my opinion, the overall economics of the WordPress ecosystem feel significantly lower than I would imagine for any community with this much reach, this much engagement, and this much market share.
I know the hosting companies out there are making money. But look at the commercial plugins out there. Why aren't we seeing more of them that are crossing the million-dollar mark per year?
My sense is because plugin developers have been flying blind.
They don't know how their code is used, where it's used, where it's helping, how it's helping, and where it's struggling.
If you think about it, it makes what they've done and the success they've had remarkable. We should hold them up. And yet we should want more and better for them and everyone else.
Is there an answer? I think so.
I think it's a different architectural approach called SaaS.
Now, I'll start by saying, to an owner of a hammer, everything looks like a nail. And I've been developing SaaS products since 1996 when we didn't call them SaaS. So I bring with me my own bias.
The other day a friend of mine wrote an article that suggested that SaaS for WordPress plugins was a constant suggestion he heard, but he wanted to caution that it wasn't right for everyone.
He's right. It's not for everyone.
But where I disagreed with my friend was in the reasons he made for why people should consider a SaaS model. I know people like to talk about recurring revenue, and I'm a huge fan of it. But I'm not suggesting that the SaaS model and approach is right because of it's financial model (regardless of how awesome recurring revenue is).
I'm suggesting it because it opens our eyes.
- When we're no longer blind, we can make better product development decisions.
- When we're no longer blind, we can make better pricing decisions.
- When we're no longer blind, we can make better support / lifecycle decisions.
- When we're no longer blind, we can make better marketing decisions.
So even though there are people out there who are trying to tackle the SaaS dynamic for WordPress plugins, like Freemius, which I think is very cool, it's not where my focus is.
I want better data. I want plugins to pursue a SaaS model simply so that they have a hosted component and a plugin component and when they do, they can gather better data to tell them:
- Which features are being used
- Which features aren't being used
- Which features aren't scaling well
- What kind of sites are using their plugin
- When sites stop using their plugin
And more.
That, to me, is why a SaaS architecture model could shift our focus away from just our code (even though the data is about our code) and to the businesses using our software.
Not all businesses will be the same. They won't have the same needs. But we'd start learning much more about segments and how we need to shape our offerings for segments rather than just lists of varying features for different prices.
- The result would be better messaging.
- And better pricing.
- And better economics for the whole ecosystem.
- And better code.
- And better discussions.
To me, that's a fantastic reason to look more closely at SaaS.
I'm pretty sure iThemes knows more about their customers and can serve them better because BackupBuddy, Stash and Sync work collaboratively but also give them insights they didn't have when it was just BackupBuddy.
Oh, and Optin Monster. I bet they know more about their customers and how to shape their product to more effectively serve them now that they're part plugin part SaaS.
I can't say for sure. I don't know. But I suspect.
Oh, and of course there's the recurring revenue. Let's not forget that.