Live Broadcast Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for scheduling primitives. If the roadmap includes any form of live programming — streamed shows, radio-style blocks, live commerce drops, webinars, worship services, classes — a planner/scheduler is a non-trivial chunk of calendar logic, recurrence rules, timezone handling, and broadcast state. This package remains a candidate to shortcut that work rather than speccing it from scratch.
• Time-to-market for a media/broadcast MVP. Still best evaluated as an accelerator for a first version of a programming calendar, not as the long-term backbone. The v7.0.5 release strengthens the "it's alive" signal but does not change the "it's small" signal.
• Channel-integration scoping. The release note — "Update the Facebook API calls to plan a livestream" — confirms the package does not stop at a local schedule table; it reaches into at least one streaming vendor's API to create/plan a live broadcast. That shifts a decision: if Facebook Live is one of your launch channels, this package may absorb real integration work (auth, permissions, broadcast creation) rather than just calendar math. If Facebook Live is not a channel, that surface is inert weight you must still carry and occasionally patch.
• Feature scoping. Use it to pressure-test requirements: one-off broadcasts, recurring slots, EPG-style program guide, or just "go live" buttons? The presence of a vendor-planning integration is evidence the author modeled "schedule → create broadcast upstream" as a first-class flow — useful prior art when writing your own requirements, regardless of whether you adopt it.
• Roadmap sequencing. Low-cost, MIT-licensed dependency continues to de-risk putting "programming schedule" into an early release instead of deferring it to a later platform phase.
• Portfolio / platform plays. Relevant for creator platforms, community radio/TV, education, faith-based streaming, and internal comms — segments where a planning calendar is the differentiating workflow but nobody wants to own the calendar engine.

When to Consider This Package

• You are on PHP/Laravel (or a PHP-adjacent stack) and the product genuinely needs broadcast planning — a schedule of upcoming live sessions — rather than just "start stream" capability.
• Facebook Live is a real launch channel, or you are willing to accept and ignore that code path. The v7.0.5 change means the package's maintenance is at least partly driven by Meta's Graph API versioning cadence — which is a good sign for upkeep and a new risk to price in (see below).
• You want to validate a feature cheaply: spike it behind an adapter interface, ship an internal or beta version, and only replace it if traction justifies it.
• Your team can read and own third-party PHP code. The package now shows an active release line — v7.0.5, and a major version of 7 implies a long prior history — which is better than the earlier read of "quiet since May 2023." But re-verify star count, dependents, and release cadence before relying on it: treat it as source you adopt, not a vendor you depend on. Pin the version, fork if you must, and budget maintenance as a known cost line.
• The blast radius is contained: scheduling is a supporting workflow, not revenue-critical uptime infrastructure, and failure degrades gracefully (fall back to a manual schedule).
• Licensing and procurement matter: MIT means no legal friction, no per-seat cost, and clean exit rights — a meaningful advantage over commercial scheduling/EPG vendors for an early-stage bet.

Look elsewhere (or build) if: you need a support SLA; you will not patch vendor-API code yourself — the Facebook integration introduces third-party surface (Graph API version sunsets roughly on a two-year cycle, app review/permission scopes for Live, token expiry and refresh) that generates maintenance work even when your own scheduling logic is untouched; your scale demands hardened, tested concurrency around live state transitions; you need integrations this package does not cover (Mux, Cloudflare Stream, Wowza, Agora, YouTube, Twitch) — one vendor does not imply breadth, and it will not own ingest, playback, or analytics; or your scheduling needs are trivial enough that a starts_at column plus a queue beats adding a dependency.

How to Pitch It (Stakeholders)

To executives: We can ship a live-programming calendar in weeks instead of a quarter, at effectively zero license cost (MIT), and the package is still being maintained — a new v7.0.5 release updates its Facebook Live integration. That's a modest but meaningful correction to the earlier read that it looked abandoned. The caveat is unchanged in substance: it's a small open-source project, so it is a starter kit, not a supplier. The recommendation is a time-boxed evaluation: one engineer, a short spike behind our own interface, and a go/no-go. We wrap it so the exit door stays open — if it stalls, or if Meta's API churn becomes a tax we don't want, we swap the implementation without touching product surface. Upside is schedule compression; downside is bounded engineering time plus a small ongoing maintenance item that now includes keeping a vendor integration current.

To engineering: Treat this as vendored source. Fork it, pin it, wrap it in an adapter so our domain model doesn't inherit its assumptions, and add tests around the edge cases we care about — timezones, recurrence, daylight-saving transitions, cancellation/rescheduling. Two things to verify that the release changes: (1) framework and PHP version compatibility against current Laravel, since a 7.x line may carry assumptions from an older framework baseline; (2) what the Facebook code actually does — whether it calls the Graph Live API directly, how it handles API version pinning, token refresh, and permission scopes, and whether that code is isolated enough that we can leave it disabled if Facebook isn't a launch channel. Confirm whether v7.0.5 is a safe patch on the version we'd pin, and check the changelog between majors for breaking changes before adopting. Report back on code quality, test coverage, and true cost of ownership — that assessment, not the star count, is the decision input.