Open standards vs open source in education

Introduction

At 7:30 a.m., the registrar’s office opens a change ticket: move 3,200 students from a canceled section into four new ones before the first lecture. The LMS has to reflect the new rosters; the video platform needs the right entitlements; the proctoring tool must pick up accommodation flags; the gradebook should not duplicate columns; the SIS must remain the system of record. Nobody asks who owns the LMS code. They ask whether the systems will talk in time and whether the change will cascade without breaking downstream reports.

That is the daily operational reality in education. Integrations run the campus: identity in, rosters across, content and tools attached, event trails out. When it works, students see their courses and materials at the first click; instructors don’t fight lists and logins; researchers can trust a learning analytics export to match census dates. When it fails, the help desk surges, instructors pivot to email, and leadership gets a weekend call.

The infrastructure constraint is not whether software could be forked. It is whether data and actions cross system boundaries predictably, at scale, and under audit. That is the domain of open standards — contracts on how systems speak — not open source — rights to copy and modify code.

I learned this the long way. In 1997, we built CourseInfo and merged with Blackboard to form Blackboard Inc. Our thesis was simple: course websites needed to be more than file drops; they had to be hubs that touched enrollment, authentication, content, and assessment. In the early 2000s, we introduced Building Blocks so outside developers could extend the LMS with server-side code and web services. It made integration a product feature rather than a custom engagement. But the real shift came when industry standards matured. When content packaged in SCORM 1.2 (2001) or Common Cartridge could load anywhere, and when tools could launch via IMS LTI (first widely adopted around 2010), the ecosystem expanded beyond any one platform. Institutions gained choice because the interfaces held.

Think of rail gauges. You can build a locomotive in-house or buy one, but if the tracks don’t match the gauge, it won’t run the network. Education infrastructure is the track bed. Open standards set the gauge.

What infrastructure means here

We use “infrastructure” loosely in edtech, so let’s pin it to operations:

Identity and access: directory, SSO (SAML, OIDC), role/entitlement maps.
Student information system (SIS): course sections, enrollments, grades as system of record.
Learning management system (LMS): course shells, content, assignments, gradebook, APIs.
Content and tools: publisher materials, assessments, simulations, proctoring, video, discussion, early alert — often external SaaS.
Assessment systems: item banks, test delivery, scoring, outcomes.
Data plumbing: event streams, nightly batches, lakes/warehouses, reporting.
Governance: RFPs, security reviews, data sharing agreements, audit trails.

Each component has a job, but the work of the institution lives in the exchanges across them: provisioning accounts, rostering enrollments, granting tool access, passing grades back, and capturing event data. That is where cost and risk concentrate.

Two examples illustrate this concentration:

A mid-sized university migrates from one LMS to another. License costs may move a few percentage points, but most project hours and risks sit in integrations: SIS connectors, SSO, third-party tools, content import, and grade migration. If courses are packaged in SCORM/Common Cartridge and tools speak LTI, timelines compress; if not, teams build adapters and hope nothing critical was bespoke.
A large district adds a new math tool mid-year. The adoption fails not because the tool is bad, but because rosters never sync and SSO doesn’t pass entitlements. Teachers are told to wait “until the overnight” and students see the wrong classes. The district blames the vendor; the vendor blames the district. The real issue is the absence of a reliable contract between systems.

Infrastructure work is boundary work. Reliability emerges when boundaries are explicit, widely implemented, versioned, and testable. That is what standards do.

Two meanings of open

Open source and open standards are often blurred in conversation, but they answer different questions.

Open source answers: “May I use, study, modify, and distribute the code?” Its unit is a codebase under a license (MIT, Apache, GPL). Operationally, it changes procurement (license costs and rights) and staffing (skills to maintain and extend). Examples in edtech include Moodle and Sakai at the LMS layer, and a range of open projects around content and analytics.
Open standards answer: “Will my system speak a defined language other systems also speak?” Its unit is an interface contract — data models, protocols, and behaviors — defined in public, with conformance criteria and often certification. Operationally, it changes integration and ecosystem dynamics. Examples include SCORM and Common Cartridge for content packaging, IMS LTI for tool-to-platform launches and data flows, OneRoster for class rosters and grades exchange, Caliper for analytics events, and xAPI for experience statements.

Both approaches aim to reduce dependency risk and expand choice, but they work at different layers. Owning code does not guarantee another system will understand your data or participate in your workflows. Speaking a common protocol does.

In an infrastructure context — where multiple systems must interoperate across institutional and vendor boundaries — open standards carry more of the operational load. They set expectations, shrink idiosyncrasies, and let the institution mix suppliers without rebuilding.

A short formation history

Interoperability in education did not arrive as a single idea; it formed through stages — experiments, fragmentation, emergent patterns, and eventual consolidation around working interfaces.

