Ezpublish Legacy Utility Bundle Laravel Package

Product Decisions This Supports

• Legacy CMS lifecycle: Whether to keep funding eZ Publish 5.x, freeze it, or accelerate migration to eZ Platform / Ibexa. This package has value only inside that decision — it is not a forward-looking capability.
• Build vs. buy (really: build vs. vendor): The "buy" option here is not procurement, it's fork-and-own. No releases since February 2018, 2 stars, zero dependents, no upstream support. Decide whether owning a small utility is cheaper than writing the equivalent glue code.
• Feature delivery on an existing legacy app: If the utilities it provides (extra legacy eZ 5 helpers) replace hand-rolled code, it can save days on maintenance work — but the savings must be weighed against the cost of carrying an unmaintained, GPL-2.0 dependency.
• Dependency governance: A package with this maintenance/popularity profile should trigger an exception review, not a routine composer require. It is a useful test case for whether the team's dependency policy is real.
• Roadmap signaling: A request to add this in Q3 is a signal that migration is slipping. Ask why the legacy stack is still receiving new investment.

When to Consider This Package

Consider it only when all of the following hold:

• You are actively maintaining an eZ Publish 5.x (Symfony 2-era) application — not eZ Platform/Ibexa, and not Laravel. Despite the "Laravel/PHP" framing, this is a Symfony bundle built for eZ Publish's legacy bridge; it will not install or run in a Laravel app.
• You have read the source and confirmed the specific utilities match a documented need. The description ("extra legacy functionalities") is too vague to justify adoption on reputation alone.
• You can vendor it, pin the version, and accept ownership: no upstream support, no security patching, no PHP 8 modernization.
• Your license posture tolerates GPL-2.0. For a proprietary product this is a compliance blocker unless counsel clears the distribution model.

Look elsewhere when:

• You're on eZ Platform / Ibexa — use the supported native APIs.
• You're on a modern PHP/Laravel stack — nothing here applies.
• You need security patches, vendor SLAs, or long-term maintenance.
• Only a small fraction of the bundle matches your need — write those two or three functions yourself and keep the license clean.

How to Pitch It (Stakeholders)

Executives: This is not a strategic dependency and should not be pitched as one. It is a tiny, frozen helper for an application we are presumably already trying to retire. The decision it informs is migration sequencing, not new capability. Recommend approving it only as a time-boxed, vendored shim tied to a specific legacy milestone — with the audit, pinning, and license review costed in, and an explicit removal date.

Engineering: Treat it as fork-in-place. Audit the source before use, vendor it, pin the commit, add it to the dependency risk register, and document the GPL-2.0 obligation. Build no new features against it and don't hold it up as a pattern for the target platform. If migration is within two quarters, skip the dependency entirely and write the small amount of glue code directly.