Interop wars: Common Cartridge, SCORM, and LTI

Introduction

In a 1999 server room, the course import “pipeline” was a literal pipeline: A faculty member zipped a course folder on a Windows machine, uploaded it over HTTP, and an LMS process unzipped it into a directory tree on a Solaris box. A manifest file declared what went where. Discussion boards wrote to a relational schema; the gradebook appended rows. Browser security meant framesets, not tabs; cross-domain calls were brittle; latency was something you budgeted in full seconds. That wirework is where interoperability standards came from—Common Cartridge, SCORM, and later LTI were responses to the operational constraints of the day, not blank-sheet ideals.

This is the record as I saw it from building early online learning platforms, co-founding Blackboard in 1997, taking the company public in 2004 (NASDAQ:BBBB), and shipping features and integration frameworks that had to run in real colleges with real networks and faculty workflows. The standards wars were never academic. They determined what counted as “a course,” which data could move, and how fast a new tool could reach a classroom. They also determined what we could not do—places we would wait years to revisit.

If you need a metaphor, think track gauge. Once rails are laid, trains follow those measurements. You can add new routes and better engines, but the spacing under every wheel fixes certain decisions for decades. The interop wars set the gauge under every learning platform that came after.

The Cartridge Bet We All Made

Common Cartridge arrived in 2008 from the IMS Global Learning Consortium (now 1EdTech). The operational need was simple enough: help institutions move courses between platforms and publishers ship content that would load the same way across LMSs. Procurement teams wanted to ask, “Does it import?” and hear yes. Course teams wanted a known path from development to delivery that didn’t depend on a specific vendor’s export format.

The design followed that need. Package content in a Zip, declare structure and resources in an XML manifest (imsmanifest.xml), and align assessments to a known question format (QTI). If a course was a set of folders, files, links, and assessments, then a cartridge could be the box those things traveled in. In practice, that meant several things you could point to on disk and on screen:

A manifest that named items and their relationships—modules, pages, files—so an LMS could reconstruct a navigation tree.
QTI-encoded assessments so a test bank from one platform could be parsed into another.
Web links that resolved to publisher-hosted activities instead of duplicating binaries.

It worked because it was concrete. The LMS that received a cartridge didn’t need to understand the pedagogy behind a sequence; it needed to render a sequence the way the sender intended and map questions to the receiving gradebook. Institutions could now inventory their content and treat it as portable capital. Publishers could build once and sell broadly.

Lesson — Design portability features to explicitly show what data will be lost during export.

The operational consequence of a packaging standard is that product teams naturally route course design toward what will survive the export. If a feature does not export cleanly, faculty avoid it or demand it be reengineered to fit the specification. This means innovation outside the box must be justified against migration cost, so it’s critical to flag what won’t carry through a round-trip and explain why to the user.

> Packaging content made courses portable—and it also fixed course design to what fit inside a manifest.

When cartridge compliance became a procurement checkbox, the market clustered around the lowest common feature set that imported with minimal friction. The standards working groups now mediated which ideas became “normal” in the LMS, because “normal” increasingly meant “portable.”

The Publisher Platform Effect

A second-order effect landed fast. By allowing web links as first-class citizens in a cartridge, the spec kept publishers in the loop. Institutions installed a thin cartridge that pointed to a publisher’s platform for rich activities and data, while keeping the LMS clean as the shell. Operationally, this created a split brain: content structure lived in the LMS; interaction and analytics lived elsewhere. The benefit was immediate—lighter imports and fresher content. The cost was steady—state and insight were now off-platform unless you built extra plumbing.

What We Gained And What We Froze

Common Cartridge gave institutions bargaining power—courses could move, and switching vendors no longer meant rewriting everything. It disciplined the industry around QTI and packaging semantics. It also held user experience to the floor of what the manifest could carry. Rich, stateful interactions, adaptive flows, or collaborative artifacts without a file-on-disk analogue tended to get expressed as links, which meant the LMS became a launcher more than a workspace for those activities.

SCORM And The Compliance Spine

SCORM’s origin story was different. The Advanced Distributed Learning (ADL) initiative in the early 2000s had a defense and corporate training mandate: track whether learners completed a module, how long they spent, and what score they achieved. The browser model of the day favored a JavaScript API exposed by the LMS inside a frame. The content—a SCO, or Shareable Content Object—called that API to read and write status. SCORM 1.2 stabilized the basic data model; SCORM 2004 added a formal sequencing and navigation model that very few adopted at full fidelity because of its complexity.

