Is WordPress Really Open Source? What That Means for Developers and Agencies

As developers and agency owners who have built entire practices on WordPress, the question of what “open source” actually means has never been abstract. I’ve been building on this platform since 2009, client sites, plugins, themes, agency infrastructure, and in that time the GPL has shaped every commercial decision I’ve made, sometimes visibly and sometimes invisibly. The 2024 governance dispute that played out publicly in the WordPress community forced a conversation many of us had been quietly avoiding: what does “open source” actually protect, what does it expose, and what does the long-term health of WordPress mean for developers and agencies whose livelihoods depend on it? This is my developer and agency perspective on all of that, the freedoms, the complications, and why we should be deeply invested in this ecosystem staying strong.

---

What Open Source Actually Means (Not the Wikipedia Version)

The technical definition is straightforward: open source software gives you access to the source code and the right to use, modify, and distribute it under the terms of the license. For WordPress, that license is the GPL (GNU General Public License), version 2 or later.

But the business and development implications are more nuanced than “the code is free.”

Freedom to Use

WordPress is free to download, install, and run for any purpose, personal, commercial, non-profit, whatever. There’s no license fee. There’s no per-seat cost. There’s no audit where someone checks whether you’re using it in a way they approve of. You can run one WordPress site or ten thousand.

For agency work and plugin development, this means we can start building client sites and products without upfront platform licensing costs. Every dollar goes to development time, not software licenses. That is a genuine, concrete financial advantage of open source that compounds over years of building a practice on this platform.

Freedom to Modify

You can modify WordPress core, themes, and plugins. You can fork them. You can build on top of them. If something doesn’t work the way a project needs, you can change it. This is the freedom that enables the entire plugin and theme ecosystem, thousands of developers extending and building on core WordPress code. For developers, this is the most valuable freedom in practice: WordPress is actually debuggable, all the way down.

Freedom to Distribute (With GPL Obligations)

Here’s where it gets more complicated. If you distribute GPL-licensed code, sell a plugin, release a theme, give code to a client, you must distribute it under the GPL. The recipient gets the same freedoms you got. They can modify it. They can redistribute it. They can give it away for free.

This is the GPL’s “viral” or “copyleft” provision. It’s what makes GPL different from, say, the MIT license. And it’s what trips up agencies and developers new to the WordPress ecosystem.

---

What the GPL Means for Your WordPress Work

The practical implications depend on which part of the WordPress ecosystem you operate in.

If You Build Client Sites

Delivering a WordPress site to a client is a software distribution. Under the GPL, you must provide the client with access to the source code and their GPL rights, the right to modify and redistribute it. In practice this almost never becomes an issue, because clients who commission custom WordPress sites are rarely interested in the source code for redistribution purposes. But legally, it’s what the license requires.

What this means practically for agencies: don’t put code in client deliverables that you’d be uncomfortable having them share. Don’t use purchased premium plugins in ways that violate their specific license terms. And understand that the custom plugin you build for a client is theirs to do with as they choose, including giving it away or having someone else modify it.

If You Sell WordPress Plugins or Themes

WordPress plugins and themes that touch WordPress’s code are GPL-licensed. The WordPress.org required GPL policy for the plugin and theme directories enforces this. But “GPL” doesn’t mean “free of charge.” The GPL allows you to charge for the software. It just means that once someone buys your plugin, they can legally redistribute it at any price, including zero.

This is why most commercial WordPress plugins and themes are sold as services, not software. You’re not really selling the code, you’re selling the updates, the support, the documentation, and the relationship. The code itself is freely copyable. The ongoing value, the support experience, the update stream, that’s what you’re actually monetizing.

GPL-nulled sites that distribute pirated premium plugins exist and are technically operating within the letter of the GPL, even if they’re violating the spirit of fair dealing. This is a real challenge for plugin businesses. The response has to be competing on service quality, not trying to lock down the code.

If You Host WordPress for Clients

Running WordPress for clients is not distribution in the GPL sense, you’re providing a service, not handing someone code. The GPL’s distribution requirements don’t apply to SaaS-style hosting. This is a deliberate feature of the GPL’s design and is sometimes called the “SaaS loophole.” For agencies managing many client sites, running your own stack on a VPS gives you more control and predictability than dependence on any single managed hosting platform.

---

The 2024 Governance Dispute: What Developers Need to Understand

In late 2024, Automattic (the company that employs a significant portion of WordPress core contributors) and WP Engine (a large managed WordPress hosting company) had a very public falling out. For developers and agencies watching from the sidelines, it surfaced governance questions that many of us had quietly avoided thinking through.

The Core Dispute

Automattic’s leadership publicly accused WP Engine of extracting more from the WordPress ecosystem than they contribute back. WP Engine is a multi-hundred-million-dollar business built almost entirely on top of WordPress. The argument: a company of that scale should be contributing more to WordPress core, more engineers, more resources, more investment in the open source project they depend on.

WP Engine’s counter was that they do contribute, through support, documentation, hiring people with WordPress expertise, sponsorships, and that their WordPress.org access was being used as leverage in what was essentially a commercial dispute between two competing business interests.

The WordPress.org Access Move

What escalated this into a genuine crisis was when WP Engine was temporarily blocked from accessing WordPress.org infrastructure, plugin updates, theme downloads, the whole ecosystem. This affected WP Engine’s customers, who suddenly couldn’t update plugins through the normal channel.

This revealed something important that many developers hadn’t fully considered: WordPress.org is not “the WordPress project” in a neutral sense. WordPress.org is infrastructure controlled by Automattic. The open source code and the infrastructure that distributes it are not the same thing, and they have different ownership and governance.

