We speak of innovation in WordPress. We present new features like post embeds and emojii, things not everyone wants to use on their sites, things that slow down sites, and we tout how we are making things better.
But do we consider all the users when we do this?
One of the tenets of WordPress, one of the core philosophies, is that we make decisions, not options. And we base these decisions on the 80% rule. We say if a feature will not be used by 80% of the user base of WordPress, we won’t add it.
In early November, WordPress reached the 25% saturation threshold. We have, generally, taken that to mean that WordPress powers 25% of the Internet. A more accurate statement by W3Techs is this:
WordPress is used by 58.7% of all the websites whose content management system we know. This is 25.0% of all websites.
That means sites like my library (which is using Jekyll) or a site built by hand because it’s 5 pages are still considered. Jekyll and Github pages might skew the spectrum, but I’m going to give them the benefit of the doubt, that they know how to adjust for that. The statistics are really quite impressive.
But with that volume of users comes a great responsibility.
952,795,650 websites and counting. If we take away the 75% that are parked domains and redirects, we have 238,198,912 websites. Let’s call it 240,000,000. Of those, 25% are WordPress. 60,000,000 websites on WordPress. 48,000,000 users is 80% of that. Realistically, since we all have multiple websites, I’ll say 45,000,000 individuals.
We are now trying to build websites and predict the behavior of 45,000,000 users.
And you know what? I’m not excited about it. I was a little excited when we hit 16% but when we hit 18% and then 20%, I started to be filled with dread. The numbers of who uses WordPress are skyrocketing, and while I should fear the edge of the cliff, the day the inevitable WordPress killer steps out of the shadow and destroys us (by the way… that totally happened to Windows and Mac, didn’t it? They’ve been top dogs for even longer…), I worry that we’re now crossing a different line.
When we start to propose things like embedding posts, or speeding up WordPress by shunting legacy code to a plugin, or dropping support for shortcodes, I fear we’re about to walk off the cliff ourselves.
Let me paint you a picture of our world.
We have spent a decade (close to 11 years) teaching people to use plugins. We explain that the exhaustive feature set of WordPress is best served by plugins. We have created a moderated, but not curated, repository of themes and plugins. We allow multiple plugins for innovation, for solving problems in new ways, and for demonstrating the myriad ways which one can use WordPress. Similarly we have taught them that themes are the right way to design and style a site, and themes can also be at the forefront of these innovations.
That said, we have not yet managed to teach people how to pick a plugin or theme. They think it’s on WordPress.org, it must be safe. In general, the majority of themes and plugins on the WordPress.org repository are better written than their premium counterpart. Please note: majority – the minority of stunningly well written themes and plugins are not to be discounted, but let’s be real folks, they’re the minority. At the same time, the majority of plugins on the repository are crap.
So let’s recap. If you take all the plugins in the world and round them up, more of the best ones will be on the WordPress.org free repository, but so will more of the bad ones. Following me still? Okay.
Now end users, the majority of our 45,000,000 users, do not know how to pick a good plugin from a bad one. They don’t know how to read, or even skim the code to find out if it’s secure or not. They rely on maybe a quick search for reported issues, if that. They look, they find, they use. Of course they do. We told them to. We linked them to these plugins and said proudly we had found their solutions.
On top of that, we’ve failed to teach them the importance of upgrades. WordPress core handles security updates, but since plugin and theme developers aren’t all as tenacious and consistent about their updates as WordPress core, we cannot always push updates of themes and plugins. WordPress is reliable. Not everyone else is. Not every one of the 50,000 plugins in the repository can possibly be.
This means we don’t have the ability to just update everyone’s site with themes and plugins right away. We just don’t. There are some plugins and themes that will break when we do, or cause each other to break. Worse, there are some plugins and themes that don’t offer updates. Which means we have created a world where people don’t know they need to upgrade to be safe, or that they have to upgrade if they plan on using WordPress 4.6.
And oh yes, we’ve taught them the importance of upgrading WordPress core very well. We’ve cajoled webhosts into upgrading WordPress core for them. We certainly upgrade WordPress core. That’s why over 80% of sites on WordPress are on the 4.x branch. We did our job well, but not fully.
So when you talk about removing features from shortcodes, or dropping support for PHP 5.2, I think that the people who would be hurt by this would be the people least able to understand why.
These people use plugins and themes and don’t know that Johnny Dev used old code. And if Johnny doesn’t update his code in time to meet the changes to the shortcode API, or there’s a bug that makes it not work in PHP 5.4, the user gets hurt.
And when the user is hurt, they don’t blame Johnny Dev. They blame WordPress.
They blame WordPress because we told them to install plugins and use themes. And they trust us. And in that one move, we have betrayed the trust.
That’s the cliff I see us rapidly approaching. And that is the cliff I fear more than anything else. Our idealism and hope may drive us off the edge before we realize it.
We developers, we builders of WordPress, are the 20%.