Fork

The core team left in August 2005 and took the work with them

A governance dispute over who would hold the trademark ended with the lead developers walking out, forking the codebase, and founding a new project inside a week.

August 2005, and what a fork actually takesPiece 1 of 4 in this section

An empty office chair at a desk with a dark monitor

The open letter of 17 August 2005 was published, not leaked; the developers argued about structure rather than people, which is why the community could follow them.

The dispute that broke Mambo

Mambo was, in the summer of 2005, one of the more successful open-source content management systems in existence. Built and maintained primarily by a distributed volunteer team, it ran on the ubiquitous LAMP stack and had accumulated a significant extension ecosystem. Its commercial backer was Miro International, an Australian company that had sponsored development while retaining ownership of the Mambo name. For a while, that arrangement held.

The fracture came from a structural decision. Miro announced plans to establish the Mambo Foundation — an entity that would, in their framing, formalise the project's governance. The lead developers read it differently. From the public record of that period: announcements, mailing-list posts and open letters, the core team's objection was specific and structural. The proposed foundation would hold the trademark and the brand, but the governance documents as circulated gave Miro effective control over the board. The developers would contribute the work; a company would control the name. That asymmetry was the line they would not cross.

Chronology

  1. August 17, 2005open letter published; core developers including Andrew Eddie and Louis Landry announce departure from Mambo
  2. August 2005Open Source Matters incorporated; naming vote held; "Joomla" chosen from Swahili jumla
  3. September 2005Joomla 1.0 released (rebranded Mambo 4.5.3); fork publicly operational
  4. 2008Joomla 1.5 released; first full architectural rewrite post-fork

The sequence moved quickly. On 17 August 2005, a group of lead developers that included Andrew Eddie and Louis Landry published an open letter explaining their position and announcing that they were leaving the Mambo project. The letter named the trademark issue directly. It did not attack individuals; it argued about structure. Within days, the departing team had announced that they would continue development under a new name, taking with them the right to do so that the GPL licence — which Mambo was distributed under — had always granted any recipient of the code.

The Joomla project wordmark

The mark the fork had to invent. Under the licence the code was portable; the name was not, so an identity had to be built from nothing in under a month.

What a fork actually requires

The word "fork" is used casually, but what happened in August 2005 illustrates what a real one demands. The GPL ↗ — the GNU General Public License — gives any recipient of covered software the right to copy, modify and redistribute it. That right is unconditional with respect to the code itself. What it does not transfer is anything that is not the code: the name, the logo, the domain, the accumulated brand recognition. Forking the code was legally straightforward. Forking the identity was impossible.

The team therefore needed a name. The choice they landed on was Joomla, drawn from the Swahili word jumla, meaning all together or as a whole — and the naming process was, deliberately, a community vote rather than a founder's decree. That choice of process was itself a governance signal: the new project would demonstrate from its first public act that decisions would be made collectively. Open Source Matters was incorporated as the legal entity to hold what the Mambo Foundation had been designed to hold — the trademark, the assets and the financial infrastructure — but with a structure the developers trusted. The Software Freedom Law Center was consulted as outside counsel on the licence questions surrounding the fork; that consultation was public and on the record, which mattered to a community that had just watched a governance process fail behind closed doors.

There were practical requirements as well. Infrastructure had to be built from scratch: domains registered, servers provisioned, a code repository established and version control migrated. The extension directory, documentation and forums were all new. The founding contributors gave substantial volunteer time in a very compressed period. The first public release of Joomla — version 1.0, essentially a renamed and rebranded Mambo 4.5.3 — appeared in September 2005, less than a month after the walkout.

What the fork settled and what it left open

The 1.0 release answered the immediate question: yes, the team could continue, yes, the software could ship, yes, the community would follow. And by most measures it did. A substantial portion of the Mambo user community migrated to Joomla in the months after the fork; extension developers, hosting providers and documentation writers moved with them. Mambo continued under Miro's stewardship but progressively lost ground, and the development energy that had made it competitive departed with the people who had written it.

What the fork did not settle was the deeper architectural question. Joomla 1.0 was, technically, Mambo with a different name on the tin. The development team knew it. The plan from the beginning was to rewrite enough of the platform to produce something that could be taken seriously on its own terms — that work would eventually produce Joomla 1.5 in 2008, the release that rewrote the core architecture around a proper MVC (model-view-controller) pattern and introduced template overrides as a first-class feature. But between the fork and 1.5 there were three years of carrying inherited technical debt while trying to build a credible governance structure and a functioning extension economy simultaneously.

The fracture came from a structural decision.

The governance question itself produced ongoing tension. Open Source Matters had been created in a hurry to solve an immediate problem, and its early structure reflected that. Who sat on its board, how decisions were made, and how the volunteer development community related to the legal entity holding the trademark were contested for years afterward. The project documented its decisions publicly — release announcements, security advisories, board minutes — in a way that Miro's Mambo Foundation had not, and that transparency was both a commitment and a discipline. Brian Teeman, among the original departing developers, became one of the more visible communicators of how the project worked and why it was structured the way it was, in part because explaining the governance was inseparable from defending the fork's legitimacy.

The 2005 event has since become something of a case study in what open-source governance failure looks like and what a fork actually costs. The code can leave; the name cannot. A new legal entity must exist before assets can be held. A community can follow developers, but it will only do so if it trusts the new structure more than the old one. The speed of the Joomla launch was impressive, but the trademark registration, the foundation structure and the licence opinions had to be assembled under pressure that no project would choose. What the Mambo situation made visible — in public, in real time, with documentation that remains accessible — is that the conditions for a fork are as much legal and organisational as they are technical. Having the right to copy the code is the beginning, not the end.

The core team left in August 2005 with the code, the skills and the community's attention. The trademark ↗ they could not take. Everything else had to be built.