Reference Architecture: A MOOC / Open-Course Platform

Why This Matters

If you are scoping an open-course product — a university's public catalog, a professional-skills marketplace, a government reskilling program, a creator's open academy — you are commissioning something whose hardest problems are scale and economics, not wiring. A corporate learning system lives or dies on its integrations into the HR and identity systems it does not own; a MOOC lives or dies on whether its cost to serve a free learner stays below the revenue from the small fraction who convert. This article gives a founder, product lead, university digital-learning director, or L&D strategist the complete architectural map of an open-course platform, so you can brief engineers precisely, judge a vendor or an open-source stack against a real reference design, and understand where the money goes when enrolment is free and completion is rare. It is written for the non-engineer making the build-versus-adopt call, but it stays accurate enough for the platform architect and the video engineer who will build it.

First, the Three Facts That Organize Everything

A corporate learning system and a MOOC look almost identical in a demo: a catalog, a video player, a quiz, a certificate. As with every learning product, the resemblance hides the point. We covered the corporate case in the corporate-LMS reference architecture, where the whole design is shaped by integrations — the bridge to the HR system, to the video platform, to the compliance function. A MOOC is shaped by something else entirely. Three facts, none of which a corporate platform faces, drive every architectural choice.

The first fact is open enrolment at unpredictable scale. Nobody assigns a learner to a MOOC; the learner finds it and signs up, often in a sudden wave when a course is featured or goes viral. A corporate system knows it has 20,000 employees. A MOOC platform might have a course sit at a few hundred enrolments for months and then take fifty thousand in a week. The architecture has to absorb spikes it cannot predict, for an audience it never authenticated against an employer.

The second fact is the completion funnel — almost no one finishes. This is not a flaw to be fixed so much as a property to be designed around. Across the entire edX catalog from 2012 to 2018, only about 3 percent of registrants completed a course in the final year studied, and 52 percent of people who registered never even started, according to a 2019 analysis in Science (Reich and Ruipérez-Valiente). More recent studies put median completion in the 6 to 8 percent range depending on how you count. A MOOC platform is therefore a funnel by nature: a huge top, a tiny bottom, and every system — video, assessment, analytics — has to be sized for the top while the revenue comes from the bottom.

The third fact is free-to-enrol economics — almost no one pays. The content is free; learners pay only for something extra, usually a verified certificate, a subscription, or a credential that counts toward a degree. This is the freemium model the big platforms run: Coursera introduced paid Verified Certificates in 2013 and now reports more than 120 million registered learners against a far smaller paying base. The architecture must make serving the free majority cheap, because the paying minority — single-digit percentages of registrants — has to cover them and still leave a margin.

Hold those three facts in your head — open enrolment, a steep funnel, free content monetized at the edges — and the architecture below explains itself. A MOOC platform is best understood as six cooperating planes, each shaped by scale and the funnel rather than by integration.

The open enrolment and identity plane lets anyone register instantly and only verifies identity at the paid boundary, where a certificate is on the line. The content and video plane stores, encodes, and delivers learning media to a global audience as cheaply as possible — this is the main cost center. The learning experience plane is the course itself: the player, the modular content, the discussion community. The assessment and grading plane scores hundreds of thousands of submissions without a human in the loop wherever it can, and routes the rest to peers. The credentials and monetization plane turns completion into a verifiable certificate and turns a small fraction of learners into revenue. And the analytics plane measures the funnel so the platform can widen the bottom.

Figure 1. The full picture. A global, self-registering audience on the left flows through six planes. The orange plane is the cost center — content and video at scale; the green plane is where the money is made — credentials and the monetization funnel. Unlike a corporate system, there is no HR or compliance bridge; the shaping forces are scale and the funnel.

The Reference Platform: Why Open edX Is the Map

Before walking the planes, it helps to have a concrete reference. The most studied open-source MOOC platform is Open edX, the software that originally ran edX and now powers public course sites worldwide. It is worth knowing its shape because it is the clearest real example of the planes above, and because "build versus adopt" for a MOOC almost always means "build from scratch versus adopt Open edX versus run on a hosted platform."

