The WordPress War Over… Revisions?  ## Metadata - Author: [[Samuel Sidler]] - Full Title: The WordPress War Over… Revisions? - Category: #articles - Document Note: --- tags: - #WordPress - #OpenSource - #TechIndustry Author: Courtney Robertson Source: Delta Blog Reference: [Read the article](https://www.delta.blog/the-wordpress-war-over-revisions/?__readwiseLocation=) date created: 2024-11-03 10:00 --- # Title: The WordPress War Over Revisions ## Table of Contents: - [📝 Summary](#summary) - [📖 Main Content](#main-content) - [🗒️ Notes](#notes) - [📖 References](#references) - [🗣️ Paraphrase](#paraphrase) - [📰 Newsletter](#newsletter) - [✅ Action Items](#action-items) ### References: - Delta Blog - TechCrunch Disrupt Interview 2024 - WordPress.org - WP Engine ## 📝 Summary: The article discusses a significant conflict within the WordPress community, focusing on a legal battle over code revisions and the implications for the open-source ecosystem. It highlights key players, their positions, and potential consequences for the future of WordPress. ## 📖 Main Content: The piece explores the ongoing legal dispute involving major entities in the WordPress ecosystem. It underscores the tension between maintaining an open-source philosophy and the commercial pressures faced by large entities leveraging the WordPress name and infrastructure. Insights from community leaders and experts paint a complex picture of the challenges and stakes involved. ### 🗒️ Notes: - **Background**: Description of the initial cause of the conflict and the parties involved. - **Legal Aspects**: Analysis of the legal claims and defenses. - **Community Impact**: Examination of the dispute's impact on the WordPress community. - **Future Implications**: Discussion on how this might affect the future of open-source projects. ## 📖 References: - Delta Blog Article - TechCrunch Disrupt Interview with Matt Mullenweg ## 🗣️ Paraphrase: 1. "The ongoing dispute has not only legal but also ethical implications for how open-source projects should operate when commercial interests are at play." — The article stresses the delicate balance between open-source ideals and commercial realities. 2. "Community leaders are calling for a resolution that ensures the sustainability of the WordPress ecosystem without compromising its foundational principles." — There is a strong community drive to resolve the conflict in a way that upholds the core values of WordPress. ## 📰 Newsletter: **WordPress Weekly** In this week's issue, we delve into a hot topic stirring our community: the revision rights battle. As we navigate these challenging waters, it's vital to stay informed about how such disputes can reshape the landscape of open-source software and affect us all. For a detailed analysis and expert insights, be sure to read the full article [here](https://www.delta.blog/the-wordpress-war-over-revisions/?__readwiseLocation=). Let's keep our community strong, informed, and engaged! ## ✅ Action Items: As a Developer Advocate, it is crucial to use this situation as a case study for discussions on the ethical management of open-source projects. Facilitate workshops and seminars that highlight the importance of balancing commercial success with open-source contributions. Engage with the community to advocate for policies that protect the interests of all stakeholders involved. ## 🧪 Hypotheses: Future research could explore the impact of legal disputes on the innovation rate within open-source communities. ### 📊 Methodology: Employ qualitative interviews and quantitative data analysis to assess the long-term effects of such disputes on community contributions and project sustainability. ### ❓ Questions: - How can open-source communities better protect themselves from similar disputes? - What mechanisms can be implemented to ensure fair contributions from all commercial entities benefiting from open-source software? ### 🔮 Future Research: Investigate alternative governance models that could be employed by open-source communities to prevent or mitigate conflicts arising from commercial pressures. ### 💡 Implications: Understanding these conflicts can lead to more robust governance structures in open-source projects, potentially influencing how similar disputes are handled in the future. ### 🧠 Learning Styles Assessment: The article provides a comprehensive analysis suitable for various learning styles but lacks interactive elements that could enhance engagement for kinesthetic learners. ### 📊 Accessibility Assessment: The article is accessible, with clear headings and structured content. However, enhancing contrast and providing alt-text for all images could improve accessibility further. ### 🌍 DEIB (Diversity, Equity, Inclusion, and Belonging) Assessment: The discussion includes multiple perspectives, but increasing representation from underrepresented groups in follow-up discussions could enhance diversity. ### ✅ Logical validity: The arguments presented are well-supported by evidence, but the article could benefit from more direct engagement with counterarguments to strengthen its analytical rigor. ### 🔍 DARVO Analysis Prompt: There is no indication of DARVO tactics being used in this content, as it maintains a factual and analytical approach to the discussion. ### 🔍 SEO Evaluation: The article uses relevant keywords effectively, but could improve its reach by optimizing meta descriptions and enhancing internal linking strategies to better engage and inform a broader audience. ## 🎯 Conclusion: The WordPress revision conflict is a pivotal moment for the community, highlighting the need for a balanced approach to commercial involvement in open-source projects. It serves as a reminder of the importance of maintaining open-source integrity in the face of growing business interests. - Document Tags: [[lawsuit]] [[Matt Mullenweg]] [[4. Archives/GoDaddy/FOCUS/Pagely/Pagely]] [[WordPress]] [[wpdrama]] [[wp engine]] - Summary: WordPress revisions cannot be the cause of the Matt Mullenweg vs WP Engine war. - URL: https://www.delta.blog/the-wordpress-war-over-revisions/ Photo by [Volodymyr Kondriianenko](https://unsplash.com/@entrpswn) / [Unsplash](https://unsplash.com/?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit) *Quick note: It’s been a hot minute. Over the past ~2 weeks, I had planned to muse on a few topics, especially the legal filings from both WP Engine and Automattic. However, two weeks ago I was laid off. Going forward, I plan to set aside writing time each week, primarily on this site.* This past Wednesday, at TechCrunch’s Disrupt conference, [Matt Mullenweg joined TechCrunch Editor-in-Chief and General Manager, Connie Loizos, for an interview on stage](https://www.youtube.com/watch?v=Fn_HzfI_sW0&ref=delta.blog).[[1]](https://www.delta.blog/the-wordpress-war-over-revisions/#fn1) In my opinion, it’s a reasonably balanced interview, mostly covering his “war” with WP Engine. At approximately 8:45 in the interview, Loizos leads into her next question (my emphasis): > So, again, just trying to get to the root of, I guess, what’s happening and how it gets resolved. So, you’re frustrated by some of the things that they did, **including making the revision history harder to manage**. I guess the question is: Was that any of your business to start with? > > Loizos’ question references [the WordPress.org post from Mullenweg on September 21, 2024](https://wordpress.org/news/2024/09/wp-engine/?ref=delta.blog), in which he called out WP Engine, stating it’s not WordPress and, as an example, added: > WordPress is a content management system, and the content is sacred. Every change you make to every page, every post, is tracked in a revision system, just like the Wikipedia. This means if you make a mistake, you can always undo it. It also means if you’re trying to figure out why something is on a page, you can see precisely the history and edits that led to it. These revisions are stored in our database. > > This is very important, it’s at the core of the user promise of protecting your data, and it’s why WordPress is architected and designed to never lose anything. > > **WP Engine turns this off.** They disable revisions because it costs them more money to store the history of the changes in the database, and they don’t want to spend that to protect your content. It strikes to the very heart of what WordPress does, and they shatter it, the integrity of your content. If you make a mistake, you have no way to get your content back, breaking the core promise of what WordPress does, which is manage and protect your content. > > (The post is longer, of course, but the above summarizes Mullenweg’s key argument.) The day this post was made, WordPress developers worldwide squinted and muttered, “this is certainly an *interesting* argument, given how WordPress works…” I don’t have access to WP Engine’s internal systems or, more importantly, the precise must-use plugins (“mu-plugins”) they use on every managed WordPress installation. I *also don’t know* the mu-plugins that Automattic uses for their WordPress.com and WordPress.com VIP offerings. However, I *do have access* to public documentation. Before Mullenweg’s post, I had no idea that WP Engine disabled WordPress revisions. However, it’s well-known within the community that a large WordPress database can cause performance issues. Moreover, it’s widely known that revisions, in particular, contribute significantly to a large database, directly impacting performance. But, don’t take my word for it. Kinsta, a managed WordPress hosting provider [says the following](https://kinsta.com/blog/wordpress-revisions/?ref=delta.blog): > The larger your database is, the more storage space it’ll occupy. Unfortunately, this can slow your site down and lead to longer loading times, hampering your site’s user experience and search engine optimization (SEO). > > Therefore, it’s critical to learn how to control revisions in WordPress to your advantage. > > … before explaining how to disable, delete, and limit revisions in WordPress. [In its documentation about optimizing performance](https://www.siteground.com/tutorials/wordpress/optimize-performance/?ref=delta.blog#Disable_or_Limit_Post_Revisions), SiteGround, another managed WordPress hosting provider, states the following: > Over time, these revisions can accumulate, significantly increasing the size of your database. A larger database can slow down your website, as it takes longer for WordPress to retrieve and display data. By limiting or disabling revisions, you keep your database more streamlined and efficient. > > … and then explains how to limit and disable revisions in WordPress. Pantheon, which provides both WordPress and Drupal hosting services, [writes the following about WordPress and revisions](https://pantheon.io/blog/tips-trimming-wordpress-database-revisions?ref=delta.blog): > WordPress is a wonderful tool, but there are still a few holes in its architecture.[[2]](https://www.delta.blog/the-wordpress-war-over-revisions/#fn2) The fact that revisions stack up in your database is one of these holes. > > … before providing instructions for, you guessed it, removing and limiting revisions. Another managed WordPress hosting provide, Pagely, [provides the following in its documentation](https://support.pagely.com/hc/en-us/articles/210623337-Enabling-and-Modifying-WordPress-Post-Revisions-Behavior?ref=delta.blog) (my emphasis): > Saving all WordPress post revisions forever might sound good on the surface, but the database can quickly become cluttered. Over time, this can become a significant issue if lots of edits are made to site that has been up for a long time or if the site has many authors generating new posts and edits. > > By default **Pagely has opted to disable revisions** unless they are needed by the user. > > … yep, that’s right—Pagely, like WP Engine, also disables revisions by default. Is their offering considered “WordPress”?[[3]](https://www.delta.blog/the-wordpress-war-over-revisions/#fn3) On [the list of recommended WordPress hosts](https://wordpress.org/hosting/?ref=delta.blog), published on the Mullenweg-owned-and-operated WordPress.org website, sits Hostinger, which [writes about fixing “overloaded” WordPress sites](https://support.hostinger.com/en/articles/7043596-how-to-fix-an-overloaded-wordpress-website?ref=delta.blog#h_8c50f9a855): > WordPress saves all revisions by default, making the website database heavier as more revisions are stored. > > … before providing instructions on how to limit revisions. They provide [additional details and options for limiting or disabling revisions](https://www.hostinger.com/tutorials/wordpress-revisions?ref=delta.blog#Advantages_and_Disadvantages_of_WordPress_Revisions) elsewhere, deeming it important enough [to publish a second time less than six months later](https://www.hostinger.com/tutorials/wordpress-database-optimization?ref=delta.blog#Revisions). Another host recommended by Mullenweg on WordPress.org is DreamHost, which [notes in their documentation about optimizing WordPress databases](https://help.dreamhost.com/hc/en-us/articles/4404267062164-Optimizing-WordPress-databases?ref=delta.blog): > WordPress post revisions are historical or autosaved versions of your site's posts. WordPress limits the revision count to 10 by default, but these can expand as your site's post count grows. Use the commands below to clean up revisions in your site's database. > > **This isn’t actually true.** WordPress-the-software does *not* limit revision count at all[[4]](https://www.delta.blog/the-wordpress-war-over-revisions/#fn4), so this statement implies that WordPress *on DreamHost* limits revisions to 10 posts. Perhaps more interesting is [this post from 2023](https://jetpack.com/blog/wordpress-revisions/?ref=delta.blog), from Automattic-owned Jetpack, which blogs (my emphasis): > For example, **WordPress.com saves 25 revisions for Free, Personal, and Premium plans, and 100 revisions for Business and eCommerce plans**. > > If you have lots of revisions, they can clog up your database and slow down your site. > > You read that right! The Automattic-owned WordPress.com limits revisions. Even Automattic’s *enterprise* WordPress.com VIP limits revisions. In [a pull request from May 25, 2023](https://github.com/Automattic/vip-go-skeleton/pull/95?ref=delta.blog), an engineer limited revisions to 100, fewer than the original 500. Except, wait! [That code was commented out by WordPress.com VIP’s Chief Technology Officer Brian Alvey on September 23, 2024](https://github.com/Automattic/vip-go-skeleton/pull/114?ref=delta.blog),[[5]](https://www.delta.blog/the-wordpress-war-over-revisions/#fn5) just two days after Mullenweg’s post on WordPress.org about WP Engine. Around the same time, WordPress.com VIP’s public documentation was also updated. Previously, [it read](http://web.archive.org/web/20240922014030/https://docs.wpvip.com/wordpress-on-vip/post-revisions/): > By default, VIP environments store the last 100 revisions. > > It’s clear now, from statements made by Mullenweg after September 21, and through to the TechCrunch interview, that the underlying issue is *not* about how WP Engine handles revisions. However, it seems curious that many of the statements from Mullenweg reference how “different” the product that WP Engine provides is from WordPress users download from WordPress.org. The fact is, *every* WordPress host modifies WordPress, usually through mu-plugins. *Every* WordPress host balances performance, features, and cost to ensure they’re providing the right product to its customers. Every *business* tries to meet the needs of its customers for the best possible price. Customers, meanwhile, are savvy—they compare offerings, looking primarily at costs and features. If an offering isn’t living up to the demands of the market, businesses can either adjust, or fail. That WP Engine has grown its sales to $400 million per year[[6]](https://www.delta.blog/the-wordpress-war-over-revisions/#fn6) says that its customers by-and-large *like* WP Engine’s product—they *like* the modifications WP Engine has made to WordPress through mu-plugins, paired with the base product WordPress provides. They think it balances well the pricing WP Engine offers, even with its tradeoffs. #### So, what does this mean? When I worked at Automattic, my team oversaw the dreaded “Merge”—the moment in time when the WordPress core software was merged into WordPress.com, combining years of code customizations that make up “WordPress.com” with the community-created codebase that makes up “WordPress.” It wasn’t pretty. The code customizations felt endless, and *often* conflicted with WordPress core. *Certainly*, the situation has improved in the intervening years, but I have no doubt that the process is still complex, and custom modifications persist. In understanding motivations and rationale for this proclaimed “war”, we’ve seen conflicting reports—was the offence “[bastardized simulacra](https://wordpress.org/news/2024/09/wp-engine-banned/?ref=delta.blog),” “trademarks,” “lack of contribution,” or something else entirely? To take Mullenweg’s argument about “bastardized simulacra” to its logical end, Mullenweg must believe that millions of customers have been wrong all along—they’ve somehow been duped. The product they’re using isn’t WordPress, even though that’s what they’re buying. And, what’s more, the changes WP Engine has made are so bad, so egregious, that virtually every major WordPress host does the exact same thing… including Automattic’s WordPress.com and WordPress.com VIP products, which both limited revisions before Mullenweg’s September 21 blog post, and all heavily modify WordPress through custom code, whether direct or via mu-plugins. The argument doesn’t hold. Given this, it should be abundantly clear that, *whatever* the cause of this war, Mullenweg didn’t suddenly start to oppose WordPress customization—his opposition was purely and solely to *WP Engine*. 1. As it so happens, I was in the audience, sitting in the front row, during the interview. I was pleased to see Loizos reference BlackRock’s devaluation of Automattic, something (I believe) [I was first to report on](https://www.delta.blog/investments-in-the-wordpress-ecosystem/). [↩︎](https://www.delta.blog/the-wordpress-war-over-revisions/#fnref1) 2. Harsh. Accurate, but harsh. [↩︎](https://www.delta.blog/the-wordpress-war-over-revisions/#fnref2) 3. Yes. [↩︎](https://www.delta.blog/the-wordpress-war-over-revisions/#fnref3) 4. Revisions haven’t been limited by WordPress core [since the feature was introduced in 2008](https://github.com/WordPress/wordpress-develop/commit/1c4f5de9a158b3023667ed8c2bdfbdc6aa4808c8?ref=delta.blog#diff-d4707e10d4f96e2329ee1369445430cdb9e0ec75e7bf70ec99b40325550801b7R379). [↩︎](https://www.delta.blog/the-wordpress-war-over-revisions/#fnref4) 5. I am neither an engineer nor a CTO, but I don’t believe it’s best practice to comment out production code like this. With version control, I’d expect an engineer to remove the code entirely, knowing the change can be reverted later, if needed. [↩︎](https://www.delta.blog/the-wordpress-war-over-revisions/#fnref5) 6. As reported by Mullenweg, in any case. WP Engine is still a private company. [↩︎](https://www.delta.blog/the-wordpress-war-over-revisions/#fnref6), The WordPress War Over… Revisions?, Samuel Sidler, 01jbs8f0qsqk14t3h4x9gxa6d9.