Late 1990s: LMS formation. CourseInfo (1997) and Blackboard’s early platforms gave instructors web-based course hubs. WebCT and others formed an early, fragmented landscape. Integrations were mostly bespoke: CSV drops, directory hooks, custom scripts.
1999–2001: Content packaging. The ADL initiative delivered SCORM 1.2 (2001), making a practical contract for packaging e-learning content with runtime data exchange. In higher ed, IMS Global (now 1EdTech) drove Common Cartridge (later) to capture course structures across systems.
Early 2000s: Platform extensibility. Blackboard introduced Building Blocks — a framework that let third parties extend the LMS through documented APIs and server-side code. This was an important intermediate step: it made integration a supported product concern and created a partner marketplace, though extensions were still platform-specific.
2004: Blackboard IPO (NASDAQ: BBBB). Market maturity accelerated procurement rigor. RFPs began to ask not only “can you do this?” but “how does it integrate and do you conform to recognized standards?”
2008–2012: Tool interoperability. IMS LTI reached broad adoption (1.0/1.1 timeframe), allowing an external tool to launch from within an LMS, receive context (course, user role), and return results (Basic Outcomes). This made it practical for tool vendors to support multiple LMSs without writing separate connectors for each.
2013–2015: Data events and rostering. Tin Can API (xAPI) emerged (2013) for describing learning experiences; IMS Caliper 1.0 (2015) provided a higher-ed centric event model. OneRoster 1.0 (2015) standardized roster and grade exchanges between SIS and learning platforms, with 1.1 (2017) refining the spec and adoption.
2018–2019: Security lift. LTI Advantage (LTI 1.3 with services) standardized modern security (OAuth 2.0, OpenID Connect) and richer services (Assignments and Grade Services, Names and Roles), improving the auditability and security posture of tool integrations.

Across this span, something important happened: the center of value moved from platform features alone to the reliability of the network connecting platforms, content, and tools. With standard contracts in place, vendors and open-source projects could compete on usability, service, and focus, while institutions gained real power to assemble architectures that fit their needs.

Why standards beat source

The claim that open standards beat open source in education infrastructure is not philosophical. It is operational. Eight reasons show up repeatedly across implementations.

1) Interoperability is the binding constraint

Condition: Institutions run heterogeneous stacks — SIS from one vendor, LMS from another, with dozens of tools and content sources. Few can — or should — run a single-vendor campus.
Operational consequence: The costliest failures occur at system boundaries: rosters that misalign, grades that don’t post, SSO claims that omit entitlements. These are interface failures, not license failures.
System implication: A shared protocol across boundaries removes the most common points of breakage and reduces integration time from projects to configurations.
Significance: Standards improve reliability where it matters most and make multi-vendor architectures a safe default.

The risk lives at the interfaces.

2) Switching costs sit in integrations, not licenses

Condition: License swaps change budget lines but do not move data or workflows by themselves.
Operational consequence: Migration timelines hinge on content portability, tool continuity, and data export/import — the terrain owned by standards like SCORM, Common Cartridge, LTI, and OneRoster.
System implication: When contracts are standard, exit plans are credible; when they are bespoke, exit plans are fiction.
Significance: Institutions protect choice by buying to standards and asking for current conformance certificates before signing.

3) Ecosystems grow when suppliers can build once

Condition: Tool makers face fragmented LMS and SIS APIs.
Operational consequence: Without standards, vendors write and support multiple connectors; with LTI and OneRoster, they implement once and serve many.
System implication: More vendors enter; niche needs are served; pricing reflects wider addressable markets; institutions see faster innovation at the edge without swapping cores.
Significance: Standards catalyze healthy markets by raising the floor and widening the ceiling.

4) Governance, security, and audit depend on predictable flows

Condition: Security reviews and audits look for known protocols, well-scoped claims, and traceable actions.
Operational consequence: LTI 1.3’s use of OAuth 2.0 and OpenID Connect, and Caliper’s event semantics, fit existing security and logging disciplines. Custom adapters do not.
System implication: Review cycles shorten; incident response is clearer; the risk register shrinks.
Significance: Standards reduce institutional risk and speed procurement without cutting corners.

5) Reliability and performance follow versioned interfaces

Condition: Integrations degrade quietly when upstreams change fields, behaviors, or auth flows.
Operational consequence: Standard versions with deprecation schedules and conformance tests make changes explicit and testable.
System implication: Operations teams can stage upgrades, run test suites, and roll back with confidence.
Significance: Standards professionalize operations and reduce “Friday night surprises.”

6) Data portability is a right with a method

Condition: Institutions assert data rights in contracts; realization requires a format and a path.
Operational consequence: Standards provide the method: Common Cartridge for courses, OneRoster for enrollments and grades, Caliper/xAPI for events.
System implication: Archives are usable; research is reproducible; compliance requests are serviceable.
Significance: Standards turn rights into practice.