Open edX is not one program. Its center is the platform that contains two applications: the LMS, which is the learner-facing experience — the dashboard, the courseware, the progress pages — and Studio, the course-authoring environment course teams use to build content. Around that center sit a collection of separate services the project calls independently deployed applications, plus a set of micro-frontends (small, separately built user-interface apps) for things like the discussion forum. The server code is mostly Python on the Django web framework; course structure lives in a document database (MongoDB), each learner's records live in a relational database (MySQL), background work like grading and email is handed to a task queue (Celery with Redis), and search runs on a dedicated search engine. Course content itself is built from a component model called XBlock, where each problem, video, or text block is a reusable unit.

You do not need to memorize that stack. The reason it matters is that it shows the planes are real: authoring is a distinct service from delivery; learner records are deliberately separated from course content; grading is asynchronous because it has to be; and the video is not stored in the core at all — it is pushed out to cloud storage and a content-delivery network, because serving video from your application servers at MOOC scale would bankrupt you. That last point is the whole next section.

Plane 1: Open Enrolment and Identity — There Is No HR Bridge

Start where every MOOC learner starts: they create their own account, in seconds, with an email address or a social login, and they are in. This is the exact opposite of the corporate case, where identity is delegated to the company's HR and identity systems and a learner never signs up at all. A MOOC owns its user list because there is no employer behind the learner — just a person, somewhere in the world, who clicked "enrol."

That openness creates two engineering jobs that a corporate system is spared. The first is absorbing registration spikes. Because enrolment is driven by marketing, press, and word of mouth, a course can take more sign-ups in a day than in the previous quarter. The registration path — account creation, email confirmation, enrolment record — has to be a lightweight, horizontally scalable service that can be given more capacity on short notice, ideally automatically. This is why MOOC platforms run stateless web tiers behind load balancers and push session and queue work to shared stores: any single server can handle any request, so you add servers to meet a spike and remove them after.

The second job is identity verification at the paid boundary, and only there. Most learners stay anonymous in any meaningful sense — a name and an email, never checked. But the moment a learner wants a verified certificate with their real name on it, the platform has to prove who they are, because the certificate's whole value is that an employer can trust it. Historically this meant a webcam photo against a photo-ID and a typing-pattern check; today it is usually a one-time identity-document verification through a third-party service. The crucial design point is that you do not verify everyone — you would pay an identity-check fee for millions of people who will never pay you. You verify at the funnel's paid edge, where the cost is justified by the revenue. Identity verification is a feature of the monetization plane as much as the identity plane.

Common mistake: building the corporate identity bridge you do not need. A team that has seen an enterprise LMS sometimes reaches for single sign-on, directory provisioning, and role hierarchies. A public MOOC needs almost none of that. It needs fast self-registration, social login, and a clean identity check at the certificate boundary. Spending the first sprint on SAML and SCIM — the standards that matter in the corporate reference architecture — is solving the previous product's problem.

Plane 2: Content and Video at Scale — The Cost Center

This is the plane that defines a MOOC's economics, because video is where the money goes out. Its job is to take learning media — recorded lectures, demonstrations, animations — and deliver it to a global, mostly non-paying audience at a cost low enough that the platform survives. Every serious architectural decision here is a cost decision.

Three steps sit between a raw recording and a learner's screen, and the same end-to-end pipeline is laid out in the anatomy of a learning-video platform. First, authoring and ingest: an instructor uploads a recording into the authoring system (Studio, in the Open edX world). Second, transcoding and packaging: the platform converts each video into several versions at different quality levels — a bitrate ladder, from a low-resolution stream for a phone on weak mobile data to a high-resolution one for a laptop on fibre — and packages them for adaptive streaming so the player can switch versions as the network changes. The specific codec and ladder choices belong to the Video Encoding section and are not re-derived here. Third, delivery through a content-delivery network (CDN): the packaged video is copied to a network of edge servers around the world so a learner in Jakarta streams from a nearby machine, not from your origin in Virginia.

