What’s There to Learn from WordPress?

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.

Open source has always lived beside paid software. A company can make money from hosting, support, and convenience. The code is still there if the company changes the deal. That possibility matters more than the license text by itself.

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.

Most sites also depend on the plugin directory, theme directory, update servers, accounts, trademarks, documentation, and the social machinery around WordPress.org. Those are not details. They are how a normal WordPress site stays 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. The court ordered Automattic and Matt to restore WP Engine’s access and stop interfering with related plugins. That preliminary injunction showed where the leverage was.

The uncomfortable part is not that WordPress has a commercial ecosystem. Every successful project does. It is that a project can be open in the repository and centralized everywhere a user actually goes after installing it.

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 gave AWS, Google, Alibaba, and others something they could support without asking users to relearn the interface.

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 power is simply harder to concentrate in one company.

Redis is still here. 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.

Agents change the cost of leaving

The old argument for control was partly practical: rebuilding software was expensive. It still is for a large, mature product. But the price is moving.

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 the shape of the new environment: more code, moving faster, with less human labor behind every revision.

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 are suddenly more valuable than the amount of code behind them.

Call it somewhere between a third and half of new code for teams moving fastest. Complexity Science Hub puts AI-assisted code at 29% of a U.S. sample of GitHub Python work by early 2025. Google says agents write about half of its code, checked by engineers. The exact share moves by company and language. The direction does not.

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.

The thing worth protecting is the community’s ability to say no. Keep governance legible. Keep interfaces portable. Do not turn the service layer into a punishment for people who took the project seriously enough to build on it.

That is what I take from WordPress. The code is not the moat. Trust is. And trust gets thinner every time leaving looks harder than staying.