Campaign Bundle Laravel Package

Product Decisions This Supports

• Feature scoping — content override / "takeover" mode. The core capability is forcing a set of screens to display only campaign content for a bounded window, then automatically reverting to normal programming. That is a distinct product behavior from ordinary scheduling and deserves its own roadmap line item: it answers "how do we guarantee a message is seen?" rather than "how do we queue content?"
• Roadmap placement of scheduling primitives. The package models campaign lifecycle (create → edit → publish) plus time-limited windows and channel targeting. Use it as a checklist for the minimum viable scheduling model: start/end bounds, target selection, revert-on-expiry, and an explicit notion of "normal content" to return to. If our roadmap has scheduling without a revert semantic, this is the gap to close first.
• Build vs. buy vs. fork. Three viable options, and the PM decision is which one, not whether the concept is worth building:
  1. Adopt — only defensible for an existing OS2Display/Symfony estate already on this bundle family.
  2. Fork and own — MPL-2.0 permits it; requires committing a named owner and a maintenance budget.
  3. Reimplement the pattern — treat the repo as a specification and build the override primitive natively on our stack.
• Emergency / priority messaging. The "force screens to show selected content" mechanic is the same primitive needed for urgent notices. Recognizing that overlap early avoids building two override systems that later collide over who wins when a campaign and an alert target the same screen. Priority and conflict resolution should be decided at the product level now, not resolved by whichever code path runs last.
• Sales and packaging. Campaign override is a demonstrable, sellable capability for retail and out-of-home networks — visible in a demo, easy to explain. It can anchor a tier or an add-on, and its value scales with screen count, which affects pricing model choices.
• Use cases that justify the investment: retail promotional windows tied to a launch date, venue or sponsor takeovers, seasonal and event-driven content, and time-boxed advertiser commitments where under-delivery is a contractual problem.

When to Consider This Package

Consider adoption when:

• We already run OS2Display on the Symfony stack and campaigns are the missing capability — the integration surface is then a bundle registration, not a port.
• The requirement really is exclusive override for a bounded window with automatic revert, and we have no existing override primitive to reconcile with.
• We have an owner prepared to fork. The repository is archived, the last release is 2019-05-20, and it carries a single star. Those three facts together mean there is no upstream support path and no security response process. Any adoption is a fork in all but name, and should be scoped, staffed, and approved as such.
• A license review has cleared MPL-2.0 for our distribution model. It is file-level copyleft; it is generally workable for internal and hosted use but needs confirmation before shipping modified source.

Look elsewhere when:

• The target application is Laravel and greenfield. The package's lineage is Symfony bundle conventions; the release notes describe presentation-tier and asset concerns, and version constraints must be read from composer.json rather than assumed. Retrofitting is a refactor, not an install.
• We need a currently maintained dependency with a responsive issue tracker, security disclosure process, or a supported major line. None is evidenced here.
• We need multi-tenant isolation, modern API contracts, or integration with a contemporary scheduling stack. A 2019 artifact will not meet current baseline expectations for auth, observability, or dependency hygiene.
• Requirements are simpler than full campaign lifecycle — a single "pin this playlist for N days" flag may be cheaper to build than any adoption path.
• A dependency audit would block an archived package with unverifiable transitive weight regardless of technical fit. In that case, decide between fork and reimplement and skip adopt entirely.

Regardless of path, resolve these before committing: is the previous campaign icon still shipped or aliased; is "screen-bundle" support additive or does it change existing bundle resolution; does the package assume a single-node filesystem for assets; and are there tests covering the screen-bundle code path.

How to Pitch It (Stakeholders)

Summary. The campaign-bundle implements a genuinely useful product primitive: exclusive, time-boxed control of a set of screens that automatically reverts to normal programming. That capability is strategically relevant — it underpins promotional windows, sponsor takeovers, and urgent messaging, and it is easy to demo and easy to sell.

The artifact, however, is not a viable dependency. It is archived, unreleased since May 2019, effectively unstarred, and its most recent changelog consists of two bullet points — one of which silently swaps an icon asset with no deprecation or migration note. There is no evidence of an issue tracker, a maintained branch, or a security disclosure route. We cannot buy support, and we cannot ask anyone to fix a defect.

Recommendation: adopt the pattern, not the package. Treat the repository as a design reference and build the override primitive on our own stack, where it can integrate with our existing scheduling, alerting, and priority rules. This costs more up front than a Composer install and materially less than owning an orphaned fork — and it avoids the failure mode that matters most, which is screens silently rendering the wrong content while logs report success.

If a stakeholder pushes for the fastest path — typically because a customer commitment is already in play — the fallback is a fork pinned to an exact version, with a named engineering owner, a funded maintenance line, and a smoke test asserting the expected assets resolve. That is a conscious decision to own a 2019 codebase, and it should be approved as one rather than assumed to be free.

What we need from the business: confirmation of whether campaign override is a committed roadmap item with a date, and if so, whether the priority is speed-to-demo or long-term maintainability. Those two answers lead to different recommendations, and holding both is what creates the expensive middle ground.