Persistent Object Laravel Package

Product Decisions This Supports

• Build vs. buy vs. reuse — already answered. A Laravel application already ships Eloquent, a maintained Active Record ORM with migrations, relationships, eager loading, and a large hiring pool. Adopting a second persistence abstraction is not a feature decision; it is a tax on every future schema change. This package's value to a PM is chiefly as evidence against a proposed adoption.
• Legacy estate triage. The realistic use case is inherited code: applications built on eZ Publish / Apache Zeta Components where PersistentObject subclasses and declarative object definitions are already load-bearing. Here the package supports a roadmap decision — contain, freeze, and extract versus rewrite — and informs sequencing of a migration off PHP 5-era persistence.
• Technical-debt scoring. With 4 stars, 0 dependents, and no active maintenance signal, this is a clean, defensible "known liability" line item. It gives you a concrete artifact to point at when justifying modernization budget, without needing a lengthy audit.
• Architecture reference, not dependency. The declarative object-definition pattern (table, columns, types, relations expressed as configuration) is a useful teaching artifact for teams designing repository interfaces or a schema-driven data layer. That is a design-review input, not a composer require.
• Vendor/licensing gate. The license is reported as NOASSERTION, meaning automated detection could not confirm terms. For a PM, that alone blocks inclusion in anything distributed or commercially sensitive until legal clears it — treat as a decision checkpoint, not a footnote.

When to Consider This Package

Consider it only when:

• You are already running it — an inherited eZ Publish or Zeta Components application where the persistence layer is woven through domain code. Even then, the decision is "how do we exit," not "should we adopt."
• You need to port behavior faithfully before re-platforming: reading the object-definition semantics to reproduce validation, relation-loading, and identity-map behavior in Eloquent or Doctrine during a strangler-fig migration.
• You want a historical/architectural reference for how a simple data mapper declares schema in PHP, for a design spike — read-only, not vendored.

Look elsewhere when:

• You are building anything new on Laravel. Use Eloquent; use Doctrine DBAL/ORM if you need a data-mapper rather than Active Record.
• You need PHP 8.x compatibility, typed properties, static analysis cleanliness, or security patching. There is no maintenance signal to suggest any of this is coming.
• You need community support, documentation, or a hiring pool — the near-zero adoption numbers mean the only expertise available is whoever wrote it.
• Licensing must be unambiguous. NOASSERTION is a hard stop until cleared; do not let it into a distributed product on the assumption it is permissive.

How to Pitch It (Stakeholders)

To executives: This is a discontinued persistence library with effectively no users left — a handful of stars, nothing depending on it. It is not a candidate for investment. If it appears in our codebase, it is a migration risk with a bounded blast radius, and the right ask is a scoped extraction budget, not an integration one. There is also an unresolved licensing flag that legal should clear before we ship anything containing it.

To engineering: Do not add this to a Laravel service — Eloquent covers the same ground with active maintenance, tooling, and hiring. If it is already present, contain it: put it behind a repository interface, pin the version, add characterization tests around the existing persistence behavior, and plan replacement incrementally. The declarative object-definition approach is worth skimming as a reference for our own schema conventions, but nothing more.