The reason this plane is the cost center is the bill for that third step, called egress — the charge for data leaving the CDN to learners. Egress is metered per gigabyte, and at MOOC scale the gigabytes are enormous. The whole subject of controlling it — multi-CDN strategy, transcoding efficiency, storage tiering — is the scaling delivery article; here, the architectural point is simply that you never serve MOOC video from your own servers. You offload it to a CDN and you engineer the bill down. The worked arithmetic later in this article shows just how large that bill gets.

One scale-specific decision lives here that a small course never faces: how aggressively to use mobile-first and lower-bitrate delivery. A large share of MOOC learners worldwide are on phones and constrained networks. Designing the bitrate ladder so the default rung is modest — and so the player drops to audio-plus-slides on a poor connection — is not only an accessibility win, covered in learning video on weak networks; it directly lowers the egress bill, because most learners stream fewer gigabytes. At MOOC scale, the accessible choice and the cheap choice are the same choice.

Figure 2. The cost center. A recording is ingested once, transcoded into an adaptive bitrate ladder, packaged for streaming, and pushed to one or more CDNs that serve a global audience from the edge. The egress charge — data leaving the CDN, metered per gigabyte — is where a free-to-enrol platform spends most of its serving budget.

Plane 3: The Learning Experience — The Course Itself

Between identity and assessment sits the part learners actually use: the course player, the way content is structured into a path, and the discussion community around it. This is the LMS in the everyday sense, and on a MOOC it carries two distinctive design loads.

The first is the modular content model. A MOOC course is not one long video; it is a sequence of short units — a few minutes of video, a quick check-for-understanding, a reading, a discussion prompt — assembled into weeks or modules. This chunking is pedagogy, covered in the pedagogy of video article, but it is also architecture: each unit is a reusable component (an XBlock, in Open edX) that can be authored once, reordered, reused across courses, and — importantly — tracked individually. The component model is what lets a platform measure where in a lesson learners drop off, not just whether they finished.

The second load is community at scale. Discussion forums are a defining MOOC feature, because with one instructor and a hundred thousand learners, peers answering peers is the only support model that scales. Architecturally the forum is its own service — separately deployed, separately scaled — precisely because its load profile is different from the courseware's and you do not want a flood of forum activity to slow down video playback. Keeping the discussion system as an independent service is a recurring pattern in MOOC design, and it is exactly why Open edX runs its forum as a standalone component rather than baking it into the core.

A MOOC player also leans harder on mobile and offline than a corporate one, for the same reason the video plane does: the audience is global and often bandwidth-constrained. The ability to download a lesson on Wi-Fi and watch it later offline, detailed in offline and low-connectivity learning, is frequently the difference between a learner who continues and one who churns.

Plane 4: Assessment and Grading at Scale — The Hard Problem

Now the plane that most cleanly separates a MOOC from a small course: grading at a scale where no human can keep up. If five hundred learners submit an assignment in a corporate course, instructors cope. If five hundred thousand submit in a MOOC, every form of human grading collapses. The architecture's answer is a tiered one: automate what you can, distribute what you cannot, and verify only what you must.

The first tier is auto-graded assessment — questions a machine can score instantly and correctly. Multiple-choice, true/false, numeric-answer, and matching questions are the backbone, because a computer can check them against a key for any number of submissions at no marginal cost. For technical subjects, autograders go further: a programming assignment is scored by actually running the learner's code against a battery of tests in a sandbox, and a math answer is checked symbolically. Auto-grading is the only tier that genuinely scales to millions, so well-designed MOOCs lean on it as heavily as the subject allows.