7) Public procurement needs vendor-neutral yardsticks

Condition: Districts and systems must buy at scale with clear, testable requirements.
Operational consequence: Requiring standards conformance reduces ambiguity and protest risk, and it widens competition to any supplier that meets the bar.
System implication: Budgets reach further; monopsony pressure is balanced by diverse suppliers.
Significance: Standards align market incentives with public outcomes.

8) Open source is a property of code; interoperation is a property of systems

Condition: A well-run open-source project can equal or exceed proprietary quality; a poorly governed one can falter.
Operational consequence: Regardless of license, the operational question remains: will it plug in? Standards answer that in a way licenses cannot.
System implication: Institutions can select open-source or commercial products freely, provided they conform to the same contracts.
Significance: Standards protect freedom of choice across license models.

Where open source wins

Open source does win — decisively — in several patterns. It simply wins for different reasons than infrastructure often demands.

Single-owner environments with strong internal teams. A university with a capable central IT organization can run and extend an open-source LMS (e.g., Moodle) effectively, tailoring features and controls to local needs. Here, the benefit is control and pace, not cross-vendor interoperation.
Commodity components. For infrastructure like logging stacks, ETL jobs, or visualization layers where standard protocols are already settled (e.g., SQL, Parquet, Kafka), open source can be efficient because the “interface” risk is low and the community is broad.
Research and prototyping. When exploring new pedagogy or analytics, open source accelerates iteration. If the project graduates into core infrastructure, the path to production should pass through standard interfaces so the result does not become an island.

The lesson is additive, not exclusive: favor open standards at the boundaries and choose open source or commercial code inside those boundaries based on capability, cost, and governance. Standards widen your options. They do not narrow them.

A short formation history, continued

To show how standards shift operations, watch three pivots in practice.

1) Content portability

Before: Course materials were often bound to the LMS that created them. Instructors rebuilding content during migrations consumed months.
After: SCORM 1.2 (2001) and later Common Cartridge gave a predictable package for moving content and basic assessments. Migrations compressed; publishers could distribute once.

2) Tool-to-platform contracts

Before: External tool vendors shipped separate connectors per LMS, each with bespoke quirks.
After: With LTI 1.0/1.1 (around 2010–2012) and later LTI 1.3 Advantage, a tool can launch securely from any conformant LMS, receive roles and context, and return grades. Vendors support a single connector; institutions scale adoption without custom work.

3) Rosters and analytics

Before: Districts used nightly CSVs with no consistent schema. Analytics stitched logs with guesswork.
After: OneRoster standardized roster and grade exchanges; Caliper (2015) and xAPI (2013) provided consistent event vocabularies. Data teams moved from reconciling mismatches to analyzing learning.

These pivots did not remove the need for platform features or quality open-source code. They shifted the center of gravity to the network contracts that let everything move together.

A reference architecture to buy

If you lead architecture or procurement, you can anchor decisions in a standards-first blueprint and reduce risk immediately.

1) Identity and security

SSO: Require SAML 2.0 and/or OpenID Connect for all user-facing systems.
Provisioning: Prefer SCIM 2.0 for account lifecycle where supported.
LTI 1.3 Advantage: Mandate for tool integrations; verify OAuth 2.0/OpenID Connect usage and services (Names and Roles, Assignments and Grade Services, Deep Linking) as applicable.

2) Rostering and grades

OneRoster: Require 1.1+ (or current) for class, enrollment, and grade exchange. Confirm supported endpoints (CSV and REST) and test with representative data before award.
SIS connectors: Ask for documented mappings and version alignment with the institution’s SIS release.

3) Content and assessments

Common Cartridge and/or Thin Common Cartridge: Require for course imports; specify media and assessment coverage needed.
SCORM 1.2 and/or SCORM 2004 (as needed): Especially for continuing education and workforce contexts.
QTI: Require for assessment item banks and test delivery where feasible.

4) Data and analytics

Caliper 1.x: Require for event streams with profile coverage aligned to your use cases (assessment, assignment, forum, media, etc.).
xAPI: Where learning extends beyond the LMS, specify xAPI endpoints and vocabulary alignment.
Exports: Include defined, scheduled exports for grades, enrollments, and course structures in documented schemas.

5) Operations and governance

Conformance: Demand current 1EdTech conformance certificates where available; include them as a condition of award and renewal.
Versioning: List accepted spec versions and deprecation timelines; require change notices 90 days before deprecation.
Exit plan: Specify the formats, APIs, and schedules by which you will extract content, rosters, and event data at contract end.
Testing: Fund conformance and integration testing as a project line item with clear pass/fail criteria.

This is how you “buy to the contract.” You are not buying features alone; you are buying behavior at the boundaries.

