Laravel Scorm Laravel Package

Product Decisions This Supports

• Build vs. buy on training delivery. This package is the accelerator that makes "build a lightweight LMS into our existing Laravel product" a realistic option instead of a 6–12 month detour or a six-figure LMS license.
• Core product loop definition. It enables the three-step loop every training product needs: import a course package → launch a player → record completion, score, and time. That loop is the foundation for everything downstream (reporting, certifications, billing).
• Roadmap sequencing on standards. Forces an explicit decision on SCORM 1.2 vs. SCORM 2004 vs. xAPI/cmi5. Recommendation: ship 1.2 first (covers the majority of Storyline/Captivate/iSpring output), treat 2004 as a fast-follow, and defer xAPI until a customer contract demands it.
• Use cases it unlocks. Customer/partner onboarding academies, compliance and certification tracking, channel enablement, internal L&D, and paid course bundles attached to existing subscriptions.
• Data model and reporting decisions. It surfaces the schema questions a PM must own: registrations vs. attempts vs. runtime CMI records, and how those map to completion rates, time-to-completion, and assessment scores in BI.
• Packaging and monetization. Per-seat, per-course, or per-completion pricing all depend on reliable completion events — this package is where those events originate, so its reliability is a revenue concern, not just an engineering one.
• What it does not decide. It is an ingest-and-runtime layer only. Catalog, authoring, search, notifications, SSO, and analytics remain our scope — don't let "we have a SCORM package" get mistaken for "we have an LMS."

When to Consider This Package

Adopt (as a starting point, not a dependency):

• You are already on PHP/Laravel and want training inside the existing auth, billing, and admin surface rather than a second platform.
• You must play SCORM 1.2 packages produced by mainstream authoring tools, and your learners number in the thousands, not millions of concurrent sessions.
• You are time-boxed (MVP, pilot, or a single enterprise deal with a training requirement) and can afford a fork-and-own commitment.
• MIT licensing fits procurement constraints and you're comfortable vendoring the code into your repo.

Look elsewhere:

• Standards beyond SCORM. xAPI, cmi5, LTI 1.3, or AICC requirements are out of scope — use a hosted engine (SCORM Cloud, Rustici) behind an API.
• Enterprise LMS expectations. Authoring tools, virtual classrooms, deep hierarchical reporting, multi-tenant org structures — buy Moodle, Docebo, or TalentLMS and integrate with SSO.
• Maintenance risk is unacceptable. Last release was September 2022, ~48 stars, single maintainer, repository provenance unverified. For audit-critical or regulated compliance programs, that is a supply-chain finding, not a footnote.
• Scale or SLAs. SCORM runtime is inherently stateful and chatty; if you need guaranteed throughput and vendor support, a hardened commercial runtime is the safer line item.
• You have no PHP depth. Adopting this means owning the runtime handshake, session handling, and CMI persistence — budget a spike before committing.

Mitigation if adopted: fork it, pin the version, wrap the runtime behind an internal interface, and write conformance tests against a fixture set of real packages. That keeps the swap-to-hosted-engine option open and converts a stale dependency into a bounded, owned component.

How to Pitch It (Stakeholders)

To executives: "We can put training delivery inside the product we already sell, in weeks rather than quarters, without an LMS license or a procurement cycle — the code is MIT-licensed, so the investment is engineering time, not contract value. It also gives us a clean upsell surface (certifications, partner academies) attached to existing subscriptions. The honest risk is that it's a small, single-maintainer open-source project last released in 2022; we manage that by owning a fork and scoping to the standard most of our customers' content already uses. If demand outgrows it, we can swap in a commercial engine behind the same internal interface."

To engineering: "This is a thin Laravel layer over imsmanifest.xml parsing, the SCORM runtime API, and CMI data persistence via Eloquent — not a framework. We'd vendor it, pin the commit, and add tests around the runtime handshake, LMSSetValue/LMSCommit/LMSFinish, and session teardown, since that's where these integrations break. Wrap storage behind our own repository interface so a hosted runtime can replace it later. First spike: validate SCORM 1.2 against three real packages from our prospects, then assess 2004 effort. Estimate the ongoing cost as 'a component we own,' not 'a dependency we consume.'"