The second tier is peer assessment, for the open-ended work a machine cannot judge — essays, designs, projects, proofs. Here the platform turns the scale problem into the solution: each learner grades several peers' submissions against a rubric the instructor wrote, and the platform aggregates those judgments into a score. Peer grading is imperfect — learners are inconsistent, and research shows it needs a well-designed rubric and several reviewers per submission to be fair — but it is the only way to assess creative work when the grader-to-learner ratio is one to a hundred thousand.

There is a real pitfall here that belongs in any honest reference design. Automated grading of open-ended work can be biased. In one widely cited study, an automated essay-scoring system used in an edX pharmacy course gave systematically lower scores to non-native English speakers. The lesson is not "never automate" but "know the limits": keep machine scoring to objective items, use it only as a first-pass filter for open-ended work with human or peer review on top, and test your graders for bias before trusting them. The deeper treatment of generating and checking assessments automatically lives in automatic quiz and assessment generation.

The third tier is external tools and proctoring at the paid boundary. Specialized assessment — a virtual lab, a coding environment, a proctored final exam — is usually a separate product plugged into the platform rather than built into it. The standard that makes this clean is LTI 1.3 (Learning Tools Interoperability), from the standards body 1EdTech. LTI 1.3 is not a password login: it uses an identity-protocol launch (OpenID Connect) carrying a signed token — a JSON Web Token (JWT) that names the learner, their role, and the course — so the platform vouches for the learner and the external tool trusts that signed message. Its companion service, Assignment and Grade Services (AGS), lets the tool push a score back into the platform's gradebook. As in the corporate architecture, describe LTI as "a signed launch into a trusted tool," never as "a login," or you will scope the integration wrong. Proctoring itself — its approaches, trade-offs, and privacy law — is its own subject in online proctoring; on a MOOC, you proctor only the paid, credit-bearing exams, because proctoring everyone would be both unaffordable and pointless.

Figure 3. Three tiers of grading. Objective questions and code autograders scale to millions at no marginal cost; peer assessment handles open-ended work the machine cannot judge; external tools and proctoring plug in over LTI 1.3 with grade passback, reserved for the paid, credit-bearing boundary. Automate what you can, distribute what you cannot, verify only what you must.

Plane 5: Credentials and the Monetization Funnel — Where the Money Is

Everything so far costs money to run and earns nothing. This plane is where a free-to-enrol platform actually makes revenue, and it is the one a corporate system, where the employer already pays, never needs. Its job is to turn a completed course into something a learner will pay for, and to turn a small fraction of learners into the income that funds everyone else.

The product at the center is the verified certificate — a credential, with the learner's verified identity on it, that an employer or institution can trust. The freemium split is precise: the course content is free to audit, and the learner pays only for the certificate (and the identity verification behind it). Coursera's first paid feature, in 2013, was exactly this, priced in the tens of dollars; the model has barely changed because it works. Above the single certificate sit higher tiers — subscriptions that bundle many courses, multi-course programs and professional certificates, and full online degrees where the platform takes a share of tuition. The "six tiers of MOOC monetization" framing — certificates, subscriptions, programs, degrees, enterprise, and sponsorships — is just a ladder of increasing price and commitment built on the same free base.

Two architectural requirements follow. First, the platform needs a payments and entitlements system: a way to take money globally, in many currencies, and to record that a given learner is now entitled to a certificate, a course, or a subscription tier. Entitlement is separate from enrolment — a learner can be enrolled (free) without being entitled (paid), and the player and certificate logic must respect the difference. Second, the credential itself should be verifiable and portable, which is where modern standards matter.

A certificate that is just a PDF is easy to forge and impossible to check at scale. The standards that fix this are Open Badges 3.0, from 1EdTech, and the W3C Verifiable Credentials Data Model, which Open Badges 3.0 is built on. A verifiable credential is cryptographically signed by the issuer, so anyone — an employer, another institution — can confirm it is genuine and unaltered without phoning the issuer, and the learner can carry it in a digital wallet. Open Badges 3.0 was finalized by 1EdTech in 2024, and the W3C Verifiable Credentials Data Model reached Recommendation status in 2025; both define a three-party model of issuer, holder, and verifier. The deeper treatment is in certificates, badges, and verifiable credentials; the architectural point is that on a platform whose entire revenue rests on the credibility of its credentials, tamper-evident, standards-based credentials are not a nicety — they are the product you are selling. Cite the version when you claim tamper-evidence: Open Badges 2.0 and 3.0 are different, and only the 3.0 / Verifiable Credentials line gives you the cryptographic guarantee.

