Who Controls WordPress When the Founder Steps Away?

Key takeaways

• A company board’s decision does not automatically transfer authority over a separate open-source project.
• Open code does not guarantee shared decision-making.
• Forking a project means rebuilding trust and distribution as well as copying code.
• Clear rules for appeals and succession help projects function when a founder steps away.

Your website may run on open-source software, but someone still decides how the project and its supporting services operate. Imagine Automattic’s board asking WordPress co-founder Matt Mullenweg to take a leave of absence—a hypothetical scenario, not a reported event. The practical question is which powers would actually change hands.

A company role is only part of the picture

Automattic and the WordPress project are separate organizations. A founder’s influence across both does not turn them into a single institution.

That distinction matters when considering what a board decision would accomplish. Restricting someone’s duties at a company and changing their authority in an outside project are separate actions.

A replacement could take over the founder’s company responsibilities without inheriting the ability to approve code changes or publish project releases. To understand the effect, you would need to establish who holds each authority, how they acquired it, and which rules allow it to be reassigned.

“Founder takes leave” makes a tidy headline. It leaves the most useful questions unanswered: who can make decisions tomorrow, and what can they decide?

Open code does not come with a vote

An open-source license allows people to use, modify, and redistribute code under its terms. It does not automatically give every contributor an equal say in running the project.

You might be able to submit a patch while a small group decides whether it gets accepted. You might participate in a discussion without having authority over release schedules or operating policies.

Governance is the set of rules behind those decisions: who has authority, where that authority ends, and how someone can challenge its use.

This is a familiar tension in founder-led projects. A community can contribute substantial work while final decisions remain concentrated in a few hands. Broad participation alone does not tell you how power is distributed.

To assess how open a project really is, look beyond access to its source code. Check whether participants have a meaningful way to influence decisions that affect them.

“Just fork it” leaves out the expensive parts

A fork lets people take existing code and develop a separate project. It gives dissatisfied contributors a way to pursue a different direction.

But copying a codebase is only one part of building an alternative people will use.

Consider a plugin distribution service. Setting up servers would be the beginning. Its operators would also need to persuade developers to publish there, respond to security problems, and maintain a service users trust enough to install updates from.

The repository does not include a ready-made reputation.

Those relationships require people, time, and money. Users also face costs when moving to another service, which gives an established operator influence even when the underlying code is freely available.

Forking remains a meaningful option. Its existence simply does not tell you how practical leaving would be.

Good governance plans for disagreement—and absence

Concentrating authority in a founder can make decisions faster. Someone who understands a project’s history may be well placed to settle difficult questions and take responsibility for the outcome.

The harder test comes when people disagree, especially when the company’s interests conflict with what project participants want. Personal trust cannot resolve every competing claim.

Four questions help reveal whether a project has rules that can handle that pressure:

• Are company responsibilities clearly separated from project authority?
• Are the criteria and procedures for major policy changes public?
• Can affected participants appeal a decision?
• Is there a process for handing over responsibilities and access when a key operator becomes unavailable?

These rules also help founders. They reduce the burden of personally settling every dispute and give participants a clear route for raising concerns.

A board could change a founder’s company role while leaving much of their influence over an open-source ecosystem intact. The meaningful change would be in who inherits authority and how others can hold that person accountable. A durable project needs rules that keep working when its most important person steps away.