WordPress, Drupal and Joomla answered the same questions differently

The Same Starting Conditions, Three Different Answers

In the early 2000s, three content management systems arrived on a broadly similar technical substrate: PHP, MySQL, Apache, and the emerging consensus that websites should be editable by people who could not write code. WordPress ↗ grew from a fork of b2/cafelog in 2003, with Matt Mullenweg as its most visible architect. Drupal had been online since 2001, when Dries Buytaert released what had started as a university dormitory message board. Joomla emerged later and more violently, in August 2005, when a development team walked out of the Mambo project in a dispute over trademark control and the governance structure of a proposed new foundation.

The technical starting points were close enough that a 2006 developer could evaluate all three without switching mental models. What differed from the outset was who held the assets, who could make binding decisions, and what obligations the project acknowledged to the people building on top of it. Those structural choices — some made deliberately, some made by accident or under time pressure — compounded across the following two decades into genuinely different ecosystems.

Who Holds the Key

The 2005 Joomla walkout produced Open Source Matters, a non-profit incorporated in New York specifically to hold the trademark and financial assets the departing team had concluded could not safely sit with Miro International, Mambo's commercial backer. The Software Freedom Law Center provided counsel on the GPL implications of the fork. The structure was adversarial in origin: it was built to solve a specific problem about who could legally bind the project.

WordPress solved the same problem differently, by not fully separating the commercial and non-commercial layers at all. Mullenweg founded Automattic in 2005 to operate WordPress.com as a commercial service, while the WordPress software itself remained a community project with the WordPress Foundation holding the trademark from 2010. In practice, Automattic's payroll has long covered a substantial share of WordPress core committers, and the company's interests have shaped the project's roadmap in ways that are visible in the public record — most acutely in the 2024 dispute with WP Engine, which drew attention to the degree to which one company's commercial interests and the project's governance were intertwined. Whether that concentration is efficient or dangerous depends on what you think governance is for. It accelerated certain decisions and left others without a genuinely independent referee.

Drupal's answer was different again. The Drupal Association, a non-profit founded in 2006, holds the infrastructure and community assets, while Buytaert retains a formal "benevolent dictator" role over core technical direction — a title the project has been explicit about rather than embarrassed by. Acquia, which Buytaert co-founded in 2008, built a commercial enterprise services business around Drupal without claiming governance authority over the project itself. The separation is structural rather than merely declared: Acquia's business depends on Drupal's health, but the company does not control the licence, the trademark, or the release process. This produced a cleaner line between commercial use and community governance than WordPress achieved, at the cost of a slower and more committee-driven decision process.

Extension Economies and the GPL Question

All three projects created extension ecosystems, and all three eventually had to answer the same question: if someone builds a plugin or module on top of GPL-licensed core code, does that extension have to be GPL too? The answer determines whether a commercial layer can exist and on what terms.

The Joomla project's position ↗, developed with reference to the Software Freedom Law Center's published opinion, was that extensions are derivative works and must be GPL. The consequences for the extension directory were significant: vendors who had been selling proprietary extensions under encoded wrappers — using tools like ionCube or Zend Guard — were eventually required to comply or delist. The policy was adopted explicitly and is on the public record.

WordPress reached a formally similar conclusion: plugins and themes distributed through WordPress.org must be GPL or a compatible licence. But the enforcement surface is narrower, because WordPress's directory is not the only distribution channel, and because the commercial ecosystem around WordPress — including premium theme shops and plugin vendors operating entirely outside WordPress.org — is large enough that a directory listing policy does not fully govern the market. Automattic's own commercial products, including some sold through its WooCommerce subsidiary, operate under split licences that satisfy the letter of GPL compliance while preserving proprietary elements. The WordPress Foundation's trademark policy adds another layer, drawing distinctions between permissible and impermissible commercial use of the WordPress name that have been contested in court.

The technical starting points were close enough that a 2006 developer could evaluate all three without switching mental models.

Drupal's GPL enforcement has been quieter, partly because the Drupal ecosystem skews toward enterprise clients with in-house legal review and partly because the module ecosystem on Drupal.org has historically operated on a contributed, not commercial, model. Enterprise revenue in the Drupal world flows through service contracts — Acquia's hosting and support business, agencies billing for implementation — rather than through extension sales. This made the GPL question less economically charged, because the commercial layer sat upstream of the code itself.

Security as Governance

How a project handles disclosed vulnerabilities is one of the clearest windows into whether its governance is functional. All three projects operate security teams with published processes, but the transparency and speed of disclosure have varied.

Joomla's Security Strike Team publishes CVEs with documented timelines, and the project's history includes enough high-profile incidents — including the December 2015 remote code execution vulnerability that affected a very large installed base — to have tested the process under real conditions. The formal structure exists and the public record shows it being used.

This made the GPL question less economically charged, because the commercial layer sat upstream of the code itself.

Drupal's security team has a reputation within the open-source community for rigorous process: coordinated disclosure, clearly scoped advisories, and a security advisory system ↗ that has been running long enough to have accumulated a trackable history. The enterprise client base creates strong incentives to maintain that reputation, because a mishandled CVE in a Drupal-based government or financial services deployment carries consequences that a volunteer team cannot easily absorb.

WordPress's security surface is complicated by scale. W3Techs ↗ has tracked WordPress's CMS market share as consistently above 40 percent, which means the raw number of vulnerable installations after any given disclosure is enormous. The WordPress Security Team operates with some Automattic involvement, and the project introduced automatic background updates for minor releases to reduce the window between disclosure and patch deployment. The same scale that makes a WordPress vulnerability newsworthy also makes the update infrastructure worth investing in.

What the Experiment Shows

The three projects did not diverge because of technical choices — the LAMP stack, the GPL, the extension model, the template system all appear in all three. They diverged because the people making governance decisions in 2003, 2005, and 2006 made different choices about where authority would sit, who would hold the trademark, and how commercial interests would be acknowledged or insulated. Andrew Eddie and Brian Teeman, among others on the Joomla founding team, built a structure that explicitly separated the project's assets from commercial control, because the walkout from Mambo had been precisely about that problem. Buytaert built a parallel but structurally distinct separation at Drupal. Mullenweg built something more integrated, which was faster and arguably more commercially successful, and which has periodically surfaced the tensions that the other two structures were designed to prevent.

That is what a natural experiment looks like in open-source governance: not a controlled trial, but twenty years of compounding consequences from decisions that were made on the record, by people whose names are known.