Product Decisions This Supports
- Scoping an availability/scheduling feature. The package models the core primitive — a time-bounded schedule attached polymorphically to any model — which is directly reusable as a spec for "who/what is available when." Useful for roadmap conversations about worker shifts, room/equipment booking, service windows, or on-call rotations.
- Build vs. buy vs. fork. A 155-star, archived, last-released-Feb-2019 package is a reference implementation, not a dependency. The decision it most supports is "buy the idea, build the code": read the source for the polymorphic schedule schema and availability query shape, then implement in-house with modern Laravel and PHP.
- MVP definition. It clarifies the minimum viable data model (morphable entity, start/end timestamps, availability lookup by time range). That shortens the design phase for a scheduling epic and lets you defer the genuinely hard parts (recurrence, exceptions, timezones) with eyes open.
- Make vs. integrate. Informs whether scheduling is core differentiation for your product (build, own the domain) or incidental plumbing (integrate Google Calendar / Calendly / an RRULE library like
simshaun/recurr and lean on Carbon for range math).
- Risk decisions on legacy surfaces. If an existing app still runs Laravel 5.x on PHP 7.x, this is a cheap way to ship a prototype; that data point feeds the broader "how long do we keep this app alive" decision.
When to Consider This Package
Consider it (narrowly):
- You are prototyping on a legacy Laravel 5.6–5.8 / PHP 7.x codebase and need a throwaway availability demo in days, not weeks.
- You want a compact, readable reference for a polymorphic schedule schema before writing your own migrations.
- Scope is single-timezone, non-recurring, low-concurrency, internal-tool scheduling with no compliance exposure.
Look elsewhere — or build — if any of these are true:
- It is archived. No security patches, no Laravel 6+ compatibility guarantees, no PHP 8 support, no response to issues. Shipping it into a maintained product is an unhedged liability.
- You need recurring shifts, exception dates, holiday calendars, overnight or split shifts, DST-safe timezones, or partial-day availability — none of which a 2019-era range query solves.
- You need overlap validation, double-booking prevention, or concurrent write safety. Availability is a race-condition problem; assume the package does not solve it and budget for DB-level constraints.
- You need audit trails, soft deletes, multi-tenancy, or authorization around who can see/edit whose schedule.
- Your product surface is customer-facing or contractual (billing by hours, SLAs, staffing compliance) — correctness risk is too high for unmaintained code.
- Composer constraints already block it on your Laravel version; do not spend engineering time on constraint gymnastics for an archived package.
Recommended path: timebox a 1–2 day spike to read the schema and query logic, then write a small internal package (~300–500 LOC) with explicit recurrence, timezone, and overlap rules. Treat the 2019 release as documentation, not a dependency.
How to Pitch It (Stakeholders)
To executives: We evaluated an open-source scheduling package that matches an adjacent feature we're planning. It is MIT-licensed and its data model is a good starting blueprint, but it was last released in February 2019 and the maintainer has archived it — meaning no security fixes and no compatibility with our current framework. My recommendation is to reuse its design, not its code: roughly a one-to-two day spike plus a small in-house build. That keeps us off an unsupported dependency while still saving most of the design time, and it avoids a future forced migration.
To engineering: The package gives us a polymorphic schedule model with start/end ranges and availability lookups. It's a useful shape, but it predates modern Laravel and PHP 8, is archived, and has no coverage of recurrence, timezone/DST correctness, exception handling, or overlap/concurrency safety — which is where the real work lives in this domain. Proposal: treat it as a reference spec, implement internally behind our own interface, and use Carbon plus an RRULE library for recurrence. That also keeps us free to swap in a commercial calendar integration later without touching call sites.
Bottom line: archived + 155 stars + zero releases in six years = read it, don't ship it.