Operationally, a SCORM course load was a choreography you could draw on a whiteboard: open a frameset or runtime wrapper; initialize the API; attempt read/write to the LMS; heartbeat the session; on exit, commit the data model and set completion state. Firewalls, pop-up blockers, and cross-domain scripts turned that choreography into a support burden. Developers wrapped defensive code around every API call and taught content authors to avoid certain browser paths. The practical data ceiling remained brittle across implementations.

Lesson — Use compliance-focused standards for mandated tracking, but isolate them from creative or collaborative user experiences.

SCORM worked perfectly for units of instruction that looked like training modules but poorly for anything that needed shared, evolving state across people or time. The standard was great at answering, “What did this person do in this package?” It was not built to ask, “What did this group build together over six weeks?” Institutions with collaborative projects and iterative writing quickly hit walls, forcing vendors to contort designs to fit SCORM's data model or keep richer experiences entirely outside the LMS.

> SCORM nailed compliance and tracking—and it turned the LMS into a report generator for packages rather than a canvas for shared work.

Because SCORM compliance mattered in defense and regulated training procurement, vendors invested in meeting the spec before they invested in novel models of learning data. That spending priority shaped roadmaps. If you shipped LMS software in 2003, SCORM support landed before you built fancy collaboration because customers asked for it in RFPs.

The Invisible Costs Inside Teams

There was also a cost most users never saw. Support and QA teams lived inside the combinatorial space of browser versions, runtime wrappers, and LMS releases—all with their own interpretations of SCORM. A fix for one publisher’s sequencing flow broke another’s status commit. Engineering teams budgeted cycles for “SCORM hygiene” every release. Product managers learned to say no to features that risked the runtime, because the blast radius was too wide.

What We Carried Forward

SCORM trained a generation of implementers to think of learning as events to track and roles as accounts to provision. That mental model persisted well into the LTI era, showing up in the way tools framed their own analytics and how institutions wrote policy. You could see it in org charts: “SCORM Specialist” was a job; “Collaborative Artifact Steward” was not.

LTI And The Tool Corridor

Around 2010, IMS introduced Learning Tools Interoperability (LTI). The operational premise was clean: instead of trying to package all content or teach the LMS to host every kind of activity, let the LMS act as a launchpad for external tools with a shared security and data contract. LTI 1.0/1.1 leaned on OAuth 1.0a and simple outcomes; LTI 1.3 (with Advantage) moved to OAuth 2.0 and OpenID Connect, formalized deep linking, improved gradebook services, and normalized names and roles.

If Common Cartridge standardized the box and SCORM standardized the runtime inside a frame, LTI standardized the hallway between rooms. A faculty member added an external tool, the LMS generated a launch with context, the tool authenticated the call, and on completion the tool could return a score. This opened an ecosystem of assignment tools, virtual labs, and niche applications that would have never lived inside the LMS codebase.

Lesson — Standardize the common path for tool integration, but build escape hatches for richer, non-graded interactions.

Early LTI focused on the assignment-and-grade passback use case. Tools that did not center on grades, or that needed continuous event streams, had to build parallel integrations. The standard extended the LMS by standardizing how to leave it, cementing a narrow pattern of "link out, come back with a score" in the core product. A robust integration strategy requires pathways for tools that don't fit this model.

> LTI extended the LMS by standardizing how to leave it.

Operational reality has edges. Identity and provisioning smoothed out over time, but cross-institution analytics and privacy guarantees varied with each vendor. Deep linking improved content selection but didn’t change the basic pattern: the LMS remained the shell; the tool ran the experience.

What This Did To Product Shape

Tools built to the spec because that’s how they got adopted. Over time, the specification itself shaped product categories. “External Tool” became a unit the LMS UI recognized. Assignment launches became the one-click path. The richer your tool’s internal model, the more translation you built at the edges to fit the launch contract and the grade service. Vendors who built beyond it educated customers one at a time, but scaled more slowly because the default rails preferred the assignment model.