Figure 4. The funnel that defines the business. Of everyone who registers, about half never start, and only single-digit percentages complete — yet the architecture must serve the whole top of the funnel. Revenue comes from the narrow paid boundary: verified certificates, subscriptions, programs, and degrees. The free base is a cost; the paying edge funds it.

Plane 6: Analytics at Scale — Measuring the Funnel

The final plane is the one that lets a MOOC improve, because on a platform defined by a steep funnel, the most valuable thing you can know is exactly where learners fall out. Its job is to capture every meaningful learner action, store it cheaply at enormous volume, and turn it into the handful of numbers that matter: where in a video attention drops, which assessment item sheds learners, what separates a completer from a quitter.

The data here is a firehose. Millions of learners generating play, pause, seek, answer, and post events produce billions of records, so the analytics plane is a streaming data pipeline, not a reporting feature bolted onto the LMS. Events are emitted by the player and the courseware, collected through a pipeline, and landed in a data warehouse or lake where they can be queried at scale. The standards that give those events a portable shape are the Experience API (xAPI), version 1.0.3, from ADL — the actor-verb-object "statement" model, written to a store called a Learning Record Store — and Caliper Analytics, from 1EdTech, a parallel standard built specifically for learning-analytics events at scale. For video specifically, the xAPI Video Profile gives play, pause, and seek a standard vocabulary, so "watched 70 percent, re-watched the proof" becomes structured data; tracking video without it is the most common reason a platform cannot answer real engagement questions, and it is covered in depth in tracking video with the xAPI Video Profile.

What you do with the firehose is the subject of the whole learning-analytics article and, for the single most important MOOC number, completion rate. The architectural point is that analytics on a MOOC is not an afterthought; it is the instrument panel for the funnel, and it has to be designed as a scalable pipeline from day one because retrofitting one onto billions of existing events is far harder than building it in.

Common mistake: "watched it all, so they learned it." Completing a video is not the same as completing a course, and neither is the same as learning. The xAPI Video Profile's "completed" verb means the video reached its end, not that the learner mastered anything. Define your completion and mastery rules deliberately — watched-threshold plus passed-assessment, for example — and measure them separately. Conflating watch-time with learning is the most common measurement error in open courses, and it starts in how you model events here.

Putting the Planes Together: How One Enrolment Runs

Walk a single learner through all six planes, because the choreography is the architecture. Priya, in Pune, sees a data-science course featured online and clicks enrol. The open enrolment plane creates her account in seconds with a social login — no employer, no verification yet. She opens week one; the content and video plane streams the first lecture to her phone from a nearby CDN edge, at a modest bitrate suited to her mobile connection, costing the platform a few cents of egress. The learning experience plane presents the lecture as a short unit followed by a quick check and a discussion thread where other learners answer her question, because no instructor could. She works through auto-graded quizzes that the assessment plane scores instantly, and a peer-reviewed project that three classmates grade against a rubric. As she goes, the analytics plane writes xAPI Video Profile and Caliper events to the warehouse — where she paused, which item she missed, that she re-watched the model section. She is in the engaged minority, and at the end she decides the certificate is worth it: the credentials and monetization plane verifies her identity once, takes her payment, and issues an Open Badges 3.0 verifiable certificate she can carry in a wallet and an employer can check cryptographically. Priya is one of the single-digit-percent who paid — and her certificate fee helps cover the thousands who audited the course for free.

That single walkthrough is the whole product. Every feature you will ever add — a new content type, a new credential, a new monetization tier — lands in one of those six planes.

The Cost Model of Free-to-Enrol Courses, Shown Out Loud

