Campaign Bundle Laravel Package

Technical Evaluation

Architecture fit. The first thing to correct: this is a Symfony bundle, not a Laravel package. The -bundle suffix is Symfony's convention, and os2display is a Symfony/Doctrine digital-signage platform (Aarhus open-source lineage) composed of sibling bundles — core, screen, slide, template, media, campaign, admin, API. That changes the evaluation materially. It is also not a leaf/presentation-tier dependency. Campaign management is domain logic: a Campaign entity with scheduling windows, channel/screen targeting, and an override that suppresses normal playback while active. It sits alongside screen-bundle and slide-bundle and shares their entities. Any assessment that treats it as an installable asset-composition helper is wrong and would mis-scope the work.

Integration feasibility. There are exactly three viable postures, and they should be stated plainly to stakeholders:

1. Consume as-is — only possible inside a running OS2Display instance of a compatible vintage. It is not a drop-in for a Laravel or generic Symfony app; it has no meaning without the screen/channel/slide domain it overrides.
2. Fork under MPL-2.0 — permitted (file-level copyleft; our own files stay proprietary, modified MPL files must be published). This is the realistic path if we want the capability.
3. Reference implementation — read the entity model and override logic, rebuild scheduling against our own schema. Often cheapest if we are not already on OS2Display.

Technical risk. Dominant risk is lifecycle, not code quality.

• Archived and unmaintained since 2019-05-20. No security patches, no compatibility work for current Symfony/PHP, no PRs accepted. Its framework constraints will be pinned to EOL Symfony 3.x/4.x-era and PHP 7.x.
• Hard coupling to sibling bundles. 2.1.0's "added support for screen-bundle" means the campaign override depends on that bundle's resolution path. Version-skew between campaign, screen, and core bundles is the most likely integration failure, and it fails at runtime, not install time.
• Silent domain failure. The override is a stateful suppression of normal content. A campaign that activates but does not release leaves screens pinned to promo material indefinitely. That is a customer-visible outage with no alerting unless we build it.
• Zero community. 0 stars, archived, no issue triage. "MPL-2.0 and archived" is effectively "here is a codebase, you own it now."
• Thin release notes (two bullets, no PR links, no migration guidance) mean every future diff must be read rather than trusted — though with an archived repo, "future" is moot unless we fork.

Key questions.

• Are we already running an OS2Display instance, and at what bundle versions? If not, posture 3 (reference only) applies and the rest of this assessment is hypothetical.
• What is the exact Symfony and PHP constraint set in composer.json, and does it intersect a supported runtime we are willing to operate?
• Which sibling bundles and minimum versions does campaign-bundle require, and are those versions still obtainable?
• Is campaign activation evaluated server-side at render time, at player poll time, or via a scheduled job? The answer determines the failure modes and the alerting we need.
• What is the campaign-expiry mechanism — explicit end datetime, cron sweep, or lazy evaluation? This is the single highest-leverage question for production safety.
• Do we have appetite to own a fork indefinitely, and who signs for that?

Integration Approach

Stack fit. Symfony + Doctrine + MySQL, administered through the platform's admin UI and exposed via its API bundle. If our stack is Laravel, the integration cost is not "add a Composer dependency" — it is "stand up a separate Symfony application." That is a programme decision, not a sprint task. Confirm the platform fit before any estimation.

Migration path.

• If already on OS2Display: pin 2.1.0 exactly (no caret), vendor the source into our repo, verify sibling bundle versions resolve, run the campaign migrations against staging, and diff screen behaviour for one channel before enabling a second.
• If building fresh: treat the repo as a design reference. Extract the campaign/schedule/targeting entity model and the override semantics, then implement against our own schema. Do not vendor a 2019 Symfony bundle into a modern app to save a week of modelling.
• If forking: fork immediately, tag our own version, add a supported-Symfony compatibility branch as a scoped work item, and accept that we now own a maintained fork. Budget this as ongoing headcount, not a one-off.

Compatibility. Three axes to verify from source, not from release notes: (1) Symfony/PHP constraints against our runtime; (2) sibling bundle version ranges — campaign, screen, and core must move together; (3) database migrations, which on a live signage deployment cannot be rolled back casually. The "changed campaign icon" note is the one genuinely low-risk item here — an admin-UI asset — and should not consume assessment bandwidth relative to the coupling and lifecycle risks.

Sequencing. Resolve the posture question first; everything else is wasted if the answer is "reference only." Then, in order: pin and vendor; verify sibling resolution in a container; enable campaign override on a single low-stakes channel; instrument expiry; then broaden. Do not enable campaign override across a fleet until expiry behaviour has been observed through at least one full campaign window — that is the only way to prove the release path works.

Operational Impact

Maintenance. There is no upstream maintenance. The realistic model is: we own the code the day we adopt it. That means a named owner, a fork in our namespace, a documented set of local patches, and a standing line item for Symfony/PHP compatibility work. If nobody will sign for that, do not adopt — use it as a reference and move on. MPL-2.0 makes the fork legally clean, which is the package's main remaining asset.

Support. None. Archived repository, no disclosed security process, no response history to evaluate. The nearest thing to support is "read the source." For a domain-tier component that can suppress all normal content on a screen fleet, that is a materially higher bar than it would be for a presentation-tier helper — a position the generic framing of this evaluation should not obscure.

Scaling. Server-side cost is modest: campaign evaluation is a lookup against active windows per screen/channel. Two things need checking in source. First, whether override resolution is cached per screen or recomputed on every player poll — signage fleets poll on short intervals, so an uncached join per poll multiplies quickly. Second, whether any campaign content is resolved from local disk; if so, multi-node deployment behind a load balancer breaks it and it must point at shared or object storage.

Failure modes.

• Stuck override (highest severity). A campaign activates, expiry never fires, screens show promo content indefinitely. Looks like success in logs — the campaign is "active" — while normal programming is dark.
• Clock and timezone skew. Scheduling windows evaluated against player or server time drift, producing campaigns that start late, end early, or straddle DST incorrectly.
• Version skew. Campaign, screen, and core bundles at mismatched versions; resolution falls back to a default and renders the wrong content rather than erroring.
• Silent scheduler death. If expiry is a cron/worker, its failure is invisible until someone notices the screens.
• Unpatched exposure. An archived Symfony-era component carrying known CVEs into a public-facing admin surface.

Mitigations are concrete and cheap: pin the version, add a monitor that asserts no campaign has been active past its window, alert on scheduler heartbeat, and run expiry evaluation against a single authoritative clock source.

Ramp-up. For a Symfony-fluent developer, the mechanics are a day — install, migrate, register a channel, observe the override. The real ramp-up is domain onboarding: understanding how campaign override interacts with screen, channel, and slide resolution is the difference between a working pilot and a fleet incident. For a TPM, the meaningful ramp-up is governance, not API: until the posture question and the expiry-mechanism question are answered, any estimate presented to stakeholders is a guess. Carry explicit contingency, and be prepared to recommend against adoption if no long-term owner exists.