Es ist die naheliegende Idee: Man hat eine Vision für ein besseres LMS, Moodle ist Open Source, also forkt man Moodle, baut die UX neu, ändert das Datenmodell, wo es zwickt, und nennt das Ergebnis ein eigenes Produkt. Das passiert seit fast zwanzig Jahren regelmäßig, und es endet fast immer auf eine von zwei Arten: Der Fork verwaist, oder er wird zum Vollzeit-Job, der kein Geld mehr für Innovation lässt.
Dieser Post erklärt, warum LernHive konsequent auf reinem Moodle 5.x ohne Fork aufsetzt — und warum diese Entscheidung kein Verzicht ist, sondern strukturelle Stärke. Adressat sind technische Käufer (CTOs, Lead-Architekten, Entwickler), die in der Vergabeprüfung verstehen wollen, was hinter dem „kein Fork"-Statement im Pflichtenheft-Antwort tatsächlich steckt.
## Die Versuchung des Fork
Ein Fork klingt nach Freiheit. Endlich kein Workaround mehr für das Moodle-Datenmodell, endlich eine UI ohne historische Altlasten, endlich Codebase-Kontrolle ohne Diskussion mit Trustworthy-Source-Maintainern. In den ersten sechs Monaten ist das auch tatsächlich befreiend — Sprint-Velocity steigt, Features lassen sich an einem Wochenende einbauen, das Produkt fühlt sich nach „uns" an.
Drei Probleme melden sich danach:
**Erstens, der Update-Fork-Drift.** Moodle veröffentlicht alle sechs Monate einen Major-Release plus laufend Security-Patches. Im Fork muss jeder Release manuell mergen — und mit jedem Sprint, der eigene Änderungen ins Datenmodell oder in Core-APIs einführt, werden Merges schwieriger. Nach 18 Monaten haben Forks typischerweise 200+ offene Merge-Konflikte pro Major-Release. Die Wahl wird: Security-Patches schnell einspielen oder eigene Features behalten — beides geht nicht.
**Zweitens, der Plugin-Marktplatz-Cut.** Moodle hat über 2.500 von der Community gepflegte Plugins. Die meisten verlassen sich auf konkrete Core-APIs. Ein Fork, der diese APIs anders interpretiert, erbt ein hartes Wartungs-Problem: jedes Community-Plugin muss vor dem Einsatz manuell geprüft werden, oft auch gepatcht. Das Versprechen „wir haben einen Marktplatz" wird zur Lebenslüge.
**Drittens, der Vendor-Lock-in für Mandanten.** Wer eine Lernplattform für Behörden oder größere Unternehmen anbietet, wird in jedem Bieter-Workshop gefragt: „Was passiert, wenn wir den Vertrag kündigen?" Bei einem Fork ist die ehrliche Antwort: „Sie können uns nicht mehr verlassen, ohne ein Migrationsprojekt zu starten." Das ist kommerziell verlockend für den Anbieter, aber es macht den Vertrieb in regulierten Märkten zur Hölle — Vergabestellen lassen sich auf Lock-in nicht ein.
## Was historisch passiert ist — drei Beispiele aus 20 Jahren LMS
Wer den Fork-Reflex hat, sollte sich drei Vorgänger anschauen.
**ATutor** war Anfang der 2000er-Jahre eine ambitionierte LMS-Alternative mit eigenem Ansatz. Eigene Codebase, eigene Roadmap, akademisch fundiert. Letzter Release: 2019. Heute praktisch verwaist.
**Sakai vs. Moodle** ist kein Fork-Beispiel, aber lehrreich: Sakai entstand in Konkurrenz, gemeinsam getragen von US-Universitäten. Es existiert noch, hat aber im internationalen Markt verloren — weil Moodle dank Plugin-Ökosystem schneller iteriert hat. Sakais Fokus auf Feature-Vollständigkeit aus einer Hand wurde zum Klotz am Bein.
**Totara** ist der instruktivste Fall. Totara forkte 2010 von Moodle, mit klarem Fokus auf Corporate L&D. Erstmal sehr erfolgreich — Funktionen wie Learning Plans und Compliance-Reporting waren früh besser als bei Moodle. Doch Totara hat nach einigen Jahren den Fork-Status ernsthaft verteidigen müssen: Maintenance des eigenen Cores band Ressourcen, die für Innovation fehlten. Heute ist Totara als Produkt etabliert, hat aber Marktanteile an einfachere SaaS-Konkurrenten (Docebo, 360Learning) verloren — die ohne Moodle-Erbe schneller bauen können.
Das Muster: Forks gewinnen früh, verlieren spät. Die Wartungs-Last wächst kompoundend, während die Innovations-Kapazität konstant bleibt.
## Die fünf Kosten eines Forks, die niemand kalkuliert
Wenn ein Hersteller intern entscheidet, ob geforkt wird oder nicht, werden meist nur zwei Kosten gegen den erwarteten Mehrwert gerechnet: Initiale Migrations-Arbeit und laufende Update-Merges. Tatsächlich kommen mindestens fünf Kosten:
1. **Update-Merge-Tax.** Pro Moodle-Major-Release typischerweise 3–6 Personenwochen Merge-Arbeit. Bei 2 Releases/Jahr × 5 Jahre = 30–60 Personenwochen oder 1–2 Vollzeit-Jahre. 2. **Security-Patch-Lag.** Critical Security Patches müssen sofort eingespielt werden. Im Fork bedeutet das: Drop everything, merge, test, deploy — typischerweise 2–5 Tage Verzug nach Moodle-Veröffentlichung. In dieser Zeit ist die Plattform nachweislich verwundbar; Vergabestellen prüfen das im Audit. 3. **Plugin-Marketplace-Cut.** Jedes von Moodle-Community gepflegte Plugin, das im Fork verwendet werden soll, wird zum eigenen Wartungs-Posten. Faustregel: 20% aller Plugins funktionieren ohne Anpassung, 50% mit kleinen Patches, 30% gar nicht. 4. **Recruiting-Friction.** Moodle-Entwickler gibt es in der Community. „Forked-Moodle-Anbieter X"-Entwickler nicht. Onboarding-Zeit für neue Engineers verdoppelt sich. 5. **Exit-Cost-Ehrlichkeit.** Vergabestellen, die ernsthaft fragen, wollen einen schriftlichen Migrationspfad zurück nach Vanilla-Moodle. Bei einem Fork ist der ehrlich nicht lieferbar — das verliert Tender, die hart auf Lock-in-Vermeidung achten (Bund, EU-Institutionen, große Konzerne).
Die Summe dieser Kosten kann ein Fork-Produkt jahrelang tragen. Aber sie wirkt strukturell — sie schmälert die Margen in einem Geschäft, in dem Margen ohnehin nicht groß sind.
## Lernhives Architektur-Antwort: Plugin-Layer auf Vanilla Moodle
LernHive verfolgt explizit das gegenteilige Modell. Moodle 5.x bleibt unverändert — keine Core-Patches, kein verändertes Datenmodell, kein eigener Build-Prozess. Stattdessen liefert LernHive eine **Schicht eigenständiger Plugins**, die alle ohne Code-Änderung am Moodle-Core auskommen. Konkret: 21 Plugins (Stand 2026-04, [siehe Plugin-Map](../plugin-platform.html)), darunter [`local_lernhive`](../plugin-platform.html) als Foundation, [`theme_lernhive`](../plugin-theme.html) als visuelle Identität, plus 19 funktionale Plugins.
Architektonisch funktioniert das, weil Moodle genau dafür gebaut ist: APIs für Aktivitäten, Themes, Auth-Provider, Reports, Hooks. LernHive nutzt diese APIs konsequent statt sie zu umgehen. Das hat Konsequenzen — wir müssen z. B. teilweise mit Designentscheidungen leben, die wir anders getroffen hätten — aber es liefert dafür Eigenschaften, die ein Fork strukturell nicht haben kann.
Die wichtigsten:
- **Update-Pfad ist offen.** Wir testen jeden neuen Moodle-Release auf einer Demo-Instanz, nicht in einem Merge-Konflikt-Sumpf. - **Community-Plugins funktionieren.** Wenn ein Mandant zusätzlich z. B. das `mod_bigbluebuttonbn`-Plugin will, kann es eingespielt werden, ohne dass wir es selbst pflegen müssen. - **Mandanten können theoretisch zu Vanilla-Moodle migrieren.** Die LernHive-Plugins lassen sich deinstallieren, was bleibt ist standardisierte Moodle-Daten. Das ist ein Argument, das in Vergabeworkshops zieht. - **Security-Patches kommen sofort an.** Was Moodle veröffentlicht, deployen wir in 24 h auf alle Mandanten — kein Merge-Schritt dazwischen.
## Was wir trotzdem differenzieren — und warum das reicht
Der häufige Einwand: „Aber wenn ihr nur Plugins macht, was ist dann anders an LernHive?" Die Antwort ist, dass Plugins viel weiter reichen, als die meisten denken — wenn man die Architektur sauber zieht. Vier Beispiele aus dem LernHive-Stack:
**Audience.** Statt Moodle-Cohorts zu erweitern, baut [`local_lernhive_audience`](../plugin-audience.html) eine Regel-Tree-Schicht obendrauf. Statische und dynamische Cohorts mit AND/OR-Logik, zeit-, aktivitäts- und profil-basierten Regeln, Live-Preview. Die Audience-Definitionen werden in Moodle-Cohorts projiziert — also kompatibel mit allem, was Moodle bereits unterstützt. Ein Fork würde versucht sein, das Cohort-Modell direkt zu erweitern; das Plugin geht den langweiligeren, robusteren Weg.
**Pathways.** [`local_lernhive_pathways`](../plugin-pathways.html) liefert sequenzbasierte Curricula mit Voraussetzungen, Fälligkeiten und Sichtbarkeitsfenstern. Moodle hat Learning Plans (kompetenzzentriert), nicht Pathways (sequenzzentriert). Statt das Learning-Plan-Modell aufzubohren, baut Pathways ein eigenes Datenmodell, das parallel läuft. Mandanten können beides nutzen.
**Theme + Plugin-Shell-CSS-Contract.** Hier wird die Architektur am sichtbarsten. Statt jedes LernHive-Plugin direkt vom Theme abhängig zu machen, definiert `local_lernhive` ein CSS-Klassen-Contract (`.lh-plugin-*`, `.lh-btn-*`, `.lh-icon-*`). Plugins rendern gegen dieses Contract; das Theme kann CSS-Variablen für Markenidentität setzen, aber ein anderes Moodle-Theme würde die Plugins ebenfalls rendern (in Default-Optik). Mehr dazu in der [ADR-P03 zur Plugin-Theme-Decoupling](../strategy.html#architecture).
**Flavours.** Statt zwei Editions („LernHive Schule" vs. „LernHive Corporate") als verschiedene Code-Pfade zu pflegen, sind [Flavours](../glossar/flavour.html) Konfigurations-Presets über demselben Code. School-Flavour aktiviert klassische LMS-UX, LXP-Flavour aktiviert Discovery + Follow + Snacks. Ein Mandant wechselt durch Konfigurationsänderung — kein Migrationsprojekt.
Diese vier Beispiele zeigen das Muster: LernHive-Differenzierung passiert in der Schicht über Moodle, nicht durch Veränderung des Cores. Das ist enger gefasst als Fork-Freiheit, aber es ist nachhaltig.
## Was Mandanten daraus mitnehmen
In Vergabe-Antworten lässt sich die No-Fork-Architektur sauber kommunizieren:
- **Update-Stabilität.** Plattform folgt Moodle-LTS-Zyklus, Security-Patches innerhalb 24 h. - **Plugin-Kompatibilität.** Ergänzungs-Plugins aus Moodle-Community sind nutzbar. - **Exit-Pfad dokumentiert.** Bei Vertragsende übernimmt der Mandant Vanilla-Moodle plus Daten-Export — keine eingebrannte Lock-in-Logik. - **Engineering-Verfügbarkeit.** Moodle-Entwickler-Markt steht offen; Onboarding für neue Engineers ist nicht produktspezifisch.
Diese vier Punkte sind in B2B- und Behörden-Tendern oft unterschätzte Bewertungs-Dimensionen — sie tauchen unter „Total Cost of Ownership" oder „Lieferanten-Unabhängigkeit" auf und können in der Punkte-Bewertung mehr Einfluss haben als Feature-Listen.
## Wann ein Fork sinnvoll wäre — und warum das für uns nicht gilt
Es gibt Szenarien, in denen ein Fork die richtige Wahl ist. Wenn das gewünschte Produkt **fundamental** anders sein soll als der Open-Source-Vorläufer — etwa ein LMS, das ein komplett anderes Datenmodell für Lernpfade braucht, das Moodle's Activity-Konzept nicht reproduzieren will — dann ist ein Fork ehrlicher als der Versuch, das mit Plugins zu hacken. Auch dann, wenn ein Hersteller über zwei Jahrzehnte Engineering-Kapazität verfügt und die Maintenance-Kosten als Investition in vollständige Kontrolle akzeptiert.
LernHive will weder das eine noch das andere. Wir wollen **die Moodle-Foundation sichtbar besser zugänglich machen** — durch UX, durch Flavours, durch zusätzliche Bausteine. Das geht ohne Fork. Es würde sogar mit Fork schlechter gehen, weil wir dann den Moodle-Marktplatz nicht mehr nutzen könnten und uns selbst zur kleinen Insel machen würden.
Die ehrlichste Formulierung dessen ist eine Selbstbeschränkung, die wir in [`AGENTS.md`](https://www.lernhive.de/strategy.html) dauerhaft fixiert haben: „No Moodle fork. Moodle remains the technical core. Do not redesign the product as a replacement for Moodle." Wer auch immer in zwei Jahren bei LernHive arbeitet — diese Regel bleibt.
## Zusammenfassung
LernHive forkt Moodle nicht, weil:
- Die Wartungs-Kosten eines Forks linear wachsen, während Innovations-Kapazität konstant bleibt. - Der Plugin-Marketplace nur ohne Fork voll nutzbar ist. - Vergabestellen aktiv nach Lock-in-Vermeidung fragen — und nur Vanilla-Moodle einen sauberen Exit-Pfad liefert. - Die Differenzierung, die LernHive will (UX, Flavours, zusätzliche Bausteine), ohne Fork erreichbar ist.
Diese Architektur-Entscheidung kostet uns punktuelle Freiheit (manche Designs, die wir gern hätten, bleiben unmöglich), liefert aber strukturelle Stabilität, die in Vergabe-Verfahren zunehmend honoriert wird. Wer in den nächsten Jahren ein LMS für deutsche Behörden, EU-Institutionen oder größere Konzerne ausschreibt, sollte das No-Fork-Statement nicht als Marketing-Phrase, sondern als prüfbare Eigenschaft verstehen — und entsprechend im Pflichtenheft eine Erklärung des Update-Pfads, des Security-Patch-Verfahrens und der Plugin-Kompatibilitäts-Liste verlangen.
Mehr dazu, wie LernHive konkrete Architektur-Entscheidungen trifft, in den [ADRs](https://github.com/eledia/lernhive) (geplant für H2 2026 öffentlich) und in zukünftigen Posts dieser Säule.