Product Decisions This Supports
- Build vs. buy vs. fork triage. This is a "fork and internalize, or replace" decision, not an adoption decision. With 0 stars, 0 dependents, and a last release of December 2016,
grossum/core-bundle has no user base to inherit. Any value it offers must be re-owned by your team the day you add it.
- License posture and OSS policy. GPL-3.0 is the single most consequential fact here. For a proprietary or SaaS product, linking a GPL-3.0 PHP dependency is a legal-review event, not a code-review event. This package is a forcing function for answering "what is our copyleft policy for transitive Composer dependencies?" — a question worth settling once, in writing, before it surfaces in a diligence packet.
- Legacy modernization roadmap. The realistic PM use case is inventory, not adoption: identifying
grossum/core-bundle in an inherited Symfony 2.x/3.x codebase and sizing the removal work. Treat it as a line item in a migration epic with an owner assigned.
- Technical due diligence (acquisition, vendor handover, agency offboarding). A bundle published by a services agency in 2016 and never touched again usually means "internal shared utilities extracted from client work." That is a signal about the codebase you are inheriting, and it belongs in the risk section of the memo.
- Security and maintenance SLA scoping. Abandoned dependencies fail most maintenance SLAs by definition — no CVE response path, no PHP 8.x compatibility owner, no one to escalate to. If your product promises a patching window, this dependency cannot meet it.
- Roadmap capacity planning. Removing an abandoned core bundle from a legacy app is a scoped, estimable task. That is the only roadmap slot this package should ever occupy.
When to Consider This Package
Consider it only in these narrow cases:
- You are the original author (Grossum) or have an explicit internal mandate to maintain it, and you intend to fork, modernize, and relicense under something permissive.
- You are performing read-only archaeology on a legacy Symfony application and want to understand what a specific base class or helper was doing before you delete it.
- Your organization has already accepted GPL-3.0 as compatible with its distribution model (e.g., the product itself is GPL-licensed), and you have accepted indefinite self-maintenance.
Look elsewhere — decisively — when any of the following is true:
- The product is proprietary, SaaS, or distributed under a non-GPL license. This alone disqualifies it. Stop here.
- You are on Laravel. The package is a Symfony bundle in naming and lineage; it will not integrate with Laravel's service container, facades, or package discovery. If the request is "a Laravel package for X," this is the wrong candidate regardless of license. Evaluate maintained alternatives on Packagist with recent releases, active dependents, and MIT/Apache licensing.
- You need PHP 8.x or Symfony 6/7 support. A 2016 release targets a PHP 5.6/7.0-era runtime. You will spend more on compatibility shims than on writing the equivalent functionality.
- You need documentation, community support, or a security response channel. There is none. Zero dependents means zero downstream bug reports; zero stars means zero eyes on the code.
- You need a maintained dependency for a core, long-lived capability. Anything load-bearing deserves an actively released package or first-party code you own.
On the scores: the 0.13 overall score is the honest signal. Treat the 4.16 opportunity figure as an artifact of the gap between "no good option exists" and "this package exists" — high opportunity scores on abandoned packages measure neglect, not upside. Do not let a single favorable number outweigh zero adoption and a copyleft license.
How to Pitch It (Stakeholders)
For executives — one line: This is an abandoned, GPL-3.0-licensed PHP component with no users, no releases since 2016, and no maintainer; we should not adopt it, and if it is already in one of our products, we should schedule its removal.
The business case in three points:
- License risk is binary. GPL-3.0 can obligate us to release source for products that incorporate it. That is a legal exposure, not a technical preference, and it is not worth taking on for a package that saves us at most a few days of work.
- Cost of ownership is 100% ours from day one. No maintainer, no releases, no security patching. Every hour spent making it run on a current PHP version is an hour we could have spent writing the same functionality cleanly and owning it outright.
- The upside is unmeasurable and the downside is a roadmap line item. Zero dependents means no proven value in the wild. The realistic outcome is a migration task we fund later at higher cost.
For engineering — the ask: Do not add grossum/core-bundle to any new project. Audit existing composer.json files for it and report scope of use. If it is present in a legacy application, open a ticket to replace the small surface area it covers with first-party code (or a maintained MIT-licensed equivalent), and treat that work as part of the existing framework-upgrade epic rather than a standalone initiative.
Recommendation: Reject for adoption. Inventory and plan removal where found. The decision cost here is low — the answer is the same whether the need is Laravel, Symfony, or standalone PHP.