Matt Mullenweg: Users Should Never Know WordPress Has Updated
Matt Mullenweg, the co-founder of WordPress, gave one of the keynote addresses at this year’s Joomla World Conference.
Of course, it was interesting that the JWC invited Matt and that he accepted.
Equally interesting was that he used the keynote to talk about several issues that were news even to WordPress junkies. For example, he mentioned that WordPress 3.8 would ship on its intended release date of December 12th. With previous versions, WordPress release dates have been much more flexible.
However, despite all of the people in the audience and watching on the livestream, perhaps the most revolutionary idea has been missed.
Matt presented a very clear vision in which WordPress runs like a software-as-a-service product. His vision is that WordPress, and all themes and plugins, should update silently and almost constantly.
If this vision comes true, users will never need to know when there’s an update and developers can push code every hour if they want to.
Matt’s vision for constant, silent updates
Here’s the text of what Matt said. He had been talking about the history of WordPress and had just arrived at version 3.7, released in October:
“A big thing that came out in 3.7 was auto-updates.
So now WordPress core, when 3.7.1 came out with bug-fixes, all the WordPresses that were able to, updated themselves and people just got an email that their site had been updated.
We had a 99.997% success rate so only a couple of hundred sites failed and within those the system is very … Grab Andy (Andrew Nacin, WordPress code developer, sitting in the audience) and he’ll talk your ear off about all the millions of contortions it goes through to work across the heterogeneous host: Windows, Linux, different file permissions, things that can happen, checking the integrity of the files over the wire. There’s a gajillion things that go to this happening and we’re doing this for core now.
The vision is that in the future we’ll do it for plugins, we’ll do it for themes, we’ll do it for major releases as well as minor releases.
So let’s say that you load up Facebook today,
What version of Facebook are you running?
Even on your computer, what version of Chrome are you running? You can go and look – it’s like version 33 or something like that – but you don’t, you’re just using Chrome that day. And that’s eventually how I’d like WordPress to work, where you just open up WordPress and get that day’s version of WordPress.
On WordPress.com we push code live to the site, to deploy to thousands of servers over 100 times per day. As a developer that is addictive. It’s like crack hits. It’s amazing how great it is to be able to iterate and ship things fast and see how people use things and move quickly.
I think this is how modern software development can and should work and so shifting our open source project to be like that, meaning that we can iterate just as quickly as our proprietary competitors I think is key to WordPress remaining competitive over the next 10 years.”
This vision, if achieved, would truly revolutionize how open source software development is done. It would mean the end of any notion of a release cycle as we know it today.
Also, although Matt doesn’t mention it, such a move could radically improve the security of WordPress. 3 weeks after the release of 3.7, only 8% of all WordPress sites have updated (link). At the moment so many sites update so slowly that together they present a serious hacking risk.
This section where Matt outlines his vision runs for about 2 minutes from 39:00 to 41:00:
{snippet mattjwcvideo}
What are your thoughts?
Should open source projects run with silent, background updates?
Is this an essential feature to allow open source to compete or is it a recipe for disaster?
If you develop themes or plugins, would you want to update them automatically?
Let us know in the comments below …
It’s about weighing risks. This has always been a balancing act between the risk of functionality & design breaking versus the risk of site security being compromised.
Up until recently, that argument almost always came down on the site of the functionality/design change being too great.
But now, with the massive amount of automated attacks on old exploits, the pendulum has swung. The risk of a security compromise is very high if you’re running an older release of a popular CMS, so auto-update becomes the low risk option.
Yes, great point, Alastair. That’s probably one reason why they’re phasing this in over months or years.
I suspect the WP team have a few sleepless nights, dreaming of massive WordPress-powered botnets. Even If they can move from 8% of sites being up-to-date to 50% being up-to-date, that would be a huge win.
Security updates are one thing – Most software separates security updates from form and function updates. If not in options, at least you’re told which is which. Exploit patching certainly shouldn’t be treated the same way as implementing new functionality and changing your themes, like was mentioned.
In a world where WordPress has no plugins and no one develops anything to work alongside wordpress, that’s a great idea. In the real world, it’s moronic.
Specs change, APIs change, databases get restructured. Automatic updates was already a terrible idea. Automatic updates without even telling the admin? That’s insane. WordPress has been developed from a blogging platform into a wannabe-CMS, it needs to be treated like one if it’s going to stay in that direction.
Even if you don’t develop extras for wordpress – he mentioned updating themes and plugins automatically. What? WHAT? The look and feel of your site to your users, and even your administration changing without your permission or even your KNOWLEDGE?
Then there’s the terrible examples Matt gave:
1.) Facebook – You don’t administer facebook, you use it at a restricted level. It’s not even comparable to running wordpress.
2) Chrome – Chrome serves a much simpler purpose than wordpress. Your chrome installation doesn’t affect your web presence for your business, or how what you write is read.
All in all… Matt Mullenweg sounds like he doesn’t even understand what wordpress is used for.
Hi Moregon
I’d say this is probably an 80% decision: [url=http://wordpress.org/about/philosophy/]http://wordpress.org/about/…[/url]
I’m with you as a developer. I would also turn this feature off. No large site I’ve ever dealt with (be it WordPress / Joomla / Drupal or something else) never runs the latest release because there’s so much testing to do with every update. For people like us it’s easy to turn auto-updates off – we’re the 20%.
For the other 80% of WP users, they have the opposite problem. They never update because they either scared to or don’t know how to. Maybe it’s not a coincidence that 80% to 90% of WordPress sites are out-of-date and have security vulnerabilities. That’s the target audience for this.
To be honest, those users sound like the kind of people that should be using [url=http://wordpress.com]wordpress.com[/url] or another hosted solution – not self-installs. Rather than changing the whole paradigm of how wordpress is deployed and managed, I’d think it’d be easier to expand the hosted functionality for the edge cases of people that don’t fit there but don’t have expanded functionality.
I’m very thankful the ability to turn off the updates is added in – but I think it’s a scary direction to take, especially for people that aren’t so technically inclined but still want to maintain a strict image.
I think a nice compromise would be update channels – like core, security, admin UI, themes, plugins – where core and security are the only ones enabled by default.
No, I think Matt is pretty smart. This way he can force 3rd party devs to be intimately involved with the core and very attentive to it if they want to have happy customers. Devs who do things wrong in their own non-standard way will have their stuff break, and it will upset those who use their plugins, and guess who will be blamed: the people who deserve it, not Matt. The WP plugin and theme ecosystem is evolving nicely with a strong set of top-shelf vendors who play well together and understand how to make and sell premium products. The kind of dissent this will spawn will be the John O’Nolan types who want WP to be something different and totally cutting edge, or who want to be the center of their own galaxy. For some that galaxy may be relatively modest in size compared to WP — like the folks behind Statamic, Kirby, Perch, Expression Engine, and other OSS based on small licensing fees. I welcome the stability and proven success on the one hand as well as the innovation and diversity of choices on the other.
I get what you’re saying, and it’s a great mindset to have idealistically.
However, realistically, it’s going to cost people viewers/readers/customers and business, and they’re going to abandon wordpress or make extra expenditures to have someone manage it for them.
It will make people shun plugins and themes developed by the community, and only attempt to use things that have been vetted by extreme exposure and/or a high price tag, because they can’t take the risk of a bad 3rd party update, or something not playing well with an update to WP.
It sounds like a death sentence to the platform, not an improvement.
I think that’s a very poor prediction. Even if WP lost significant “market share” because of backward compatibility issues in minor upgrades-in-place, what is the value of the share that would be lost?
Those who are burned by their inability to maintain a basic level of professionalism in sustaining the applications they rely on will be those who didn’t do things right in the first place and just installed all kinds of random things they don’t understand. WordPress managed hosting is booming along, and I don’t see people on WPengine and its peers getting blindsided by core updates. BlueHost Fantastico installs are the ones who will get hurt because they’re always getting hurt already!
If those newbie users have the resources to go back and do things right, that is going to be their most attractive option because it will always be far more expensive to change horses midstream and abandon WP. Those who are driven off by the difficulty or costs are frankly not bringing anything of value to anybody–quite the opposite. Retrograde third party software and poorly maintained sites bring a great deal of shame to WP, weaken its core markets, and spread DDoS/spam/malware worldwide. Nobody else will benefit from this “lost business” flocking to them, but what more “accessible” platform would they flee to exactly? What we’re really talking about is the young, DIY, and hobbyist contingent here that gets carried away making sites with generally no dollar value to anyone, and their way forward is to learn some valuable skills, hire others, or exit a market that will not miss them.
I see this move to core upgrades on autopilot as raising the bar for the community. It won’t eliminate free themes, plugins, etc. It may necessitate a long-needed sweep of the plugin directory though. What remains and starts afresh there would necessarily be stronger.
“I see this move to core upgrades on autopilot as raising the bar for the community”
Yes! That’s probably the phrase I was trying to think of 🙂
This move prioritizes the users over the developers.
It asks developers to step up and provide a better experience for users.
People who are in very specialized situations may need to have the option to control how they roll out upgrades, and they can do that. “Forcing” auto-updates on everyone else seems like a wise choice to me. The big question for WP is how far small, non-disruptive incremental upgrades can go before the core application is obsolete and requires a major overhaul. WP is like Windows XP. Joomla 1.5 was also in that position.
I would bet good money that seamless, flawless web updates on a stable base platform are far and away the single most important reason for WordPress’s meteoric rise to global supremacy. I predicted this in the Joomla forums to Andrew Eddie around 2010/WP 2.9. That was certainly the point at which many people felt WP had become a reliable (and quickly the go-to) solution for rapid, maximally efficient small to mid-sized website development. t.
I have never had a WP update break a site that I can recall. If it did, I expect it would expose some fault in a plugin, theme, or other third-party or custom code. Of course during the time autoupgrades have been possible, there have been no massive changes to the interface, data model, and API.
Agreed, Dan.
Yes, Joomla’s one example. Drupal’s another … when Drupal 8 comes out, their users will be spread over Drupal 6, 7 and 8. Plus, the community will be supporting all 3 versions, plus building Drupal 9.
If people think that supporting updates is a burden, try not supporting updates.
I agree completely. In this talk I hear Matt quietly suggesting a lot of things about where others went wrong and mistakes to learn from. Pushing out releases come hell or high water is one of the big ones. I wish someone had asked him what he was thinking about Joomla and Drupal pre-2010. I wouldn’t be surprised at all if he followed what they were doing more than they paid attention to WordPress.
Was this talk at the world conference well attended? I saw a lot of empty seats down front in the video.
Yes, surprisingly well so. Certainly as well as the other keynotes.
I think that most of them just sat at the back.