Anyone who builds a website on WordPress is, indirectly, relying on an unusual arrangement. The software is open source and free, yet a commercial company and its founder have been closely tied to its direction. When leadership questions arise at a company like Automattic, people search for names and headlines, but the more useful question is structural, and it is about open source governance: how should we think about projects where a business, a nonprofit and thousands of volunteers all have a stake? That’s what this article covers, using general principles rather than any specific dispute.
Open source is not the same as community-run
The word “open” in open-source software refers to the license. A license such as the GPL lets anyone use, modify and share the code. It says nothing about who gets to decide what goes into the official version, who owns the name, or who pays the developers.
Those decisions are open source governance, and projects handle them in very different ways:
- Foundation-led: a neutral nonprofit holds trademarks and assets, with elected or appointed boards.
- Company-led: one firm employs most maintainers and sets the roadmap, and may offer a hosted product.
- Benevolent dictator model: a founder has the final word, often for a long period.
- Committee or consensus: a group of maintainers decides, sometimes with formal voting.
Most real projects blend these open source governance models, and the hybrid can work well until pressure shows up.
The pressure points in open source governance
Disputes over open source governance tend to cluster around the same few areas.
Trademark. Code can be forked, but a name and logo are protected differently. Whoever controls the trademark controls how the brand can be used, including by hosting companies and agencies who rely on it.
Money matters in open source governance. Who funds development? If a single company pays most of the maintainers, its interests will shape priorities. If it reduces funding, work can stall.
Commercial conflict. A company that sells hosting built on the project competes with others who also host it. Decisions about features, defaults or access to shared infrastructure can look neutral or self-serving depending on where you stand.
Infrastructure. Plugin directories, update servers and package registries are the projects’ central nervous system. Control of them is real power, even if the code is free.
Leadership and accountability. When a founder is also a company executive, board decisions at the company and decisions in the project can blur. Observers then ask who is speaking for whom.
Why users and businesses should care about open source governance
If you run a site, a store or an agency on top of an open project, your risk isn’t that the code disappears. It’s that something around the code changes: update access, plugin rules, branding terms, a shift in license or pricing of the commercial services you depend on.
A practical way to assess that risk is to look at a project the way a cautious engineer would. The same caution applies to the terms in our piece on AI API access terms and vendor risk:
- Who holds the trademark and the domains?
- How many companies employ core contributors? A wide spread is healthier than reliance on one.
- Is there a written governance document, and does it describe how disagreements are resolved?
- Can the update and distribution infrastructure be mirrored or replaced if needed?
- Is there a track record of handling disputes calmly and in public?
What healthy open source governance looks like
Strong projects tend to share a few habits of open source governance. They publish decisions and the reasons for them. They separate the roles of company executive and project steward where possible, or at least declare conflicts openly. They diversify funding, with multiple sponsors and, ideally, a foundation to hold shared assets. And they treat contributors as people to retain, not resources to extract from.
Even sound open source governance does not make conflict vanish. Humans disagree. The goal is for disagreements to be survivable, which depends on predictable rules rather than the temperament of one person.
Who actually does the work
Behind any big project is a mix of people: paid staff, volunteers, occasional contributors and the maintainers who review everything. Our overview of the types of developers and tech gatekeeping is a good reminder that these roles carry very different levels of power and recognition.
Good open source governance makes the path from newcomer to maintainer visible, so influence is earned in the open rather than handed out privately.
A note on reading headlines
News about leadership changes, leaves of absence or board decisions at a company tends to arrive in fragments, often through leaks, posts and partial statements. It is easy to over-read them. Before concluding anything about the future of a project, separate what the company’s board decided from what the project’s community does. They overlap, but they are not the same body.
It also helps to remember that code is resilient. Open licenses exist partly to protect users from a single point of failure. If a community loses trust in stewardship, forks can and do happen, though they are costly and rarely succeed without major backing.
The takeaway
When you pick an open source project for your business, treat open source governance as a feature, as important as performance or plugin quality. Read the governance page, count the sponsors, and decide how you would respond if one party stepped back. That small homework is cheap insurance, and it will make you a calmer reader of the next dramatic headline.
