Foundation Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for back-office scaffolding. modera/foundation-bundle is the kind of package that answers "do we buy our admin/CRUD/settings layer or build it?" Its answer, on inspection, is neither buy nor borrow code — but it is still useful evidence for the "build" column, because it documents the primitive set (base admin controllers, module registration, settings, ACL hooks) that any internal admin framework ends up needing. Use it to sharpen the build spec, not to satisfy it.
• Stack and taxonomy correction. The package is a Symfony bundle, not a Laravel package. For a PM this is a gating fact: it should be reclassified in whatever registry or shortlist surfaced it, and it should be removed from Laravel comparison matrices. It also signals that the discovery source feeding your evaluation pipeline is not trustworthy on framework attribution.
• Roadmap risk triage for an inherited or legacy portfolio. With 2 stars, 0 dependents, a last release in June 2016, and an overall score of 0.04, this is an unmaintained artifact. If it appears anywhere in your dependency graph, the decision it forces is containment and exit planning, not adoption. That is a roadmap item with a real cost attached (upgrade blocking, PHP/Symfony version ceilings, security review overhead).
• Dependency policy calibration. Opportunity score 26.03 against zero adoption and a decade of dormancy is a good worked example for setting thresholds: define what "maintained" means in your org (release recency, dependents, security response, maintainer count) and use this package as the failing baseline when you socialize that policy.
• Technical due diligence on vendor/acquisition targets. Modera's bundle represents a class of PHP agency framework bundles from the Symfony 2/3 era. Recognizing it quickly lets you price migration work into diligence rather than discovering it post-close.
• Reference material for admin UX patterns. As a read-only artifact it can inform acceptance criteria for internal tooling — for example, how module registration and settings scoping were modeled — without any production dependency.

When to Consider This Package

Consider it (narrowly) only when:

• You are maintaining an existing Symfony application that already depends on it, and you need to understand behavior before a migration — treat it as archaeology, not as a candidate.
• You need a read-only reference for pre-2017 Symfony bundle conventions (service definitions, DI extension patterns, admin scaffolding) while writing an internal replacement.
• You are running a timeboxed (≤1 day) spike to confirm the above and produce a written "do not adopt" record for the decision log.

Look elsewhere — decisively — when any of the following hold:

• New build. No new project should take a dependency whose last release predates PHP 7.1. There is no realistic path to PHP 8.x, Symfony 5+, PSR-11/PSR-15 alignment, or current security patching without effectively forking.
• Laravel stack. Hard mismatch. Evaluate Laravel-native options (Nova, Filament, Backpack) or your own internal package instead.
• Security, compliance, or regulated scope. Zero dependents and no recent maintenance means no downstream scrutiny, no CVE response, and no one to call. That fails most vendor-risk questionnaires on its own.
• You need support, SLAs, or a maintainer relationship. There is no commercial support surface here.
• Team velocity matters. Onboarding cost is effectively infinite: no current docs, no community answers, no ecosystem examples. Every question becomes source-reading.
• You need a maintained admin/CRUD foundation. The functional category is well served today; the constraint is not features, it is maintenance and security posture.

Decision rule: if the package is already in the codebase → exit plan. If it is not → do not introduce it, and record why.

How to Pitch It (Stakeholders)

For executives — one line: This is an abandoned 2016 Symfony bundle with two GitHub stars and no downstream users; it carries real maintenance and security risk and zero strategic upside, so our recommendation is to not adopt it and to budget an exit if it is already in our code.

For engineering leadership:

• It is a Symfony bundle, not Laravel — the shortlist that surfaced it was mislabeled, and we should fix the source.
• Viability signals are uniformly negative: last release 2016-06-10, 2 stars, 0 dependents, score 0.04, opportunity 26.03. There is no maintainer community to inherit and no patching path to modern PHP.
• Cost of adoption is not license cost — it is the fork. Any real use means we own the code, the upgrades, and the security review indefinitely. That is a build project wearing a dependency's clothing.
• What we get from it: a compact reference for back-office primitives (module registration, admin controllers, settings, ACL hooks) that we can cite when specifying our own internal admin layer. That is the entire extractable value.
• Recommendation: no-go for adoption; timebox any investigation to a single day; if it exists in the estate, open a migration ticket with the stack upgrade as the forcing function.