LTI 1.3 improved security and role semantics, but it did not, by design, turn the LMS into a data hub. Institutions that wanted a full picture of activity across tools stitched together separate feeds—Caliper, xAPI, vendor APIs—or settled for thin reporting. Mature privacy practices required consent screens and data minimization policies that many teams bolted on late because the spec could be implemented with a broad or narrow data footprint. The standard didn’t force a governance model; it forced a pathway.

The Interop Wars As Market Formation

Standards are not neutral. They are agreements made under constraints that reallocate power. From 1998 to 2015, three forces kept circling each other: institutions that wanted portability and switching power, publishers and toolmakers that wanted distribution and protection of their IP, and platform vendors that wanted extensibility without surrendering product shape.

Common Cartridge balanced institutions and publishers by keeping structure local and interactivity remote. SCORM balanced procurement and vendors by making reporting consistent while leaving pedagogy out of scope. LTI balanced platforms and tools by standardizing launch and grades while avoiding the mess of full data federation. Each balance made sense at the time; each carried downstream costs.

Our own extension framework shipped in the early 2000s—Building Blocks—let third parties add capabilities with deeper hooks than standards alone allowed. That was deliberate. We needed a way to move faster than a committee cycle when institutions pushed a use case that didn’t fit a manifest or a SCORM runtime. But adoption at scale pulled us back to the standards because that’s where procurement settled. The same dynamic played out at peers: Moodle plugins and Sakai tools thrived, but cross-campus deals still asked about Cartridge imports, SCORM, and later LTI compliance first.

If you plot the category formation, the curve looks familiar: Experimentation → Fragmentation → Standards (CC, SCORM, LTI) → Commercialization → Consolidation → Professionalization. The interop wars were the standardization-to-commercialization phase, where loud committees and quiet procurement line items set the rails.

What It Cost In Practice

Costs showed up in four piles: product shape, data depth, operational complexity, and pace of change.

Product Shape. Because import/export became a gating ask, LMS feature sets converged on what could survive a cartridge or a SCORM runtime. Rich editors, embedded collaborative objects, and custom workflows lost out to lists, files, links, and quizzes. Many other ideas migrated to external tools.

Data Depth. Manifests captured structure, not behavior. SCORM captured events at the level of a single package, not the relational story across people and time. LTI standardized a tunnel, not a warehouse. Institutions that wanted learning analytics beyond pass/fail assembled shadow data systems.

Operational Complexity. Supporting three main standards (plus local APIs and SIS connections) turned every release into a multi-variable test matrix. A spec version bump in one corner could break a publisher cartridge import in another. Teams carried a permanent interop budget that crowded out greenfield work.

Pace of Change. Committee cycles are measured in months and years, not sprints. The run-up to stable releases of new standards took time that product teams had to respect. Vendors who moved ahead of the spec paid an adoption tax in documentation, support, and one-off integrations.

Standards bought us portability and predictability—and they taxed product ambition, data richness, and speed.

The Procurement Paradox

Procurement teams needed shorthand. “Supports Common Cartridge” and “SCORM Compliant” became proxies for due diligence. That made sense. It also created a paradox.

Lesson — Write procurement requirements that reward desired learning outcomes, not just standards compliance.

By using standards compliance to reduce risk, institutions inadvertently reduced their upside by discouraging novel models that did not map to those specifications. A course portfolio built under those incentives looked safe on paper and repetitive in practice. Procurement documents should define success by the intended pedagogical experience, creating market demand for innovation beyond the baseline specs.

The Talent Trap

Organizations staffed to the standards. They hired cartridge specialists, SCORM QA engineers, and LTI integrators. That expertise is valuable. It can also become the center of gravity that makes change harder when the next protocol shows up. You see it now when teams try to move to event-based models: the people who can do it are busy keeping the old rails humming because that’s where today’s support tickets are.

What We Unmistakably Gained

It’s important to name the upside clearly, because the gains were—and are—real.

Portability of Institutional Assets. Courses became movable capital. That changed vendor behavior and pricing conversations. It also built courage inside universities to rethink their platforms because they could carry their content forward.

A Shared Vendor Ecosystem. Standards lowered the barrier to entry for toolmakers and content providers. LTI, especially, made it possible for small teams to reach classrooms without being acquired by a platform.

Baseline Privacy and Security. While not sufficient alone, the specs put guardrails around identity, roles, and data exchange. LTI 1.3’s model is a step change over ad-hoc SSO.

Professionalization. You can now hire someone who knows how to make this all work on day one. That matters when you run a campus at scale.