What It Means for Agencies and Developers

For those of us building on WordPress professionally, the practical takeaways are clear:

• Reliance on WordPress.org for plugin updates is a dependency on infrastructure you don’t control, worth diversifying for agencies managing many client sites
• The governance model of WordPress concentrates significant authority in one entity, which creates both stability and real risk
• Diversifying plugin sources (direct downloads, GitHub, alternative update servers) is reasonable operational practice, not paranoia
• The WordPress Foundation is theoretically a neutral steward of the WordPress trademark, but the lines between the Foundation, Automattic, and WordPress.org governance are genuinely blurry and worth understanding

None of this changes the core value proposition of building on WordPress. But understanding the governance landscape is part of being a professional who recommends and builds on this platform.

---

The Four Freedoms and Where They Break Down

The Free Software Foundation defines software freedom through four freedoms (numbered 0–3). It’s worth examining where these work in practice for WordPress professionals and where complications appear.

Freedom 0: Use for Any Purpose

This works cleanly. WordPress has no usage restrictions. You can build any kind of site for any kind of client. The trademark guidelines may have something to say about how you name your product, but usage itself is unrestricted, which is why WordPress works for everything from corporate intranets to e-commerce to membership platforms.

Freedom 1: Study and Modify

Also works cleanly. The code is available, it’s readable, and you can modify it however a project requires. For developers, this is the freedom that makes WordPress genuinely debuggable, you can trace any problem to its source, which is something you simply cannot do on proprietary platforms.

Freedom 2: Redistribute Copies

Works, with the GPL’s copyleft requirements attached. This is where business models get complicated. Redistribution requires carrying the GPL forward, which limits some proprietary approaches. Most WordPress businesses have adapted their models accordingly, service-based monetization rather than code lockdown.

Freedom 3: Distribute Modified Versions

Works, but requires maintaining GPL on the modified version. This is actually what enables most of the WordPress plugin ecosystem, developers can sell modified versions of GPL code as long as the GPL terms are preserved. Understanding this freedom is what makes GPL-based product businesses viable.

---

Why WordPress Staying Strong Matters to Us Specifically

After 15+ years of building on this platform, my view is clear: the health of WordPress is not separate from the health of our businesses, it is our businesses. This is something developers and agencies understand more viscerally than most users do.

The open source nature of WordPress means we never negotiate a license with a vendor who can hold our clients hostage. We can always hire someone else to maintain code. We can always fork if the project goes in a direction that hurts the sites we maintain. The existential vendor risk that affects businesses built on proprietary platforms simply doesn’t apply when the code is GPL.

The large installed base, WordPress powers 40%+ of the web, creates a talent pool, a plugin ecosystem, and a knowledge base that no proprietary platform can match. When we need to solve a WordPress problem for a client, thousands of developers have already solved it and documented the solution.

And here’s what matters most from a developer and agency perspective: every site we build on WordPress, every plugin we sell, every agency retainer we maintain, all of it depends on WordPress remaining a platform that clients trust and want to build on. The platform’s reputation is our pipeline. Governance disputes that make headlines in non-technical press don’t stay in the community, they reach clients and slow down sales conversations.

This is why developers and agencies who build on WordPress have the strongest possible interest in the platform staying healthy, well-governed, and trusted. We’re not neutral observers of the WordPress ecosystem. We’re its practitioners, and we’d feel a platform decline faster than anyone else.

---

The Honest Risks

Uncritical open source boosterism isn’t useful to anyone. Here’s what developers and agencies should actually be watching:

• Governance risk, “Open source” doesn’t mean “democratically governed.” WordPress’s governance is concentrated in ways the 2024 controversy made visible. Agencies with entire client bases on WordPress should understand this and plan accordingly.
• Long-term direction uncertainty, The Gutenberg transition was controversial but ultimately beneficial for developers who adapted early. A future major direction change might not be. Platform bet risk is real and worth monitoring.
• Security responsibility, Open source means agencies are responsible for keeping client installations updated and secure. There’s no vendor to call when a site gets hacked. This requires either internal capability or a trusted managed hosting partner, and clear scope agreements with clients about who owns maintenance.
• GPL compliance complexity, If you’re building commercial products on WordPress, getting WordPress coding standards and GPL compliance right requires either legal counsel or a very clear understanding of what the license requires. Most small teams get this wrong in one direction or the other.

---

What This Means for WordPress Professionals

My recommendation, developer to developer: stay invested in this ecosystem, not just commercially, but as active participants. The governance problems exposed in 2024 don’t get fixed by developers and agencies disengaging. They get fixed by more people contributing, more voices in the community, more economic activity that validates the platform’s importance to the organizations that steward it.

The GPL gives us real, legally enforceable freedoms. Use them, and understand them well enough to explain them to clients when questions come up. Don’t assume that “standard practice” in the ecosystem matches what the GPL actually requires.

Build client infrastructure in ways that don’t create a single dependency on any entity, including WordPress.org, that you don’t control. Maintain direct plugin vendor relationships. Keep local copies of critical plugins. These are operational basics for serious agencies, not edge-case concerns.

Stay close to where the platform is going. WordPress’s Full Site Editing, block themes, the Interactivity API, these are significant platform shifts, not optional features. Agencies that track these early have a head start on the next wave of client work. The developers who understand WordPress deeply are the ones whose businesses survive and grow through platform transitions.

WordPress staying strong isn’t a passive wish for developers and agencies. It’s something we actively contribute to every time we build well on the platform, advocate for it honestly to clients, and participate in the community that sustains it. If WordPress thrives, we thrive with it.