Learning Content as Code#
Building a Libre Open-Source e-Learning Authoring Toolchain
Most people have taken an online course at some point, maybe a workplace training, a coding bootcamp, or a university module. Behind the scenes, those courses are usually built with specialized software platforms. They often come with drag‑and‑drop editors, proprietary formats, and limited ways to move your content elsewhere. If you switch platforms, you often have to rebuild everything from scratch.
That’s frustrating not just for developers, but for anyone who values openness and portability. Imagine if course content could be created the same way we write blogs or documentation: in simple text files, easy to share, version, and remix. Imagine if interactive quizzes or videos could be added without locking you into a single vendor. And imagine if learner progress could be tracked in a standard way, so analytics weren’t tied to one company’s dashboard.
This isn’t just a thought experiment for me… I work as a consultant at a German IT-consultancy firm, in a team focused on App Modernization and Cloud Migration. Almost a year ago, I was tasked with creating a cloud migration bootcamp to onboard colleagues quickly. We started with a Word document… “Easy” for collaboration, but painful for versioning and extensibility. I suggested switching to a static site generator, because it gave us the same benefits developers enjoy in Git workflows: branching, reviewing, reproducibility, and CI/CD integration.
Why Git workflows matter here
With Git, every change to course content is tracked. You can roll back mistakes, review contributions, and branch off experiments. It’s the same discipline developers use for code, applied to learning content. This makes collaboration transparent and scalable.
I built a theme for the static site that matched the corporate identity of our existing SCORM courses. Management loved the look, even if they didn’t fully grasp the technology gap between a static site and a SCORM package. My team lead went further: he made it part of my development plan for 2026 to extend the bootcamp not just with more content, but with features like quizzes and badges.
That aligned perfectly with my own plan: integrate the bootcamp into the company’s learning management system. The most efficient way forward is to develop these features privately, open‑source them, and then reuse them internally. That way, I can offer my company a product that I continue to evolve, potentially even rivaling commercial e‑learning authoring suites with a developer‑centric alternative.
Beyond the immediate surplus value for my company, I’m also thinking about how this approach could become commercially viable. The key isn’t to abandon the developer‑friendly workflow (Git, Sphinx, open standards, etc.), but to layer a visual editor on top, much like Gutenberg did for WordPress. That way, instructional designers or non‑technical colleagues can author content through blocks and drag‑and‑drop, while the underlying system remains transparent, versioned, and portable.
Gutenberg‑style editor
Gutenberg transformed WordPress by introducing a block‑based editor. Each piece of content, text, image, embed, became a block that could be rearranged visually. The same idea applied to e‑learning would let non‑developers build courses without touching code, while still preserving the developer‑friendly workflow underneath. Any action in the visual editor will be translated into action a developer would take upon a text file.
Competitively, this matters because most commercial e‑learning suites are designer‑centric GUIs: convenient, but closed and hard to integrate. By contrast, my approach keeps the open, developer‑friendly workflow under the hood (Git, Sphinx, xAPI), while adding a visual editor on top. That way, instructional designers can work comfortably, but developers still retain transparency, portability, and version control. It’s not “I built something, let’s monetize it”, but a deliberate strategy: build an open foundation, then add a commercial layer that solves a real gap in the market.
The business angle
Beyond the technical vision, it’s worth stressing that this isn’t a small market. Commercial e‑learning authoring frameworks often charge license fees upwards of $1,200 per seat per year. For large organizations, that adds up quickly and it creates a barrier for smaller teams, schools, or nonprofits who simply can’t afford those tools.
By keeping the developer‑friendly workflow open‑source and layering a visual editor on top, there’s potential to offer a more accessible pricing model. That could be a genuine game‑changer: lowering costs while still delivering professional‑grade authoring features, and opening the door for more people to create and share learning content.
Talking through the Idea#
When I first started sketching this workflow, the question wasn’t “how do I build another LMS?”, it was “how do I keep course authoring as close to software development as possible?” That led me straight to Sphinx. It’s flat‑file, version‑controlled, and reproducible. In other words, it already feels like code.
Sphinx
Originally built for Python documentation, Sphinx is a static site generator that takes Markdown or ReST files and produces HTML, PDF, or ePub. Developers love it because it’s deterministic, integrates with Git, and supports extensions.
But static documentation alone isn’t enough for learning. Learners need interactivity: quizzes, drag‑and‑drop, hotspots, videos with embedded questions. That’s where H5P comes in. It’s open, reusable, and doesn’t lock you into a proprietary editor.
H5P (HTML5 Package)
H5P is a library of interactive content types: Think quizzes, interactive videos, drag‑and‑drop exercises, all defined in JSON and rendered client‑side. You can self‑host H5P.org components or use H5P.com’s SaaS integration.
Embedding H5P components into Sphinx pages means you can keep your content in Markdown or ReST, while still offering rich experiences.
The next piece is analytics. Standards like ISO/IEC/IEEE 39274 are locked behind paywalls, but the xAPI specification (xAPI-Spec) is open and practical. it lets you describe learner actions in json and send them to any learning record store.
xAPI (Experience API)
xapi is an open specification for tracking learning experiences. each event is a json statement with an actor (who did it), verb (what they did), and object (what they did it to). example: “alice completed quiz 1.”
the challenge is plumbing: do you send statements directly from the browser, or do you add a proxy layer? at first, i leaned toward a server proxy. but then i realized: why not keep it client‑side? a lightweight js module can capture h5p events, normalize them into xapi, and store them locally. that way it works offline, and later syncs to a cloud LRS when connectivity is available.
Learning Record Store (LRS)
an LRS is a database designed to receive and store xAPI statements. think of it as the analytics backend for learning. popular open‑source options include learning locker and lrsql; saas options include yet analytics and lrs.io.
it’s a bit like git: you commit locally, then push upstream when you’re ready. this keeps the workflow developer‑friendly and portable.
Of course, there are trade‑offs with a client-based LRS proxy: Credential management in the browser is tricky and sync conflicts need idempotency… Maybe a “poor‑man’s merkle tree” to hash statements and reconcile them later could help with this? I’ll see… But the upside is huge: you preserve sphinx’s static nature, avoid LMS lock‑in, and give developers a toolchain that feels natural.
That’s the heart of the idea:
author in text,
enrich with open components,
track with portable telemetry.
No monolithic LMS,
no proprietary formats.
Just a libre e-learning authoring stack that treats learning content like code.
Competitor landscape#
The e‑learning authoring tools market is sizeable, valued at around $704 million in 2024 and projected to grow to $1.29 billion by 2033 at a compound annual growth rate (CAGR) of about 7% [1]. This growth is driven by enterprises and educational institutions investing in digital learning. But the competitive landscape is dominated by designer‑centric suites with high license costs.
Here’s a brief overview of the current competitive landscape:
Docebo Creator: Polished SaaS, but content is locked in. You can’t export source, so leaving means rebuilding.
iSpring Suite, Articulate 360, Adobe Captivate: Mature GUIs that export SCORM/xAPI packages. Better portability than pure SaaS, but workflows revolve around binary packages. Git diffs and CI/CD integration are painful.
H5P.org provides open components you can self‑host, ideal for Sphinx integration.
H5P.com offers SaaS integration with LMSs. Convenient, but pulls you back toward platform dependency.
SCORM vs xAPI
SCORM is the older standard for packaging courses into LMSs. It’s rigid and LMS‑centric. xAPI is newer, JSON‑based, and flexible. It can track learning outside an LMS, like mobile apps or simulations.
Open LRS options: Learning Locker, LRSQL, Yet Analytics, LRS.io, ClueLabs. All useful for testing xAPI statements and verifying interoperability.
Where I Differ#
Most of these competitors are built for instructional designers, not developers. They rely on GUIs, binary packages, and expensive licenses, often $1,200+ per seat annually. That’s big money, and it keeps the market concentrated among large enterprises.
My differentiator is that I’m not approaching this primarily as a commercial venture. I’m building it because it’s part of my development plan at my company: extending our cloud migration bootcamp with quizzes, badges, and LMS integration. Of course, career growth is a nice motivator. If this lands well, it might be the kind of project that earns me more than just kudos in the next performance review.
Because I’m not under pressure to “milk” a product or slap on an “AI” badge just to look feature‑complete, I can focus on building a developer‑friendly, open‑source foundation. Later, layering a Gutenberg‑style editor on top makes it accessible to non‑technical colleagues, while keeping the Git + Sphinx workflow intact.
That’s a deliberate strategy:
solve my company’s needs
open‑source the technical features
only then consider commercial viability, with lower pricing that could democratize access to professional authoring tools
Architecture sketch#
Think of the system as a pipeline with five main stages:
Authoring
Build
Runtime
Analytics
Sync
Each stage has a distinct role, but together they form a coherent developer‑friendly toolchain.
2. Build#
A Sphinx extension processes directives that embed H5P components.
The build step injects necessary assets (JS, CSS) and prepares xAPI hooks.
Output is a static site: fast, reproducible, and deployable anywhere.
Static builds
Static sites don’t need complex servers. They can be hosted cheaply on GitHub Pages, Netlify, or internal infrastructure, while still delivering rich interactivity. They also are packageable nicely for learning management systems
3. Runtime#
Learners open the static site in their browser.
H5P client renders interactive components (quizzes, videos, drag‑and‑drop).
A lightweight xAPI client listens for events and emits statements.
4. Analytics#
xAPI statements describe learner actions: actor, verb, object.
These are sent to a Learning Record Store (LRS), which acts as the analytics backend.
Dashboards and exports can then be built on top of the LRS.
5. Sync (Offline‑first)#
The xAPI client can queue statements locally when offline.
Later, it syncs to the LRS, ensuring no data is lost.
Idempotency is handled via hashing (a “poor‑man’s Merkle tree”), so duplicates don’t pollute the record.
Offline‑first design
Learners aren’t always online. By queuing events locally, the system works anywhere: on a train, in a workshop, or behind a firewall and syncs later.
Roadmap#
MVP:
Sphinx directive for embedding H5P.
Basic xAPI client sending initialized, answered, completed.
Configurable endpoint/auth in conf.py.
Stabilization:
Asset pipeline with fingerprinting and caching.
Event adapters for common H5P types.
Testing against at least one open LRS.
Developer ergonomics:
Single‑page rebuilds.
Hot‑reload dev server.
Linting for directive IDs and xAPI schema.
Middleware editor (commercial layer):
Gutenberg‑style block editor that writes clean ReST/Markdown.
Visual config for H5P blocks.
xAPI mapping UI for verbs and results.
Production hardening:
Optional proxy service for secure credential handling.
Observability: retries, health checks, logs.
Governance: contribution guidelines and extension APIs.
Conclusion#
The vision is clear: a developer‑first, libre toolchain for e‑learning. Sphinx provides the authoring foundation, H5P adds interactivity, and xAPI ensures portable analytics. By keeping the proxy client‑side and offline‑first, we preserve Sphinx’s static nature while still syncing to a canonical LRS. Competitors may offer polished GUIs, but they come with lock‑in. This approach keeps content open, workflows developer‑friendly, and analytics portable.
Comments
Feel free to leave a public comment on my Learning Content as Code blog post.
Before you comment...
In order to comment, you need to authenticate yourself with a
valid e-mail address. The e-mail address will not be publicly displayed, or
shared with anyone, as I (Tiara) also operate the commenting service on my
own server, on which your e-mail address is securely stored.
Choose your
username in accordance with your privacy expectations.