These gains are worth protecting as we add new capabilities. The point is not to rip up the rails; it is to understand where they lead and where we might need a siding or a parallel track.

Where The Rails Bent The Category

The metaphor is useful one more time. Rail gauge determines which cities can be served by the same trains without swapping wheels. In learning platforms, the “gauge” was the combination of what a manifest could describe, what an API could record, and what a launch could pass back. Those measurements bent the category toward content sequencing, assignments with scores, and packages with statuses. Collaboration, creation, and long-lived artifacts fit awkwardly. Social learning thrived in tools built for it, but the LMS saw only a link and a number.

This is why, a quarter century on, many LMS homepages still look like file trees with a gradebook—even when the rest of the web matured into collaborative canvases with real-time presence and rich objects. The rails served the freight we chose to carry.

A Practical Map For Now

We can add capability without breaking the bank if we treat standards as a protocol portfolio rather than a single doctrine.

Keep Common Cartridge for archival portability and bulk migration. Make your exporter honest—flag what won’t carry through a round-trip and why. Offer a “lossless as link” option so faculty understand when an embedded object becomes a launch.

Support LTI 1.3 (Advantage) as the default corridor for tools. Invest in a permission-aware UX that makes role/consent obvious on launch. Default to data minimization in claims; expand only with explicit purpose.

Treat SCORM as bounded. Maintain it where contracts require it and where the package model genuinely fits. Don’t route new collaborative experiences into the runtime.

Add an event backbone. xAPI and/or 1EdTech Caliper can carry the behavioral detail the other specs skip. Make events a first-class service with documentation, test harnesses, and examples. Feed them to institutional data platforms under a clear governance policy.

Publish an interop map. Document which standards and versions you support, how you test them, and the performance budgets. This reduces vendor friction and reveals where your rails need reinforcement.

Build a consent pattern. Treat data sharing the way we treat payments on the web: explicit scope, clear purpose, revocable grants, and audit trails.

Think portfolio—cartridge for structure, LTI for launches, events for insight, SCORM when mandated.

Implementation Notes From Hard Lessons

Version discipline beats feature sprawl. Pick specific spec versions and certify against them with real fixtures, not happy-path demos.

Test the failure modes. Simulate expired keys, mismatched roles, cross-domain cookies disabled, and slow vendor endpoints. What happens in your product is your responsibility, even when the event starts outside your walls.

Budget for performance. Interop often hides network calls; measure them. A slow launch feels like a broken standard to a faculty member.

Teach the mental model. Faculty and support staff don’t need protocol details, but they do need to know when something is “in the LMS” versus “in the tool.” Clear language prevents bad expectations.

The Bet I’d Make Today

If I were standing up a new platform or revising a mature one, I would treat interop as a civic infrastructure problem with a product manager’s discipline.

Set the rail gauge intentionally. Decide what “a course” means in your system beyond files and assignments. Name the native objects you will support first-class (e.g., collaborative docs, group spaces, simulations) and how they survive export—either as native serializations or explicit links.

Establish a protocol portfolio. Ship reliable Common Cartridge export/import for structure and assessments. Implement LTI 1.3 Advantage for launches, deep linking, and grades. Stand up an event pipeline via xAPI/Caliper with documented schemas and governance. Keep SCORM where contracts bind you; quarantine its effects from your core design.

Invest in consent and observability. Provide administrators and faculty with dashboards that show what data each tool receives, why, and with what retention policy. Offer per-launch scopes and make revocation easy.

Build the migration bridge. Create tools that convert legacy packages to your native objects where possible, and to clean, explained links where not. Communicate the tradeoffs plainly. Meet institutions where they are, not where you wish they were.

Align incentives. Price and contract in ways that reward modern protocols without penalizing the institutions still living with SCORM archives. Offer support tiers that include interop audits and health checks.

Most importantly, make the gains additive. You don’t have to take portability away to earn deeper engagement and richer data. You have to be explicit about what travels, what stays, and why.

One last turn of the metaphor: The rail gauge we chose let us build a continent-wide network. It also narrowed the kinds of trains we ran. We can lay a second track alongside the first—one built for collaborative artifacts and event streams—without tearing up the old line. The cost of the wars is sunk; the benefit of a clear map is still ahead.

Interop wars: Common Cartridge, SCORM, LTI