AWS and Digital Ocean run local Ubuntu download servers and do not depend on Canonical to run their business. WPEngine is a hosted service and could make very simple changes to download updates from their own servers.
This all kicked off when he publicly accused WP Engine of “butchering” WordPress for disabling revisions:
> What WP Engine gives you is not WordPress, it’s something that they’ve chopped up, hacked, butchered to look like WordPress, but actually they’re giving you a cheap knock-off and charging you more for it.
— https://wordpress.org/news/2024/09/wp-engine/
Disabling revisions is a configuration change. This is the simplest possible change you could make, and it’s unacceptable in his eyes.
Making WordPress contact something other than api.wordpress.org requires altering the codebase. Making this configurable is something he has explicitly rejected:
> Why would I build that? The built-in source works great, for tens of millions of servers.
— https://news.ycombinator.com/item?id=41676885
So according to Mullenweg:
- If WP Engine alters WordPress, even just to alter its configuration, they are “butchering” it.
- If WP Engine doesn’t alter WordPress and leaves it pointing at api.wordpress.org, they are unfairly using community resources.
– Huge numbers of people using api.wordpress.org is actually “great” and scales to tens of millions of servers.
As far as I can see, he doesn’t have a consistent position. He’s just grabbing hold of the nearest accusation that he thinks will harm WP Engine in the heat of the moment, regardless of what he has previously claimed or who else it hurts.
Here's a nice example: https://github.com/WordPress/WordPress/blob/92d9e70f849c337c...
It's an example of the kind of backwards compatibility WordPress needs to deal with the myriad of crazy content generated by people (and plugins!) over the years. Often this gets very chatty and very inefficient.
Besides backwards compatibility, this codebase grew like a jungle, with people just piling code on, not always with much forethought. Part of it's due to the limitations of PHP in the old days, and of course it's inherent with projects of this size, but there are varying degrees of messiness. WordPress is an example of a project that started out too messy and only became more messy over time.
Just to pile on: the WPDB class is another example of continued messiness. The first thing I do whenever I write a plugin, is to add a little database wrapper that just uses PHP PDO instead. Anything better than to deal with the hopeless, inefficient, inflexible mess that is WPDB. (To whoever wrote it: sorry mate!)
Edit: this guy said it better: https://news.ycombinator.com/item?id=41729827
Or maybe it is just fine for their use case and they are making already enough money with it...
Actually this is wrong. Yes the constant WP_POST_REVISIONS exists. But WP Engine has disabled this constant. They do in fact "butcher" WordPress in the sense that they remove a feature, you can't turn it back on by yourself, and you need to talk to their support to get a limited version of it re-enabled by them.
Add to that, revisions are a big deal for a certain type of customer. Say, an enterprise scale publisher for example who has built an extensive publishing workflow around WP. (Hacker News consistently underestimates how massive some WordPress installs are; the scale of the world's biggest publishers, many of whom rely on WordPress, blows your nice little startup out of the water.)
So I am aware of a case or two where this actually became a negotiating point in an enterprise contract. The customer was entirely unaware that revisions were just a free thing built into WP, and it influenced the resulting contract and cost. Dirty dirty on WPE's side, really.
BTW this is documented at https://wpengine.com/support/platform-settings/ and you can see on that page that they limit their environment in many other ways. In the abstract this may not be a huge problem, hosts have costs and security and various limitations to think about. In my personal experience there are limitations which are not listed on that page and those are more frustrating.
Intel, Google, even Microsoft etc. develop improvements to Linux knowing full well that their competitors will also get access to those improvements. For sure it's disappointing that WP Engine contributes almost no time to Core.
Oh, I remember now. I was wondering why ACF didn't become part of the core.
We can have debates about whether this philosophy is the right one or not but there's no point. It's what it is and it makes fixing things like this simply not possible.
It's a well-engineered product whether you want to accept it or not. Unlike more than half of the tech world that's unprofitable and is just a fart in the wind of tech memory.
WP is a well-delivered product that works well for its user base in most situations. Plenty of code is well-marketed, profitable, and fulfills users' needs, but not well-engineered.
By the way, I know the PHP gripe is contentious, but it's not the reason why I think WP is badly engineered, it's just the reason it was easier to engineer it badly.
See https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ for more details on PHP.
One excerpt from that page:
There is a whole lot of action at a distance. Consider this code, taken from the PHP docs somewhere.
@fopen('http://example.com/not-existing-file', 'r');
What will it do?
If PHP was compiled with --disable-url-fopen-wrapper, it won’t work. (Docs don’t say what “won’t work” means; returns null, throws exception?) Note that this flag was removed in PHP 5.2.5.
If allow_url_fopen is disabled in php.ini, this still won’t work. (How? No idea.)
Because of the @, the warning about the non-existent file won’t be printed.
But it will be printed if scream.enabled is set in php.ini.
Or if scream.enabled is set manually with ini_set.
But not if the right error_reporting level isn’t set.
If it is printed, exactly where it goes depends on display_errors, again in php.ini. Or ini_set.
I can’t tell how this innocuous function call will behave without consulting compile-time flags, server-wide configuration, and configuration done in my program. And this is all built in behavior.
Although I think the exception there is security (and yes I know many will say clean and well engineered code is secure code). Security has to be solid or it will impact too many people negatively.
Yeah good luck with that. Something so deeply embedded in WordPress Core impossible to improve upon.
I do know they exist of course, Sony being one.
I’m coding up a little something that I feel is more modern and superior compared to WP, and I’d like to learn what their business requirements and use cases are that keep them on WP.
Thanks in advance!
Something that feels powerful and safe; like WP of 10 to 15 years ago.
It's a very nuanced thing. The world could be very different today. There would have been very little pushback against Matt's crusade if he'd just thought about making sure service to users was uninterrupted.
Instead he dragged 1.5 million sites into the middle of this in a way that made him look like the bad guy.
I hope that WordPress will continue to be open and Matt will continue to lead it, but he just cost himself a lot mindshare. That's why I asked him to explain why he made the choice he did.
Hopefully he has a PR person who is advising him on how to handle this situation. Were it me, I would say something like: "My passion for keeping WordPress open source got the better of me and I made a hasty decision which caused problems for end users. I've learned from this and it's not a mistake I will ever repeat. Going forward if there are changes to how we administer WPorg's services we will discuss them with the community and announce them well in advance because we want them to be rock solid and reliable for all of the millions of websites which depend on them."
This type of statement would go over well with a lot of people including the big enterprise customers who are depending on WP, who Matt really wants and who are constantly being courted by WP's competitors. In followup messaging you can reiterate all the strengths of open source e.g. how it reduces vendor lock-in.
But what do I know, I've only sold a couple million dollars worth of WP contracts, meanwhile Matt is worth 400 of those big M's. :)
According to Automattic they had been in discussions for 20 months. Your anger should be with WPEngine for taking your money while knowing full well their service depended on servers ran by a company they were on (best case) shaky terms with.
Up until about 8 months ago, Bluehost (another big paid hoster of WordPress sites) ran its own plugin mirror with no issues: https://github.com/bluehost/pluginmirror
They could have give a warning 20 months ago that this may happen and then this would not be a thing.
Or is the 20 months thing just completely irrelevant to the point that Automattic should've given a heads up before cutting off plug-in updates
I mean yeah, companies should have contingency plans for things that are extraordinarily rare but let's be reasonable about it. No one, including you, saw this coming.
I challenge you to find a single blog post, tweet or HN/Reddit comment that suggests Matt could one day shut off wp.org access to a single company running 1.5 million sites without any notice to that company, or the community members who will be affected. It's unconscionable. Or at least it was.
Be reasonable.
https://wordpressfoundation.org/trademark-policy/#:~:text=If....
In a social media post on the platform X, he boasted that as a result of his actions, WPE is now a “distressed asset,” worth just a “fraction” of what it was before, because “[c]ustomers are leaving in droves” – calling into question whether Defendants’ motivations extend beyond mere interference and extortion, and are in fact a thinly disguised attempt to artificially drive down WPE’s valuation in hopes of acquiring it on the cheap
Its not unlikely that the gameplan all along was slander and disrupt them so much that the company would become worthless, then acquire it. He was trying to blackmail/extort WPE's CEO into coming to work for him, after all! (text message screenshots are in the lawsuit too)
I would think that is a cost-saving measure as well. A hell of a lot of that data would be downloaded by users every day. Being able to pull it locally saves all that. Also, it is faster and does provide some security.
> They do not depend on Canonical to run their business.
That depends on how you look at it. If for some odd reason Canonical vanished tomorrow, that would be a big problem for both DO and AWS.
They do rely on Canonical developing, fixing upgrading the distros.
But then Amazon does have their own in-house Linux distro, which is/used to be somewhat associated with RedHat/ Centos https://github.com/amazonlinux/amazon-linux-2023
I would expect AWs,Google etc have specific internal only distros that make up the foundation of their cloud business but that is just a guess.
That is something the WordPress community (albeit centralised in the WordPress.org decision makers) could have been doing for decades.
That would be Matt as the sole owner of wordpress.org, not a plural 'decision makers'