I moved this blog away from WordPress for boring reasons. It publishes writing. I wanted Markdown in git, static HTML on Cloudflare, and fewer things to keep alive.
The fight between WordPress and WP Engine gave me a less boring reason not to go back. It also clarified what I think an open-source project is selling after the code becomes easy to fork: trust.
Ten years ago, an established open-source package had real leverage. Replacing it meant learning a large codebase, rebuilding years of edge cases, and convincing an ecosystem to move. A company could charge for hosting and support around that package, and the project could ask commercial users to contribute back. The cost of walking away kept the bargain intact.
That cost has fallen. The code is still difficult to maintain, but it is much cheaper to get a credible fork, compatible replacement, or migration tool off the ground. Agents did not make the hard parts disappear. They made the first year of work less special.
That leaves WordPress in a hard position. I understand why the people who built it want commercial companies to contribute back. But an expectation is not leverage. If the deal stops working for enough of the ecosystem, they can fork the code. The remaining question is whether enough people trust the fork to leave with them.
The part of WordPress that is not in the download
WordPress is GPL-licensed. I can download it, run it, modify it, and publish a fork. That is real freedom. It is not the entire WordPress experience.
Many sites also use the plugin directory, theme directory, update servers, accounts, trademarks, documentation, and the social machinery around WordPress.org. Those are not details. They are part of the ordinary way a WordPress site is installed, extended, and kept current.
Matt Mullenweg co-created WordPress, runs Automattic, and controls WordPress.org. WordPress’s own documentation draws a line between the project and Automattic’s commercial WordPress.com service. The court record in the WP Engine case describes WordPress.org as owned and operated by Matt. That structure helped WordPress get this large. It also put a lot of the project’s practical power in one place.
In September 2024, Matt announced that WP Engine was banned from WordPress.org resources. Automattic said WP Engine needed a trademark agreement and was not contributing enough back. Its public term sheet proposed either a license or a contribution equal to 8% of WP Engine’s revenue in money or employee time. WP Engine disagreed and sued.
A fight over trademarks and contributions reached updates and plugins for people trying to run sites. In a December 2024 preliminary injunction, the court ordered Automattic and Matt to restore WP Engine’s access and stop interfering with related plugins while that litigation was pending. The order did not decide the merits. It did show how much practical power sits outside the code repository.
The commercial ecosystem is not the uncomfortable part. Every successful project has one. The problem is that WordPress can be open in the repository and centralized everywhere a user goes after installing it. That is leverage, but only until the community decides it has become a reason to leave.
Valkey did not appear by accident
Redis changed the license for future releases in March 2024, from BSD to the source-available RSALv2 and SSPLv1 licenses. Redis said it wanted competing hosted services to stop using newer versions for free. Its announcement is refreshingly direct.
The response was Valkey: a Redis-compatible fork under the Linux Foundation, starting from Redis OSS 7.2. Its migration path made it possible for Redis users to move without changing the interface they had built around.
Amazon participates in Valkey. Its technical steering committee includes people from AWS, Google Cloud, Alibaba, Oracle, Percona, Tencent, and Ericsson. Valkey publishes the list. Commercial interests are still there. The project is governed through the Linux Foundation rather than by Redis Ltd. alone.
Redis added an AGPLv3 option with Redis 8 in May 2025, alongside its source-available licenses. The 2024 fork story does not describe today’s only Redis licensing option. Valkey does not prove Redis was wrong. It proves that when enough users dislike a new deal, a fork can become more than a threat. It can become the place the work goes next.
The cost of leaving has fallen
This is the difference from ten years ago. Challenging a mature project no longer starts from zero. Existing APIs, public behavior, test suites, and package ecosystems provide the map. Coding agents help a small group follow it much faster.
GitHub logged 986 million commits in 2025, up 25% year over year, and 43.2 million pull requests merged each month, up from 35 million. More than 1.1 million public repositories imported an LLM SDK, up 178%. GitHub’s Octoverse report shows more software activity and much wider AI adoption. It does not measure how much of that code agents wrote.
Developers merged more than one million pull requests from GitHub’s coding agent in its first five months. People choose the work and review it. The agent does a lot of the implementation.
An agent cannot recreate WordPress in an afternoon. It cannot manufacture plugin compatibility, operating knowledge, or a community that trusts it. It can make the first credible version of an alternative much cheaper. Stable APIs, file formats, and migration paths now matter more than the amount of code behind them.
Complexity Science Hub estimates that AI-assisted code made up 29% of a U.S. sample of GitHub Python work by early 2025. Google says agents write about half of its code, with engineers checking it. Neither figure measures all software. I do not need them to. The direction is enough: implementation is getting cheaper, so forcing an ecosystem to stay is getting harder.
Agent-written code is not automatically MIT-licensed. Maintainers choose the license for what they publish, and generated code still needs security and intellectual-property review. GitHub’s guidance covers both. Permissive licenses such as MIT are attractive to new projects because they remove friction for users, integrations, and forks. That choice makes the exit cheaper too.
What I would protect
Open-source projects should let companies make money around them. Hosting, support, and managed services are not an insult to the project. They are often the reason more people can use it. Using shared services to enforce a tighter deal can push users toward an alternative when one is cheap enough to build.
The thing worth protecting is the community’s ability to say no. Keep governance legible. Keep interfaces portable. Do not use vital shared services to settle a commercial dispute.
That is what I take from WordPress and Valkey. The code is not the moat. Trust is. A project has the most leverage when people stay because they want to, not because leaving is painful. In a world where building the exit is getting cheaper, that is the only leverage that lasts.
Was this useful?
Thanks for the feedback.