Common Bundle Laravel Package

Product Decisions This Supports

• Portfolio standardization for Sulu estates. If your organization runs multiple Sulu CMS sites, this bundle supports the decision "do we maintain a shared internal baseline, or copy-paste CMS glue between projects?" It collects reusable services, config defaults, and helper utilities into one place — the classic DRY argument for a portfolio of similar sites.
• Build vs. buy vs. reuse. For Sulu projects the real choice is: (a) adopt this bundle, (b) maintain an in-house common bundle, or (c) assemble individual community bundles per concern. This package only wins on (a) if the inventory of components collapses enough duplicated work to justify a hard dependency.
• Roadmap and upgrade gating. Because it sits between your application and Sulu/Symfony, adoption makes it a release-gate dependency — every Sulu, Symfony, or PHP bump routes through its maintainers' release cadence. That belongs in release planning.
• Feature scoping by days saved, not feature count. The value proposition to test is "how many engineering days per project does this remove?" — faster onboarding of commodity CMS features (admin UI conventions, shared validation, common content-type helpers) so product effort goes to domain work.
• Ownership and vendor-risk decisions. With zero stars and zero dependents, this is an explicit "are we comfortable being the only real consumer?" call. That is a PM decision, not a technical one, and it should be recorded as such.
• Scope correction as a decision itself. The brief frames this as a "Laravel/PHP package," but it is a Symfony bundle built for Sulu CMS — it does not install into Laravel without a port. Any roadmap item framed as "adopt for Laravel" must be corrected before it is prioritized. This package supports no decision about a Laravel service, a non-Sulu Symfony app, or a headless/API-only content platform.

When to Consider This Package

Consider it when all of the following hold:

• You already run Sulu CMS on Symfony across more than one project, and you can point to concrete duplicated code between them.
• The bundle's actual contents map to your duplication — read the source and list what you would genuinely use. A "common" bundle where you need 2 of 10 utilities is not a win.
• You are willing to fork and maintain it if upstream goes quiet. With zero dependents, that contingency is the default plan, not the fallback.
• The license and the maintainers' intent (internal extraction vs. supported OSS) clear your legal and procurement process.
• You can pin it and upgrade deliberately — your CI can prove a Sulu/Symfony bump does not silently break you.
• You have named an internal owner for the fork for the next 12 months.

Look elsewhere when:

• You are on Laravel or plain Symfony without Sulu — the bundle is the wrong shape. Mine it as reference code, do not install it.
• You have one Sulu project. Shared bundles only pay off across a portfolio; a single app should own its code directly.
• The components you need are already covered by maintained, widely adopted community bundles. Prefer the dependency with dependents.
• You need support SLAs, a security disclosure path, or a documented BC policy — a zero-adoption bundle gives you none of that.
• Your team cannot absorb an additional fork to maintain. Every under-maintained dependency is a latent maintainership cost, not a freebie.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, internally oriented Symfony bundle for Sulu CMS sites that packages code our teams would otherwise rewrite on every project. It is not a strategic platform, and it is not a Laravel component — that framing should be corrected before it reaches the roadmap. Its value is measured in avoided duplicate effort across a Sulu portfolio, potentially a few engineering days per project. Against that it carries concentration risk: no measurable external adoption, so if the maintainers stop, we own it. Recommendation: treat it as an evaluation candidate for a defined Sulu portfolio, not a standard, and adopt only behind a fork-and-pin policy with an owner named internally. If we do not have two or more Sulu projects with real duplication, the right decision is to decline.

For engineering: The pitch is "stop rebuilding the same Sulu glue." Validate it in a short, timeboxed spike: diff the bundle's components against our actual duplication, run our Sulu/Symfony/PHP matrix against its constraints (composer require --dry-run), and classify each component as portable utility, framework-coupled, or Sulu-coupled. Assume we may need to fork — confirm the license permits it, check commit recency and issue responsiveness, and decide up front who owns the fork. If the answer to "who owns this in 12 months?" is unclear, do not adopt.

Bottom line for the roadmap: worth a time-boxed audit, not a line item. Gate adoption on demonstrated duplication removed, a named internal owner, and a fork contingency. If we run Sulu, re-evaluate the calculus; if we run Laravel, do not adopt as a dependency.