Groundwork Bundle Laravel Package

Product Decisions This Supports

• Build-vs-buy triage on foundational scaffolding. A "groundwork" bundle is, by name and convention, the kind of thing teams are tempted to pull in to skip boilerplate (base controllers, service wiring, common abstractions). This package is useful mainly as a reference design — read it, mine the patterns, then write your own 150 lines. It is not a dependency you plan a roadmap around.
• Roadmap de-risking for greenfield Symfony services. If a squad is scoping a new Symfony service and someone proposes this as the foundation layer, this assessment is the artifact that kills or defers that proposal before it eats a sprint.
• License gate for commercial distribution. GPL-3.0 is the single most consequential fact here. For any product shipped as a proprietary or SaaS-with-on-prem component, this is a hard stop until legal signs off. That is a decision, not a discussion.
• Dependency-hygiene prioritization. 2 stars, 0 dependents, last release November 2019 — this is a useful data point when arguing for an internal "approved dependencies" policy or an SBOM/vetting step in the PR template.
• Not a use case: It does not support a feature decision, a pricing decision, or a customer-facing commitment. Nothing here is load-bearing for product strategy. The opportunity score of 6.78 should be read as "unclaimed space in the ecosystem," not "validated demand" — with 0 dependents there is no evidence anyone wants this filled by this package.

When to Consider This Package

Adopt only under a narrow set of conditions:

• You are on Symfony, not Laravel. Despite being filed under PHP packages generally, this is a Symfony bundle; in a Laravel codebase it is inert.
• You need a reading reference, not a runtime dependency — a teammate is studying bundle structure, compiler passes, or DI extension patterns and wants a compact real-world example. Vendor it into a scratch repo, do not require it.
• Your project is already GPL-3.0 and therefore copyleft-compatible, so the license imposes nothing new.
• You accept stewardship risk explicitly: no maintainer activity since 2019, no dependents to surface breakage, no security response path, and PHP/Symfony major versions since then will likely break it outright.

Look elsewhere — or write it yourself — if any of the following hold:

• Proprietary or closed-source distribution. GPL-3.0 is disqualifying without a legal opinion; assume the answer is no.
• You need maintained code. Seven years without a release and zero dependents means you are the only person who will ever hit the bugs you hit.
• You need security responsiveness. No release cadence plus no dependents equals no disclosure channel. Treat the code as unmaintained and unaudited.
• You need modern PHP or Symfony support. Compatibility with current framework versions is unverified and unlikely out of the box.
• The alternative is a first-party skeleton. Symfony's own skeleton and maker tooling cover the same "groundwork" territory with an active security process. The burden of proof sits entirely on the third-party bundle, and it does not meet it.

How to Pitch It (Stakeholders)

For executives (30 seconds): We evaluated a small open-source PHP package as a potential foundation for new services. Recommendation: do not adopt. It has effectively no user base (2 stars, 0 downstream projects), no release in over six years, and carries a GPL-3.0 license that would force us to open-source anything we build on it or require a legal exception. The cost of adopting it exceeds the cost of writing the equivalent scaffolding in-house by a wide margin, and it introduces a licensing risk with no offsetting benefit. No action needed beyond logging it as evaluated-and-rejected.

For engineering: Treat this as a pattern library, not a dependency. If the underlying ideas are useful, spend a day reimplementing the parts we need against our current Symfony version — that gives us code we own, code we can license freely, and code that gets security patches. If someone wants to track it as prior art, put it in the internal reading list, not in composer.json. Add it to the rejected-dependencies log with the reason "unmaintained + copyleft + zero adoption" so we don't relitigate it next quarter.