A CEO is no longer expected to talk candidly about open source. Maybe business leaders have never expected open source to be anything but serve their business interests. Not every CEO takes advantage of open source to the degree we have seen in recent months. But no one is free of blame. Open source means different things to different people, and everyone uses it for their own purposes.
The colloquial use of open source gives companies like Meta the opportunity to use open source as they wish. Even high-ranking people in the open source community discount the problem. They say it’s OK. Open source is still moving forward. The kids don’t care — all they want to do is build models.
There is no playbook or good versus evil here. Many thoughtful people want to find a way to solve the mess we’ve seen surface in the WordPress saga of the past few weeks.
To recap, for those who haven’t been sufficiently online the past few days: Matt Mullenweg, co-creator of WordPress, the popular open source content management system, has been accusing WP Engine, a WordPress hosting provider, of violating WordPress’ trademarks and using its servers without compensation. The two organizations’ lawyers have exchanged cease-and-desist letters (more on those later). At the stroke of midnight UTC on Tuesday, WordPress blocked WP Engine’s access to its servers.
As this episode unravels, a fresh flow of ideas about open source has emerged. At least one CEO has established an important approach to solving issues like those we see with WordPress and WP Engine.
In a thoughtful post on his personal blog, Dries Buytaer, creator of Drupal, described the issue today as a makers-takers problem, where “creators of open source software (“Makers”) see their work being used by others, often service providers, who profit from it without contributing back in a meaningful or fair way (“Takers”).”
CEOs are on both sides of the perspective he details. He knows the people involved and has a solution that makes sense for the Drupal community. He calls it a “contributor credit” program.
Buytaer comes from the same world as Mullenweg. Drupal and WordPress are open source content management systems.
Still, open source is a tool for CEOs to use for profits, sometimes illusions, and leverage against commercial competitors. We’ve seen this with Meta CEO Mark Zuckerberg, who calls Llama, the company’s large language model, open source, which it is not.
And now we face someone who has long enjoyed a gleaming image in the open source community but now faces many questions about his intent.
Earlier in the week, we interviewed Mullenweg, who said WP Engine should fork WordPress.
“I think a fork would be amazing,” he told TNS. “They should fork WordPress, because what they offer is not actually WordPress. They call it WordPress, but they really screw it up.”
Mullenweg now wants to own a chunk of WP Engine, and he’s using his bully pulpit to pound away until he gets what he wants. He’s called WP Engine “a cancer.” He openly rails about the WP Engine executive team and Silver Lake, the private equity firm that has invested in it, using tactics we’ve become far too accustomed to from all sorts, who we don’t have to name here.
It’s a victim tactic. Mullenweg and Automattic, his holding company, talk like they are the victims of an evil plan, rooted in trademark violations. Following the victim’s logic, Mullenweg has to attack. He and his team have to block WP Engine from the WordPress servers.
Now comes the news from The Verge that WordPress demanded 8% of WP Engine revenues each month in exchange for being considered a contributor to the WordPress open source project. That would also mean WP Engine could not fork WordPress, but it would allow WP Engine to use the trademark.
The Verge:
“[C]hoosing to contribute 8 percent to WP Engine employees would give WordPress.org and Automattic ‘full audit rights’ and “access to employee records and time-tracking” at the company. The agreement also comes with a ban on ‘forking or modifying’ Automattic’s software, including plug-ins and extensions like WooCommerce.”
This raises questions about Mullenweg’s hearty support for a WP Engine fork. For perspective, WP Engine competes with Automattic. Just be clear on that one.
Mullenweg has made it confusing for almost everyone involved. There are huge supporters who want WordPress to survive, and there are end users who don’t have any clue about open source or even that their sites run on WordPress servers.
WP Engine, on the other hand, has its own issues. It does not give much in return for using WordPress. The company, under CEO Heather Brunner and founder Jason Cohen, uses the WordPress name. They call it fair use.
Further, WP Engine uses the work invested by the WordPress community into the service without the engineering overhead required if it had to maintain its own fork, which would cost millions and take quite some time to develop — a year, two, three?
What drama. If you are hearing about this for the first time, Mullenweg, who created the web content management system WordPress, has been relentless with his attacks on WP Engine for what he claims are trademark violations. It came to a head at WordCamp in Portland earlier in September when Mullenweg called WP Engine “a cancer” on the community.
On Sept. 23, attorneys sent a cease-and-desist letter to WP Engine on behalf of Mullenweg’s holding company Automattic and WooCommerce. Among its demands: that WP Engine stop all unauthorized use of WordPress’s trademarks and “provide an accounting of all profits from the service offerings that have made unauthorized use of our Client’s intellectual property.”
The letter suggested that “even a mere 8% royalty on WP Engine’s $400+ million in annual revenue equates to more than $32 million in annual lost licensing revenue for our Client.”
On Sept. 25, in lieu of action by WP Engine, Mullenweg blocked WP Engine’s access to the WordPress servers. He then gave a reprieve on Sept. 27 after users contacted him. Mullenweg said users thought they were paying WordPress, not WP Engine.
“They thought they were paying me, to be honest, that’s why they were pissed off,” Mullenweg said. “And so I was like, ‘Oops, OK, we’ll turn it back on.’“
WordPress blocked WP Engine’s access to its servers Tuesday at UTC 00:00.
The odd thing: no sign of trouble so far from WP Engine users; a WP Engine spokesperson declined to comment when contacted by TNS about whether the company had heard from customers having problems. WP Engine must have set up the mirrors and all to WordPress.org. How that affects performance and the rest is still not understood.
In our interview, Mullenweg said users now hopefully understand that they are paying WP Engine, which does not pay WordPress for auto updates and everything else WordPress provides. Users, he argued, should be mad at WP Engine, not him and his team, who run the servers. Again, Mullenweg expresses that he and his team are the victims.
WP Engine is simply not responding, Mullenweg said, except through a cease-and-desist letter its attorneys sent Automattic on Sept. 23 after his repeated attacks.
The letter sent on WP Engine’s behalf reads in part, “Mr. Mullenweg’s covert demand that WP Engine hand over tens of millions to his for-profit company Automattic, while publicly masquerading as an altruistic protector of the WordPress community, is disgraceful. WP Engine will not accede to these unconscionable demands, which not only harm WP Engine and its employees but also threaten the entire WordPress community.”
WP Engine did not answer The New Stack’s question about forking WordPress, but a company spokesperson did have choice words about Automattic’s licensing demands.
“We, like the rest of the WordPress community, use the WordPress mark to describe our business. Automattic’s suggestion that WP Engine needs a license to do that is simply wrong, and reflects a misunderstanding of trademark law. To moot its claimed concerns, we have eliminated the few examples Automattic gave in its Sept. 23 letter to us.”
For example, WP Engine has made some minor changes, namely changing WordPress to WordPress1 and WooCommerce1 on the site’s front page.
Overall, users had almost no warning that their sites would be disrupted. This is an odd way to treat users, especially when they are such huge fans of your platform.
Here’s where open source becomes a problem for users. Most people do not know how they get the updates to their CMS. But once their site stopped working, they became entangled in a battle between Mullenweg and WP Engine.
Meanwhile, most users are just trying to keep their sites working.
Post by @alexelnaugh
View on Threads
Amidst the controversy, Mullenweg acknowledged he could have done better in reaching out to the community.
“To be fair, I have not been the best at public relations or publishing things,” he told TNS. “That’s why we try to be very clear at UTC 00, Oct. 1 … at this exact time, their network, WP Engine servers will no longer be able to access our networks.”
But a fork? The cost to set up the servers, the network, the load balancers, on and on, would cost millions and could take years. At its peak, WordPress serves 30,000 requests per second and 40% of the entire Web, according to Mullenweg.
Users have an option, he said. They can move to a different hosting provider. He mentioned Bluehost and his own company, WordPress.com, as two options.
There has been confusion about open source AI and server-side public licenses. Now, we’ve got the WordPress debacle. Oh, and there’s talk about Oracle owning the JavaScript trademark. The fun never ends.
But people are working on the problem, particularly the single point of failure issue that has become more apparent since WP Engine’s servers were cut off.
Here’s a thread worth reading from Reddit, about how to solve the problem of a single point of truth. The problem is a severe one, but maybe a fork is not the answer. Instead, perhaps it’s a way to solve matters that can easily happen if sites aren’t updated:
The vulnerability should be apparent: if WordPress.org goes down for any reason, millions of sites stop updating. A coordinated attack (zero-day implementation coupled with a DDoS attack that prevents updates from going out from zero-day) could be a disaster the world over. And, if the Foundation ever decided to get out of the update business, or ran into financial difficulty, or Matt decides to retire to Aruba and quit WordPress entirely — whatever the case may be — there’s no Plan B.
So, the community needs a plan B — and maybe that’s most important. Stop the bickering. Instead, look for ways to modernize the WordPress infrastructure so users don’t get entangled in corporate wars that use open source as a proxy to fight battles that leave casualties scattered across the web.
YOUTUBE.COM/THENEWSTACK
Tech moves fast, don’t miss an episode. Subscribe to our YouTube
channel to stream all our podcasts, interviews, demos, and more.
“WPE’s nominative uses of those marks to refer to the open-source software platform and plugin used for its clients’ websites are fair uses under settled trademark law, and they are consistent with WordPress’ own guidelines and the practices of nearly all businesses in this space,” the lawsuit said.
Mullenweg told Ars that “we had numerous meetings with WPE over the past 20 months, including a previous term sheet that was delivered in July. The term sheet was meant to be simple, and if they had agreed to negotiate it we could have, but they refused to even take a call with me, so we called their bluff.” Automattic also published a timeline of meetings and calls between the two companies going back to 2023.
Mullenweg also said, “Automattic had the commercial rights to the WordPress trademark and could sub-license, hence why the payment should go to Automattic for commercial use of the trademark. Also the term sheet covered the WooCommerce trademark, which they also abuse, and is 100 percent owned by Automattic.”
Exhibit A in the lawsuit includes a letter to WP Engine CEO Heather Brunner from a trademark lawyer representing Automattic and a subsidiary, WooCommerce, which makes a plugin for WordPress.
“As you know, our Client owns all intellectual property rights globally in and to the world-famous WOOCOMMERCE and WOO trademarks; and the exclusive commercial rights from the WordPress Foundation to use, enforce, and sublicense the world-famous WORDPRESS trademark, among others, and all other associated intellectual property rights,” the letter said.
The letter alleged that “your blatant and widespread unlicensed use of our Client’s trademarks has infringed our Client’s rights and confused consumers into believing, falsely, that WP Engine is authorized, endorsed, or sponsored by, or otherwise affiliated or associated with, our Client.” It also alleged that “WP Engine’s entire business model is predicated on using our Client’s trademarks… to mislead consumers into believing there is an association between WP Engine and Automattic.”
Web hosting provider WP Engine has filed a lawsuit against Automattic, and WordPress co-founder Matt Mullenweg, accusing them of extortion and abuse of power. The lawsuit comes after nearly two weeks of tussling between Mullenweg, who is also CEO of Automattic, and WP Engine over trademark infringement and contributions to the open-source WordPress project.
WP Engine accused Automattic and Mullenweg of not keeping their promises to run WordPress open-source projects without any constraints and giving developers the freedom to build, run, modify and redistribute the software.
“Matt Mullenweg’s conduct over the last ten days has exposed significant conflicts of interest and governance issues that, if left unchecked, threaten to destroy that trust. WP Engine has no choice but to pursue these claims to protect its people, agency partners, customers, and the broader WordPress community,” the company said.
The case document, filed in a court in California, also accused Mullenweg of having a “long history of
obfuscating the true facts” about his control of WordPress Foundation and WordPress.org
Mullenweg had criticized WP Engine for infringing WordPress and WooCommerce trademarks. He called them the “Cancer of WordPress” and also called out WP Engine’s private equity partner, Silver Lake, for not caring about the open-source community.
Later, WP Engine sent a cease-and-desist letter, asking Mullenweg and Automattic to withdraw these comments. Automattic then sent its own cease-and-desist, accusing WP Engine of infringing WordPress and WooCommerce trademarks.
Notably, Mullenweg banned WP Engine on September 25 from accessing WordPress.org resources, including plug-ins and themes, and preventing WP Engine customers from updating them. Two days later, Mullenweg provided a temporary reprieve and unblocked WP Engine until October 1.
On Wednesday, Automattic published a proposed seven-year term sheet that it had sent to WP Engine on September 20, asking the hosting company to pay 8% of its gross revenues per month as a royalty fee for using the WordPress and WooCommerce trademarks.
Alternatively, WP Engine was given the option to commit 8% by deploying employees to contribute to WordPress’s core features and functionalities, or a combination of both people hours and money.
WP Engine didn’t accept these terms, which included a probation on forking plugins and extensions from Automattic and WooCommerce.
You can contact this reporter at [email protected] or on Signal: @ivan.42
It’s now time for Part 3 of our “Building Studio in Public” series! In today’s post, we’ll explore how the Studio app connects with other open source projects, with a focus on its key relationship with WordPress Playground. We’ll also dive into the benefits and challenges of this symbiotic relationship, showing how both projects mutually benefit from improvements and bug fixes.
If you’re following the series, be sure to check out past posts:
As a reminder, Studio is our free and open source local WordPress development app.
Studio relies on various open source projects, with the primary one being WordPress Playground which provides a local WordPress server, handling everything from running PHP code to serving static files and managing a database. This allows developers to test WordPress sites, plugins, and themes in a local, sandboxed environment.
WordPress Playground utilizes Emscripten to compile the PHP interpreter to WebAssembly, enabling PHP to run in the browser and other platforms—a significant leap for WordPress development.
By way of WordPress Playground, Studio also makes use of other open source tools like the SQLite integration plugin.
Studio itself is open source, which means the codebase is available for review, contribution, and forking by the community. This openness fosters collaboration, encourages innovation, and enables rapid identification and resolution of issues.
Because of the open source nature of Studio and the projects it uses like WordPress Playground, we are not blocked by missing or undesired behavior of our libraries but can instead help uncover issues or opportunities for enhancement in these projects and contribute the necessary fixes and improvements. Instead of building workarounds, we can directly enhance Studio’s performance and capabilities by submitting fixes to the actual problems.
This creates a virtuous cycle of improvement, showcasing how open source collaboration drives innovation and helps solve complex challenges.
WordPress Playground is powerful, but since it makes WordPress run in an unusual environment–the browser instead of a server–some things work differently than developers expect. While using it to power Studio allows us to achieve all the good things, like a fast setup, we also had to overcome some challenges:
These complexities sometimes lead to incompatibilities, bugs, or performance issues. However, we believe the benefits of WordPress Playground far outweigh the challenges, and we are committed to addressing them by contributing to the Playground project. Thus not only Studio works better, but everyone who uses Playground has a better experience.
In turn, Studio also benefits from contributions from other Playground users.
As part of our contributions to the Studio app, we recently focused on improving the compatibility of plugins, themes, and workflows in sites. The following are some of the fixes we made that contributed to the projects.
With a pull request, we helped improve the compatibility of sites connecting to MySQL databases, making Studio more flexible in handling various site configurations and expanding its capability to support more diverse WordPress setups.
We submitted two contributions (PR 1, PR 2) to add crucial support for handling symlinks in sites, greatly improving file system compatibility and flexibility. This enhancement significantly improves the development workflow, enabling developers to maintain cleaner project structures and more efficiently manage their themes and plugins across multiple projects. It also facilitates easier version control and collaboration by allowing links to external repositories without duplicating files.
A fix resolved critical issues with uploading media on sites when using the Windows version of the Studio app, ensuring a smoother experience for Windows users. This contribution addressed a significant functionality gap, ensuring that Studio provides a consistent and reliable media management experience across all supported operating systems.
Another contribution fixed the process of upgrading versions of WordPress, plugins, and themes. This improvement streamlined the update process within Studio, allowing developers to maintain their WordPress installations and associated extensions easily.
This pull request significantly improved compatibility with the WooCommerce plugin, expanding Studio’s utility for e-commerce development. This contribution addressed specific database queries and operations that were incompatible with the SQLite database used in sites created with Studio. The SQLite integration plugin involves different complexities to allow seamless integration with the WordPress ecosystem, and this contribution addresses one of the main pain points of using WooCommerce in local WordPress environments.
We contributed the ability to enable the cURL extension on PHP used with Playground which turned out to be a requirement by a significant number of plugins for external API calls or remote data fetching. This broadens the range of plugins that can be used effectively within Studio and WordPress Playground.
A fix improved compatibility with plugins that create files using umask to set file permissions, enhancing the file system operations. This was crucial for plugins that generate caches, create custom CSS or JavaScript files, or manage uploads in non-standard ways. By resolving these file operation issues, we ensured that a broader range of plugins could function correctly within Studio, providing a more accurate representation of how sites would behave in a production environment.
All the above examples demonstrate how collaborative contributions help Studio evolve, making it more compatible with the vast array of plugins and themes in the WordPress ecosystem.
If this post has inspired you to contribute to open source projects (we’re big fans), here’s how you can get involved with some of our favorite open source projects:
Together we can build incredible tools for the community! 🙂
If this information has piqued your interest, or if you’re developing WordPress sites, start leveraging the power of Studio today. It’s free, it’s open source, and it seamlessly integrates into your development workflow.
After downloading Studio, connect it to your WordPress.com account (free or paid) to unlock features like Demo Sites.
Join 112.5M other subscribers
WordPress biz Automattic details WP Engine deal demands • The Register
Daily Search Forum Recap: September 30, 2024
Yoast Co-Founder Suggests A WordPress Contributor Board
6 Things You Can Do to Compete With Big Sites
Google Volatility With Gains & Losses, Updated Web Spam Policies, Cache Gone & More Search News
Daily Search Forum Recap: October 1, 2024
An In-Depth Guide For Businesses
This Minimalist Lamp Lets You Pick From 16 Million+ Lighting Colors for Maximum Productivity
![How to Create A Website to Sell Products In 8 Steps [+6 Expert Tips]](https://articles.entireweb.com/wp-content/uploads/2024/10/1727868370_How-to-Create-A-Website-to-Sell-Products-In-8.webp-400x240.webp "How to Create A Website to Sell Products In 8 Steps [+6 Expert Tips]")
![How to Create A Website to Sell Products In 8 Steps [+6 Expert Tips]](https://articles.entireweb.com/wp-content/uploads/2024/10/1727868370_How-to-Create-A-Website-to-Sell-Products-In-8.webp-80x80.webp "How to Create A Website to Sell Products In 8 Steps [+6 Expert Tips]")