The rail gauge lesson

Railroads did not scale because one workshop built the best locomotive. They scaled when regions agreed on gauge, couplers, and signaling so trains could cross borders without unloading freight. Engineers still innovated on engines and cars, but the network’s capacity came from compatibility. Education infrastructure is the same. Institutions are the stations; SIS, LMS, and tools are the rolling stock; students and data are the freight. If the tracks match, the system moves.

The metaphor is not decoration; it maps to operations:

Gauge: OneRoster and LTI dimensions that must align for a tool to move from district to district or campus to campus.
Couplers: Auth and context — SAML/OIDC and LTI claims — that let cars connect securely and carry the right manifest (roles, sections, entitlements).
Signaling: Caliper/xAPI events that tell you where trains are, how fast they move, and where congestion builds.

Standards make the network legible. Once the network is legible, you can run it.

Procurement patterns that work

Even when you buy to standards, execution details determine outcomes. Four patterns show up in successful projects.

1) Treat integrations as product, not projects

Create a maintained catalog of integrations with owners, versions, and conformance status. Track changes. Run smoke tests after upstream releases. This turns glue into inventory and reduces single points of failure.

2) Negotiate on behavior, not promises

Do not accept “we plan to support LTI 1.3 next quarter.” Write acceptance criteria tied to published specs and public conformance. Link payment milestones to passing tests with your representative data.

3) Put security and data teams upstream

LTI 1.3/OIDC claims, OneRoster scopes, and Caliper event payloads have privacy and access control consequences. Have security review the scopes and payloads during selection, not at go-live.

4) Write the exit before the entry

Ask vendors to produce a dry-run export of content, rosters, and events in the specified formats during implementation. Confirm you can restore into a test environment. The best time to validate an exit path is before you need it.

These are governance disciplines. They are also how you realize the value of standards in practice.

Where standards need care

Standards are not magic. They require stewardship and clear-sighted use.

Version gaps: A vendor may support LTI 1.1 but not 1.3. Decide whether to stage adoption or require upgrades. Document the gap and the risk.
Profile choices: Caliper and xAPI offer profiles and vocabulary choices. Choose a small, high-value subset first and expand with purpose.
False equivalence: “Supports SCORM” can mean minimal runtime compliance. Specify scenarios and conformance tests that mirror your courses.
Overreach: Not every interaction needs a standard immediately. Use the rule of three: formalize when three or more systems must interoperate reliably on the same function.

Call the downsides, then rest on the gain: with standards, the integration work you do once pays dividends across your stack.

A note from the LMS trenches

In the early 2000s at Blackboard, we learned two complementary lessons. First, by shipping Building Blocks, we reduced friction for partners and customers who needed to extend the platform. Integration became a supported behavior, not a favor. Second, as LTI took hold around 2010 and beyond, we saw partners support multiple LMSs with one implementation. That widened the ecosystem for everyone — including competitors. The counterintuitive but consistent outcome: when interfaces standardize, the market grows and institutions benefit.

Blackboard’s IPO in 2004 (NASDAQ: BBBB) pulled procurement into the foreground. RFPs became longer and more precise. Many institutions began to add hard requirements for content portability and tool interoperability. The conversation matured from “can you integrate?” to “which standards, which versions, and what evidence?” That shift improved delivery and reduced operational risk.

The bet I’d make today

If I were advising a CIO, provost, or superintendent today, I would make one clear bet: build your education infrastructure around open standards at every boundary, then choose the best product — open source or commercial — inside those boundaries.

Start with a narrow, high-yield slice:

Identity: SAML and/or OIDC everywhere, with SCIM where possible.
Tools: LTI 1.3 Advantage as a gate for any new adoption.
Rostering: OneRoster 1.1+ as the only acceptable format and API for class and grade exchanges.
Data: Caliper for events with a focused profile; xAPI where learning extends beyond the LMS.
Content: Common Cartridge for course portability; SCORM when runtime tracking is needed.

Then operate like an infrastructure team:

Maintain a public (internal) standards registry: which systems, which versions, who owns them.
Fund conformance testing and version upgrades as an annual line item.
Write acceptance criteria in RFPs that map to published tests and require current certificates.
Review payloads and scopes for security and privacy upfront.
Rehearse exits. Export a sample term of courses, rosters, and events annually and restore them.

Do this, and you will see three effects:

Faster time to value for new tools because integrations become configuration, not projects.
Lower switching costs because content, tools, and data have defined exits.
Healthier vendor relationships because expectations are legible and testable.

Back to the rails: you can paint a locomotive any color you like and tune its engine to your terrain. What matters first is that the wheels meet the track at the right gauge and the signals are understood across the line. Open standards give you that. They protect your freedom to choose, today and when you change your mind later.

Why Open Standards Beat Open Source in Education