The MOOC question is rarely "build or buy" in the abstract; it is "can the paying edge cover the free base." Make it concrete with one popular course run, and show the math out loud.

The serving cost: video egress. Say a course run draws 100,000 registrations. The funnel applies immediately — about half never start, most who start watch little — so model 50,000 active viewers who each stream, on average, 3 hours of video. Pick an average delivered bitrate of 1.5 Mbps, which is realistic once most learners are on mobile and lower rungs of the ladder. First, gigabytes per viewing-hour:

1.5 Mbps × 3,600 s = 5,400 megabits = 675 megabytes ≈ 0.66 GB per hour

Then total egress for the run:

50,000 viewers × 3 hours × 0.66 GB = 99,000 GB ≈ 99 TB

Now the bill, and why the CDN choice is an architectural decision. At a major cloud CDN's blended rate around $0.06 per GB at this volume, that is 99,000 × $0.06 = $5,940. On a value CDN around $0.01 per GB, it is 99,000 × $0.01 = $990. On an aggressively priced CDN near $0.004 per GB, it is under $400. Same course, same learners — a fifteen-fold cost difference that comes entirely from delivery engineering. That is why multi-CDN strategy is a first-order concern at MOOC scale and barely matters for a small course.

The revenue: the paying edge. Suppose 3 percent of registrants buy a $49 verified certificate — a deliberately modest single-digit conversion:

100,000 registrants × 3% = 3,000 certificates
3,000 × $49 = $147,000

Against an egress bill between $400 and $6,000 (plus compute, storage, and identity-check fees), $147,000 in certificate revenue is what makes free-to-enrol viable. The lesson of the arithmetic is the architecture's whole thesis: drive the serving cost of the free majority down with delivery engineering, and engineer the funnel so the paying minority converts — get either wrong and the model collapses. The learning-platform cost model turns this into a full calculator, and the delivery-cost article goes deep on driving egress down.

Build, Adopt, or Run Hosted: The Realistic Decision

For a MOOC, "build versus buy" has three doors, not two, and most teams should not walk through the first one.

Build fully custom. Writing an open-course platform from scratch — registration at scale, a transcoding-and-CDN pipeline, an autograder, peer assessment, a credentialing and payments stack, an analytics firehose — is a multi-year, multi-million-dollar undertaking. It is justified only when the learning experience itself is your differentiator and no existing platform can express it, and when you have the engineering depth to run a platform at scale. For most teams, building all six planes from zero is the wrong door.

Adopt the open-source platform. Open edX exists precisely so you do not start from scratch. You get the LMS, the authoring studio, the component model, forums, and assessment out of the box, as open-source software you can host and customize. You still invest — hosting at scale, customization, the video pipeline, and operations are real work — but you build on the six planes instead of building them. For most serious open-course products, this is the default door: adopt Open edX (self-hosted or through a specialist provider) and spend your engineering on the video economics, the custom experience, and the integrations that differentiate you.

Run on a hosted platform. If you do not want to operate infrastructure at all, you publish onto an existing marketplace or a hosted course platform and accept its constraints and revenue share. You are fastest to launch and you own the least; the platform owns the learner relationship and takes a cut. This is the right door when reach matters more than control and you have no wish to run engineering.

Figure 5. The realistic decision. Build from scratch only if the experience is your differentiator and you can operate a platform at scale; adopt open-source Open edX for most serious open-course products and spend engineering on video economics and a custom experience; run on a hosted platform when reach matters more than control. Most teams should adopt, not build.

The Pitfalls That Define a Bad Build

"It's a course site with more users." The root error. A MOOC is shaped by scale spikes, a steep funnel, and free-to-enrol economics — none of which a small course faces. Design for the top of the funnel and monetize the bottom, or the model never closes.

"Serve the video from our servers." At MOOC scale, origin-served video is a bankrupting egress bill and a reliability risk. Offload to a CDN, engineer a sane bitrate ladder, and treat delivery cost as a first-order design constraint.

