Rad Bundle Laravel Package

Product Decisions This Supports

• Framework and tooling selection for greenfield PHP work. This package is a data point against adopting an external "rapid application development" layer on top of a framework: the canonical Symfony RAD bundle died alongside its host framework version and was never ported.
• Build vs. buy for developer-productivity tooling. RadBundle is a concrete reference case for the scope a scaffolding layer must cover — console-driven CRUD/controller generation, convention-based service auto-registration, auto-routing, and an opinionated app skeleton. It also shows the maintenance cliff: a productivity layer coupled to one framework major version has a shorter half-life than the framework itself.
• Roadmap input on onboarding velocity and time-to-first-endpoint. The bundle existed to collapse the "empty project to working CRUD screen" gap. If that metric is on the roadmap, this is the historical baseline to beat, not the tool to ship.
• Architecture decision on convention-over-configuration in application code. Auto-wiring services and inferring routes from naming shortens the initial build but raises the debugging and new-hire comprehension cost. That trade-off should be an explicit, recorded decision — this package is the worked example.
• Closing the "fork or vendor it" question. Archived, zero dependents, no release since September 2015, no security patching, no PHP 8 or Symfony 4+ compatibility. That is a settled no, not an open evaluation.
• Vendor-risk precedent. A useful pattern for the risk register: any single-maintainer or framework-tied productivity package gets scored on maintenance signal before it touches a product roadmap.

One correction worth surfacing to stakeholders: this is a Symfony 2 bundle, not a Laravel package. For a Laravel shop there is no integration decision to make — the capability it offered (generators, starter scaffolds, opinionated conventions) is already in-core via Artisan, Breeze/Jetstream, and is purchasable or open-source via Filament, Nova, or Blueprint. The actionable decision is "do we build internal scaffolding, or buy/adopt a maintained equivalent," and this repo is evidence for that decision, not a candidate in it.

When to Consider This Package

• Legacy audit only. You are inventorying a Symfony 2.x / PHP 5.6–7.0 era codebase and need to confirm whether RadBundle is a live dependency and what surface area it touches before a migration or acquisition.
• Architectural research. You are designing an internal RAD or golden-path tooling layer and want a real, readable implementation of convention-based service registration and console CRUD generation to borrow patterns from. Read it as prior art; do not vendor it.
• Not for production, in any scenario. No maintained fork, no security response, no compatibility with modern PHP or Symfony, and no evidence of a user community to inherit fixes from.

Look elsewhere when any of the following is true — which is effectively always for new work:

• You need PHP 7.4+ or 8.x, Symfony 4/5/6/7, or any active security support.
• You are on Laravel: use Artisan generators, Blueprint for spec-driven scaffolding, and Filament or Nova for admin CRUD. No third-party bundle required.
• You are on modern Symfony: MakerBundle is the direct successor and is maintained.
• You need an SLA, a named maintainer, or anything that will survive the next framework upgrade.

How to Pitch It (Stakeholders)

To executives: "This is an abandoned 2015 Symfony 2 tool with no dependents and no updates in a decade. We are not adopting it, buying it, or forking it. We are reading it as a case study for a developer-productivity initiative, because it demonstrates both the upside — scaffolding removes boilerplate between an empty repo and a working CRUD screen — and the failure mode: productivity layers die when they are welded to a single framework version. It is a two-hour read, not a line item."

To engineering: "Wrong framework, wrong PHP generation, zero maintenance — treat it as prior art rather than a dependency. What it did was auto-register services by convention and generate controllers and CRUD from the console. That is the same shape as the internal scaffolding most teams eventually build. Before we build it, we owe ourselves a written answer on what Artisan, Blueprint, Filament, or Nova already cover and where the genuine gap is."

Recommendation: Do not adopt, do not fork, do not vendor. Capture the patterns in a one-page design note, benchmark the current maintained equivalents, and make the build-vs-buy call on a one-to-two sprint horizon. Add a standing gate for any future proposal to introduce a framework-tied tooling layer: require a named maintainer, a decoupling plan from the framework's major-version cadence, and an exit path. The high opportunity score here is a signal that the capability is worth investing in — not that this package is worth installing.