Youtube Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. fork. The real decision is not "adopt or not" — the package is archived, so it is "fork and own ~a few hundred lines of YouTube slide logic" versus "rebuild the same slide type in our own renderer." Framing it as fork-vs-build is the decision that actually unblocks the team; framing it as a dependency evaluation leads to a dead end, because there is no maintainer to depend on.
• Whether YouTube is a supported content source on the roadmap. This package answers a product question — can editors put video on screens without asking engineering — with a specific, dated (2019) implementation. If YouTube is a roadmap content type, its capability list is a useful requirements sketch: URL or search-based selection, autoplay/mute/controls config, and reuse of existing scheduling and templates. Treat the feature list as a spec to beat, not a spec to inherit.
• Editor self-service and content-ops load. Search-or-URL selection moves video publishing out of engineering tickets and into the editorial workflow. That is a measurable reduction in content-ops turnaround, and it is the strongest product argument for keeping YouTube in scope at all.
• Platform coupling and exit cost. Adopting this couples your slide model to OS2Display's bundle conventions and to a specific major-era Symfony API. Since the upstream is archived, every future Symfony or PHP upgrade is your migration to fund. Price that into the roadmap before committing, not after.
• Compliance and consent posture. Embedded YouTube means third-party requests and cookies on signage players, often in public-sector or EU deployments. Whether playback defaults to youtube-nocookie and whether consent gating is required is a product/compliance decision, and an abandoned 2019 component will not make it for you.
• Licensing position. MPL-2.0 is file-level copyleft: fine for internal, non-distributed use, but modifications to existing files should stay under MPL if the bundle is ever distributed. Worth a legal confirmation before it enters the codebase, not after.

When to Consider This Package

Consider adopting (as a fork, not as a live dependency) when:

• You already run OS2Display and need a YouTube slide type this quarter; forking beats reimplementing the integration glue.
• You are willing to assume ownership explicitly — vendor the source into your repo, pin a commit, and budget for Symfony/PHP upgrades.
• Engineering has confirmed the bundle registers and renders on your current Symfony/OS2Display versions (2019-era code; verify before planning around it).
• Legal has signed off on MPL-2.0 and on the YouTube embedding/consent approach for your deployment regions.

Look elsewhere when:

• You are on Laravel. This is a Symfony bundle targeting the OS2Display platform, not a Laravel package. There is no sensible path to dropping it into a Laravel app; that mismatch alone should stop the conversation.
• You need maintained support, security backpatching, or a release cadence — the upstream is archived, last released 2019, with no visible community (0 stars). "Consider" here means "harvest the source," never "depend on upstream."
• You need capabilities the 2019 implementation predates: playlists, live streams, Shorts, caption/accessibility handling, privacy-enhanced embeds by default, or API-quota-aware search.
• Your only evidence is the repository description and one changelog line. That is the current state — commission a short spike (install, render a slide, read the code) before any commitment.

How to Pitch It (Stakeholders)

To executives: This is a small, contained decision about one slide type in our signage stack, and the honest framing is that it is not a live dependency. The upstream project is archived with no releases since 2019, so we would be harvesting a small amount of working code and owning it ourselves. That is still the cheaper option versus building YouTube playback from scratch, but the cost is ownership, not licensing — there is no maintainer to rely on and no support to buy. It also comes with a compliance caveat: embedded video means third-party requests and cookies on players, which matters for our deployment environments. My recommendation is to treat this as vendored source code with a named internal owner, or to fund a short rebuild if we want YouTube as a long-term roadmap capability. Either way, the spend is weeks, not quarters, and the risk is bounded and reversible.

To engineering: Important correction to the brief — this is a Symfony bundle for the OS2Display platform, not a Laravel package, so it is relevant only if we are working inside OS2Display. Last release was 2019 and the repo is archived, so plan for a fork, not composer require. Concretely: vendor the source into our repo and pin a commit; do not build a production dependency graph on an unmaintained Packagist entry. Two things to verify in a short spike before we commit — first, that the bundle registers and renders a slide on our current Symfony and OS2Display versions (2019-era API assumptions are the main risk); second, that playback uses privacy-enhanced embeds and that search-by-query, if we rely on it, has a sane API key and quota story. Note also that the only release note we have (2.0.1) is a Composer package-name fix, which tells us the distribution name moved at some point — confirm the name resolves before anyone writes it into scaffolding or CI.