"Verify everyone's identity." You would pay an identity-check fee for millions who will never pay you. Verify only at the paid certificate boundary, where the revenue justifies the cost.

"Grade open-ended work with a machine and trust it." Automated essay scoring can be biased — it has measurably disadvantaged non-native speakers. Auto-grade objective items; use peers plus human review for open-ended work; test for bias.

"A PDF certificate is fine." A free-to-enrol platform sells trust. A forgeable PDF undermines the one thing learners pay for. Issue tamper-evident, standards-based credentials (Open Badges 3.0 / W3C Verifiable Credentials), and cite the version.

"We'll add analytics later." The funnel is the business, and analytics is its instrument panel. Retrofitting a pipeline onto billions of existing events is far harder than designing it in. Build the analytics plane from day one.

Comparing the Options Per Plane

The MOOC decision is not one decision; it is six, one per plane. The table makes the realistic options explicit, including the standards each plane should speak — and tooling and platform comparisons in this section always carry a standards-support column for exactly this reason.

Plane	Run hosted	Adopt Open edX + extend	Build custom	Standards it should speak
Open enrolment & identity	Platform owns it	Self-registration + social login + ID check at paid edge	Custom scalable auth	OIDC; ID-verification APIs
Content & video at scale	Platform's player/CDN	Own transcoding + multi-CDN behind it	Full custom pipeline	HLS/DASH; xAPI Video Profile
Learning experience	Platform's courseware	XBlock content + forums, themed	If experience is the product	LTI 1.3 (embed tools)
Assessment & grading	Platform's graders	Autograders + peer + LTI tools	Custom autograder/peer engine	LTI 1.3 + AGS; QTI
Credentials & monetization	Platform takes a cut	Own payments + verifiable credentials	Bespoke funnel + wallet	Open Badges 3.0; W3C VC
Analytics	Platform's dashboards	xAPI/Caliper pipeline to a warehouse	Custom event firehose	xAPI 1.0.3; Caliper

The pattern most successful open-course builds follow is the middle column: adopt the open-source platform, and spend your engineering on the video economics, the custom experience, and the credential and analytics planes — the parts that determine whether the funnel closes. A full custom build is justified only when the experience itself is the product and the scale pays back the investment; a hosted platform is right when reach beats control.

Where Fora Soft Fits In

Fora Soft has built video streaming, WebRTC, and e-learning systems since 2005, and an open-course platform sits at the intersection of those skills — a video layer that has to serve a global audience cheaply, wired into assessment, credentials, and an analytics pipeline sized for the funnel. The build-versus-adopt trade-off we help teams make is concrete and per-plane: a hosted platform or a customized Open edX deployment gets an open-course product live without rebuilding the planes, while a custom video-delivery pipeline, a standards-correct credential layer, and an analytics firehose are where a platform earns a margin against free enrolment. We work across e-learning, video streaming, OTT, conferencing, and telemedicine, so we are usually brought in when the video economics and the scale are the hard part — not the catalog. No hype: for the platform core the honest answer is often "adopt and extend Open edX," and we will say so, so the engineering you own is the part that actually decides whether the model works.

What to Read Next

• Scaling delivery: CDN, transcoding, and cost at volume
• Reference architecture: a corporate LMS with video
• Certificates, badges, and verifiable credentials

Call to action

• Talk to a e-learning engineer — book a 30-minute scoping call to talk through your learning management system development plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the MOOC / Open-Course Platform — Architecture Readiness Checklist — A one-page checklist across all six planes — open enrolment and scale, content and video at scale (egress economics), the learning experience, assessment and grading at scale, credentials and the monetization funnel, and analytics — to….

References

