Encoded code sold badly and aged worse

The Logic of Encoding

When the Joomla extension economy began to grow in earnest after 2008, commercial developers faced a genuine dilemma. The project's position — eventually confirmed through the Software Freedom Law Center's published opinion ↗ — was that extensions distributed with Joomla are derivative works and therefore fall under the GPL. But the GPL requires source to be available. For a vendor who wanted to sell a plugin without giving away its logic, that left a narrow technical path: ship the PHP files not as source but as encoded bytecode, using tools such as ionCube Loader or Zend Guard. The code ran, the loader translated it at runtime, and the buyer received something that worked but could not be read, modified, or legally redistributed in any meaningful sense.

The argument was roughly that an encoded file is not source code, so the GPL's source-availability requirement had nothing to bite on. It was a contested position, and the Joomla project never endorsed it, but the marketplace accommodated the practice because enforcement was difficult and demand was real. Developers building booking systems, advanced access-control layers, or payment integrations pointed to their encoded products as proof of serious engineering. The price premium over free alternatives was supposed to justify the opacity.

When PHP Moved

The fragility was architectural. ionCube and Zend Guard encode against a specific PHP version. When PHP 5.6 reached end of life, then PHP 7.0, then successive 7.x releases, encoded extensions tied to older ABI versions simply ceased to execute. A site running an encoded component from 2012 on a host that had upgraded to PHP 7.2 would throw a fatal loader error on every page load. The vendor's options were limited: re-encode against the new version and issue an update, or let the product die.

Many let it die. The economics had shifted — subscriptions had lapsed, the developer had moved on, the company had dissolved — and the encoded binary sitting in a site's components folder could not be patched by anyone except the original author. An open-source extension with a bug in it can be fixed by any competent developer given access to the repository. An encoded extension with a bug, or an incompatibility with a new PHP release, is simply broken until the original vendor acts. PHP's release schedule and end-of-life policy ↗ is public and has always been public; vendors who built on encoding were accepting a recurring deadline they did not control.

The pattern repeated with every major PHP transition. Sites that had accumulated encoded components across several years arrived at upgrade windows carrying a list of components that no longer worked and no longer had anyone to call. Hosting providers who moved infrastructure to PHP 8.x found themselves fielding support requests for products they had never sold.

The Maintenance Reality

There is a version of this story in which encoding was simply a miscalculation about longevity. The deeper problem is what encoding did to the relationship between a site and its own functionality. Standard Joomla architecture lets a developer examine a component, trace a data flow, and understand what a piece of code is doing — the MVC pattern the framework adopted made this at least tractable. Encoding removed that entirely. Security researchers could not audit encoded extensions; site owners could not verify what data was being sent where; nobody outside the original vendor could apply even a trivial fix.

The argument was roughly that an encoded file is not source code, so the GPL's source-availability requirement had nothing to bite on.

The Joomla Security Strike Team could document a CVE against an encoded extension, assign it a severity, and publish an advisory, but they could not issue a patch. The installed base would remain vulnerable until the vendor acted, and because many encoded products had limited commercial lives, the vendor sometimes no longer existed to act. The practical outcome was that encoded extensions accumulated in abandoned installations — precisely the category that produces the most persistent security exposure across the Joomla install base.

Encoding was marketed as a protection for intellectual property. In practice it transferred the maintenance risk entirely to the buyer, and that buyer had no tools to manage it.