One of the names on the original announcement

The Moment His Name Entered the Record

In August 2005, a group of Mambo's core developers published a public letter explaining why they were leaving. The grievance was structural: a plan to hand the project's trademark and assets to a newly created Mambo Foundation controlled by Miro International, the Australian company that had commercially backed Mambo, rather than to an independent body governed by the community that had built it. Andrew Eddie was among the signatories. That act of signing was not merely symbolic — it meant he was prepared to walk away from the codebase he had worked on and start over, under a different name, with no guarantee the community would follow.

The community did follow. Soon after, Open Source Matters was set up to hold the new project's assets and trademark, and the fork was publicly announced under the name Joomla — drawn from the Swahili jumla, meaning all together, chosen by the core team after inviting community suggestions, to signal that the governance model was itself the point. Eddie's name appears in the initial announcement as one of the founding developers, and his subsequent contributions span far enough across the project's history that he functions as a useful lens on how Joomla's internal decisions actually worked over time.

Architecture as Governance

The technical decisions Eddie is documented to have driven are not separable from governance questions. In the period between the 2005 fork and the release of Joomla 1.5 in January 2008, the project faced a foundational choice: patch the inherited Mambo architecture, which was largely procedural and had grown without a coherent design philosophy, or rewrite the core around a model-view-controller pattern. The MVC approach won, and 1.5 shipped with it as the structural basis for how extensions were expected to be written.

Why does that matter as a governance question? Because an architectural standard is also a contribution policy. Once the core adopted MVC, extension developers who wanted to integrate cleanly with Joomla had a documented interface to work against. The alternative — continuing with the ad-hoc structure inherited from Mambo — would have made every extension author's relationship to the core a matter of personal judgment and version-specific hacks. The choice to impose a coherent architecture was a choice about who the platform was for and what it would ask of people building on it. That kind of decision has a longer half-life than a single release.

Eddie's role in the 1.5 development cycle is documented in the project's own changelogs and in the public record of what Joomla became after that release. The platform shifted — credibly, not just in its own community's estimation but in the wider CMS market — from a fork-of-something into a project with its own technical identity. Joomla 1.5 is the release that made that shift legible.

Staying Through the Difficult Transitions

A fork's founding moment is, in some ways, its easiest. The enemy is clear, the community is energized, and everybody agrees on the immediate task. What tests governance is what comes after: the years when the project has to make decisions that disappoint some of its own contributors, when version upgrades break extension compatibility, and when the GPL licensing questions that seemed abstract in 2005 become actual disputes with commercial vendors.

Eddie's documented involvement runs through these later periods. The GPL debate — whether a Joomla extension constituted a derivative work of the GPL-licensed core and therefore had to be distributed under GPL — produced genuine conflict in the extension community. Commercial developers who sold extensions had real money on the table. The project sought an opinion from the Software Freedom Law Center ↗, published that opinion openly, and then had to hold the position when vendors pushed back. Eddie's public record in this period is consistent with the project's formal stance, which is the most that can be honestly said about any contributor whose involvement is documented through public channels rather than private correspondence.

The version transition problem is a different kind of governance test. The migrations from 1.5 through 2.5 and then from 3.x to 4.x each required extension authors to rewrite significant code, and each time a portion of the extension ecosystem simply did not make the crossing. The project knew this would happen and did it anyway, because the alternative — maintaining backward compatibility indefinitely — would have locked the platform into architectural choices made in 2005 or 2007. That is a documented trade-off, not a mistake, and it required leadership to articulate and defend over a period of years.

The technical decisions Eddie is documented to have driven are not separable from governance questions.

What the Record Shows About Longevity

Open-source projects have a well-documented attrition problem. According to research on open-source contributor behaviour ↗, the drop-off between a project's founding cohort and its five-year active contributor list is steep; the ten-year list is steeper still. The people who sign founding letters are not typically the people still filing commits a decade later, because founding-level involvement is expensive and life intervenes.

Eddie's documented work spans well past the founding period and into the 4.x era, which makes him unusual in the project's contributor history — not unique, but uncommon. Louis Landry, another signatory to the original letter and an architect of 1.5, is another figure in this category. Brian Teeman's documented work runs long in a different register: Teeman concentrated on communication, documentation, and public explanation of the project rather than on code. That these contributors stayed, worked in different modes, and disagreed with each other on record at various points is itself evidence that Open Source Matters functioned as something more than a holding company for a single founding faction's preferences.

The governance structure that emerged from the 2005 walkout was designed to prevent any single entity — including Miro International, but also including any future company or clique — from controlling what the project built and how it was licensed. Andrew Eddie's documented career inside that structure, from the founding letter through multiple major releases and through the disputes about licensing and compatibility that defined the project's middle years, is a record of what that prevention looks like in practice. It is not a heroic narrative; it is a working record. The distinction matters, because the former kind of story is what projects tell about their founders, and the latter is what the public record actually shows.