Product Decisions This Supports
- Build vs. buy vs. borrow for content management. RedKite gives the team a concrete, MIT-licensed reference point for what "block-based, in-page content editing" actually costs to build. That informs the real decision — a maintained CMS (Statamic, Craft, Contentful, Strapi) versus a Laravel-native admin layer (Filament) versus building blocks into our own app — without committing to any of them.
- Dependency governance and the "abandoned OSS" gate. Twenty-five stars, zero dependents, DEPRECATED/READ-ONLY status: this is a clean worked example for our dependency scorecard. It exercises the maintenance, adoption, security-patching, and bus-factor criteria in one review, and it lets us calibrate whether our scoring model (composite 0.435, "opportunity" 9.78) rewards genuine signal or just low competition on dead code.
- Framework-fit triage. The catalogued package is a Symfony bundle, not a Laravel package — no service provider, no adapter, and a Composer graph that cannot resolve alongside Laravel 10/11. That is itself a roadmap input: it forces an explicit target-runtime decision before any CMS work is scoped, and it flags a recurring metadata quality issue in our package intake.
- Legacy modernization scoping. If any inherited application already runs RedKite, this assessment seeds the migration plan (freeze content model → export → replatform → decommission) rather than a feature backlog item.
- Editorial UX requirements capture. The source documents page trees, block/slot composition, multilingual and multi-site content, and in-context editing. That is a usable requirements primer for whatever we build or buy, at zero licensing cost.
- Decommission-date discipline. It models the governance pattern we want for any legacy surface: named owner, contained deployment, explicit end-of-life date treated as a commitment.
When to Consider This Package
Consider it only in narrow, backward-looking situations:
- You already operate a Symfony 2/3-era RedKite instance and need to stabilize, audit, or extract from it. Contain it behind a gateway with a decommission owner and date — acceptable as a migration tactic, never as a steady state.
- You want a reading reference for block-based composition and inline editing UX, and are willing to read source rather than install anything. Vendor nothing; mine the content model (pages, blocks, slots, revisions, localization) and rebuild the pieces you need on Laravel-native primitives.
- You are running an archaeology or porting spike and want to borrow domain ideas, not code.
Look elsewhere by default:
- Any new build. Read-only means no security patches, no PHP 8.x or Symfony 6/7 compatibility work, no upstream to escalate to. The admin/editing surface is the highest-value target in the app and would be permanently unpatched.
- Laravel stacks. Symfony bundles are binary-incompatible with Laravel's service providers; the glue would be ours to own forever, and Composer will refuse the dependency graph outright.
- Zero dependents is the decisive signal: no downstream projects means no de facto integration testing, no community fixes, and no hiring pool that knows the stack.
- Anywhere you need vendor support, an SLA, or a modern editor experience. Take a maintained CMS or a Laravel-native admin layer instead.
- If supply-chain reproducibility matters (it should) — abandoned transitive packages can be yanked from Packagist at any time, so even a frozen build is not guaranteed reproducible.
How to Pitch It (Stakeholders)
Recommendation: do not adopt. Reject cheaply, extract the ideas, and move on.
RedKite CMS is a deprecated, read-only Symfony bundle with 25 GitHub stars, zero dependent packages, and no active maintainer. Its MIT license means we could fork it, but a fork converts a free dependency into an internal product we must staff, patch, and carry through every future PHP and Symfony release — a permanent tax paid for a content-editing capability we can buy or build more cheaply. It is also a Symfony bundle, not a Laravel package, so on our stack the fit is zero before we even reach the maintenance argument.
To engineering: treat it as a design reference for content-block modeling and in-page editing. Do not add it as a dependency. If we inherit a deployment, budget a migration — freeze the content model, write the exporter early, contain the legacy instance behind a gateway, and set a decommission date with a named owner.
To executives: this is a "no" with a cheap exit. A short spike — roughly a day to confirm the framework mismatch and the deprecation posture, plus one to two weeks if we want to extract the content model into a requirements doc — closes the question. The downside of skipping it is zero, because nothing in our stack depends on it today. The downside of adopting it is unbounded and open-ended: an unpatched web-facing editorial surface, no upstream, no vendor, shrinking internal knowledge, and a vulnerability scanner that will eventually stop the release pipeline. The one genuinely valuable asset here is the design thinking, and the MIT license lets us take that for free.