1. ADL. Experience API (xAPI) Specification, version 1.0.3 — Part 2: Statements; the actor-verb-object statement model and the Learning Record Store used for the analytics plane. https://github.com/adlnet/xAPI-Spec (Tier 1, primary standard). Accessed 2026-06-22.
2. ADL. xAPI Video Profile — the standard video-event vocabulary (played, paused, seeked, completed, time-watched) for tracking video interactions as xAPI statements at scale. https://adlnet.gov/projects/xapi-video-profile/ (Tier 1, primary standard). Accessed 2026-06-22.
3. 1EdTech (IMS Global). Learning Tools Interoperability (LTI) 1.3 and LTI Advantage — the OIDC launch, the signed JWT, and Assignment and Grade Services (AGS) used to embed external assessment, lab, and proctoring tools into the platform. https://www.imsglobal.org/spec/lti/v1p3/impl (Tier 1, primary standard). Accessed 2026-06-22.
4. 1EdTech (IMS Global). Open Badges 3.0 Implementation Guide — the verifiable-credential badge standard, aligned with the W3C Verifiable Credentials Data Model, for tamper-evident certificates; finalized 2024. https://www.imsglobal.org/spec/ob/v3p0/impl (Tier 1, primary standard). Accessed 2026-06-22.
5. W3C. Verifiable Credentials Data Model (VCDM) 2.0 — W3C Recommendation (2025); the issuer–holder–verifier model and cryptographic verifiability behind portable, tamper-evident credentials. https://www.w3.org/TR/vc-data-model-2.0/ (Tier 1, primary standard). Accessed 2026-06-22.
6. 1EdTech (IMS Global). Caliper Analytics — the learning-analytics interoperability standard (sensor API, events, and entities) built for capturing learning events at scale. https://www.imsglobal.org/activity/caliper (Tier 1, primary standard). Accessed 2026-06-22.
7. W3C. Web Content Accessibility Guidelines (WCAG) 2.1 — Level AA, Success Criteria 1.2.2 (Captions), 1.2.4 (Captions, Live), 1.2.5 (Audio Description) for an accessible global course catalog. https://www.w3.org/TR/WCAG21/ (Tier 1, primary standard). Accessed 2026-06-22.
8. Reich, J., & Ruipérez-Valiente, J. A. The MOOC pivot. Science, 363(6423), 130–131 (2019) — analysis of edX MOOC data 2012–2018: low and declining completion (about 3% of registrants in 2017–18) and that 52% of registrants never started. https://www.science.org/doi/10.1126/science.aav7958 (Tier 5, peer-reviewed). Accessed 2026-06-22.
9. Open edX (Axim Collaborative). Open edX Platform Architecture — Developer Documentation — the LMS and Studio applications, independently deployed applications and micro-frontends, the XBlock component model, and the separation of course content, learner records, and video/CDN delivery. https://docs.openedx.org/en/latest/developers/references/developer_guide/architecture.html (Tier 4, first-party engineering). Accessed 2026-06-22.
10. Class Central. Six Tiers of MOOC Monetization — the freemium ladder from verified certificates through subscriptions, programs, degrees, and enterprise that funds free enrolment. https://www.classcentral.com/report/six-tiers-mooc-monetization/ (Tier 6, educational/industry). Accessed 2026-06-22.
11. Amazon CloudFront. Pricing — per-GB egress rates and volume tiers used in the worked delivery-cost arithmetic for a course run. https://aws.amazon.com/cloudfront/pricing/ (Tier 4, first-party engineering). Accessed 2026-06-22.

Where sources disagreed, the official standard won. Vendor descriptions of LTI as "a login" and of a certificate as "a PDF" were overridden by the 1EdTech LTI 1.3 spec (an OIDC launch with a signed JWT) and the Open Badges 3.0 / W3C Verifiable Credentials Data Model (a cryptographically signed, verifiable credential), respectively. The completion figures are from the 2019 Science analysis of edX data and more recent studies (median ~6–8%); the cost arithmetic ($0.004–$0.06/GB egress; ~3% certificate conversion; $49 certificate) is illustrative 2026 ranges synthesized from current CDN pricing and published MOOC monetization data — confirm against live vendor quotes and your own funnel before budgeting.