Interne Strategie · lebendes Dokument

Wo LernHive steht — und wohin es geht.

Diese Seite fasst Vision, Prinzipien, Architektur und Preismodell in einer technisch-strategischen Lesart zusammen. Sie ist bewusst nüchterner als die Landingpage und dient der internen Abstimmung sowie Partner-Briefings.

Vision

LernHive ist eine eigenständige, modular erweiterbare Lernplattform — klarer, leichter bedienbar und experience-orientiert. UX und Design sind klar von der Business-Logik getrennt; Bausteine statt Sonderlocken. Als Fundament nutzt LernHive die Moodle-5.x-Plattform, ohne sie zu forken — siehe Abschnitt Technologie unten.

Positionierung

LernHive ist eine eigenständige Lernplattform mit geführter UX, Flavours für typische Einsatzszenarien und einer optionalen LXP-Erfahrung. Level-System und Explore-Feed formen die Produkt-Identität — das darunterliegende Open-Source-Fundament bleibt technisch kompatibel, aber konzeptionell im Hintergrund.

Sieben Kernprinzipien

1 · Clean Foundation Die darunterliegende Open-Source-Plattform bleibt unverändert. Alle Erweiterungen laufen über offizielle Erweiterungs-Schnittstellen — kein Fork.

2 · Function & Design getrennt Business-Logik in den funktionalen Bausteinen, Visuelles im Theme. Keine Vermischung.

3 · English first Englisch ist kanonisch, Übersetzungen folgen den Konventionen der darunterliegenden Plattform.

4 · Bewährtes wiederverwenden Vorhandene Rollen, Capabilities, Strings und Konzepte werden wiederverwendet, nicht ersetzt.

5 · Simple UX first Klarheit schlägt Feature-Vollständigkeit. Geführte Flows vor Experten-Overload.

6 · Flavours = Empfehlungen Startkonfigurationen, keine hartkodierten Modi. Alles bleibt anpassbar, Overrides sind nachvollziehbar.

7 · Release 1 diszipliniert Scope-Disziplin: R2-Ideen dürfen nicht still in R1 wandern. Sichtbare Doku-Änderungen bei Scope-Shifts.

Fünf Produktschichten

So ist LernHive sauber geschnitten. Jede Schicht hat ihre eigene Verantwortung und darf nur nach oben abhängen.

Schicht	Verantwortung
1 · Open-Source-Fundament	Kurse, Aktivitäten, Gruppen, Enrolment, Rollen, Reporting, Messaging, Kompetenzen, Sprachsystem — aus der zugrundeliegenden Moodle-5.x-Plattform.
2 · LernHive-Bausteine (funktional)	Orchestrierung, Guidance, produkt-spezifische Logik: Flavours, Levels, Launcher, ContentHub, Explore, Audience, Reporting, Digest.
3 · LernHive Theme & UX-Komponenten	Visuelle Identität, Layout-Shells, Context Dock, Launcher-UI, Sidebar.
4 · Flavour- & Configuration-Layer	Empfohlene Startkonfigurationen (School, LXP, später weitere), Override-Verlauf, Partner-Dokumentation.
5 · SaaS- & Partner-Layer	Betrieb, Managed Service, Partner-Sales, flavour-basiertes Consulting.

Architektur-Kontrakt: ADR-P03

Die geteilten UI-Klassen für die Baustein-Oberflächen (.lh-plugin-*, .lh-btn-*, .lh-icon-*) und der plugin_shell_header-Partial liegen zentral in local_lernhive. So rendern alle LernHive-Bausteine unter jedem kompatiblen Theme strukturell korrekt — branded, wenn theme_lernhive aktiv ist, neutral unter Boost / Boost Union / Partner-Themes.

Flavours — Produkt-Startpunkte

Flavour	Priorität	Kernaussage
School	R1	Klassischer Kurs-Einstieg, vertraute Struktur, geführte UX.
LXP	R1	Explore statt Dashboard, Snacks, Communities, Follow/Bookmark, Digest.
Higher Education	später	Akademische Zielgruppen, Kursstruktur, Prüfungs-UX.
Corporate Academy	später	Weiterbildung, Pflicht-/Empfehlungs-Content, Reporting.
Association / Membership	später	Verbände, Mitgliederbindung, Community-Inhalte.

Regel

Flavour-spezifische Wording-Änderungen bleiben minimal. Kern-Terminologie — Explore, Audience, Follow, Bookmark, ContentHub, Snack, Community, Launcher — bleibt stabil über alle Flavours.

Roadmap

Disziplinierter Kernumfang

Core-UX + Theme
Level-System + Feature Registry
Launcher + ContentHub + Copy + Library
Onboarding (Level-1 Pack live)
School-Flavour
LXP-Flavour mit Explore, Follow, Digest
Basis-Audience-Regeln
3-Tile-Reporting-Dashboard
Orgchart (produktiv)
Learning Pathways + Certify (produktiv)

Verfeinerung & Tiefe

Stärkere Personalisierung
Empfehlungs-Logik
Audience Circle-UX (visueller Rule-Builder)
Content-Versionierung & Library-Lifecycle (Update-Vergleich, Importhistorie)
Erweitertes Reporting (Custom-Dimensionen, Inactive-Users-Tile)
Skills & Learning Plans (UX-Layer)
Snack- und Community-Kursformate
Multitenancy-Härtung (Mandanten-Isolations-Patterns)
Higher-Ed- & Corporate-Academy-Flavours

Später

Offene Richtungen

Higher-Ed-, Corporate-, Association-Flavours
Native Mobile-App
AI-gestützte Content-Erstellung
Third-Party-Theme-Integration

Preismodell

Prinzip

Die Preis-Architektur steht: aktive Nutzer/innen als einzige Berechnungsgrundlage, SaaS-only, Betrieb in Deutschland, DSGVO- und ISO-27001-konform. Die konkreten Zahlen pro Tier werden nachgeschärft, sobald R1 produktiv läuft.

Geschäftsmodell (fix)

SaaS-only. Managed-Betrieb auf deutschen Servern. Keine Self-Hosted-Variante. So bleiben Sicherheit, Updates und Datenschutzzusagen für alle Kunden einheitlich.
Aktive Nutzer/innen als Berechnungsgrundlage. Abgerechnet wird pro Person, die sich innerhalb eines Kalendermonats mindestens einmal anmeldet. Angelegte, aber inaktive Accounts zählen nicht.
Partner-enabled. Sales und Einführung laufen über ein Partnermodell. Für Partner existiert ein eigenes Tier mit Wholesale-Konditionen.
Managed Service mit dokumentierter Konfiguration. Die Konfigurations-History macht jede Änderung auditierbar und ist Grundlage für Managed-Service-Verträge.

Zusagen, die in jedem Tier gelten

Zusage	Inhalt
DE-Hosting	Ausschließlich deutsche Serverstandorte. Keine Datenverarbeitung außerhalb der EU. AVV nach Art. 28 DSGVO wird bereitgestellt.
DSGVO by Design	Datenminimierung, Rollen- und Rechtesystem, dokumentierte Löschfristen, Privacy-API-basierte Datenauskünfte, Exporte und Löschungen.
ISO 27001	Betrieb in ISO-27001-zertifizierten Rechenzentren. Change/Incident/Backup/Zugriff folgen einem ISMS. Auditberichte und TOMs auf Anfrage.
Updates & Backups	Plattform-Updates, Baustein-Updates, Sicherheits-Patches, tägliche Backups. Kein separater Wartungsvertrag.
Portable Inhalte	Bei Vertragsende vollständige Datenexporte in offenen Standard-Backup-Formaten. Keine Lock-in-Strafe.

Preisdimensionen

Aktive Nutzer/innen pro Monat — primäre Skalengröße, Tier-bestimmend
Gebuchte Flavours (School, LXP, später weitere) — Freischaltung innerhalb des Tiers
Add-ons (Seminarmanagement, Orgchart, spätere Skills/Reporting) — pauschal pro Instanz; Enterprise-Tier enthält sie
Supportstufe (Standard, Priority, Partner-Managed) — Tier-gebunden

Tier-Gerüst

Starter bis 250 aktive / Monat

Einzelne Schulen, kleine Teams
Eine Flavour (School oder LXP)
Standard-Support
Backups & Updates inkl.

Professional 250 – 2.500 aktive / Monat

Mittlere Organisationen
Beide Flavours (School + LXP)
Erweitertes Onboarding
Priority-Support

Enterprise ab 2.500 aktive / Monat

Konzerne, Verbünde, Hochschulen
Alle Flavours & Add-ons
Orgchart + Seminarverwaltung inkl.
SLA, dedizierte Instanz, SSO

Partner-Managed Partnermodell

Partner, die mehrere Kunden betreuen
Wholesale-Konditionen
Configuration-Tracking + Training
Gemeinsame Betreuung im Mandanten

Die Kundenansicht — mit Berechnungsgrundlage, Trust-Zusagen und FAQ — lebt auf einer eigenen Seite:

→ Preisseite öffnen

Offene Fragen zum Preismodell

Konkrete Listenpreise pro Tier — werden erst publiziert, wenn R1 produktiv läuft und Nutzungskurven vorliegen.
Fair-Use-Grenzen bei Speicher und Traffic: qualitative Formulierung oder konkrete GB-Schwellen?
Überschreitungs-Nachverrechnung: pauschal pro 100 zusätzliche aktive Nutzer/innen, oder linear pro Kopf?
Partner-Marge-Modell: Wholesale-Rabatt fix oder gestaffelt nach Mandantenvolumen?
Add-on-Preise jenseits des Enterprise-Bands: pauschal pro Instanz, oder mit eigener Nutzer-Staffel?

Leitplanken

Für die tägliche Arbeit am Produkt.

Dokumentationshierarchie beachten. Produkt-Entscheidungen in product/, plugin-lokale Entscheidungen in public///docs/, visuelle Entscheidungen in theme_lernhive.
Terminologie stabil halten. Kernbegriffe dürfen nicht flavourspezifisch umbenannt werden.
Strings wiederverwenden. Bestehende Plattform-Strings zuerst, neue Strings nur mit Begründung.
DevFlow-Konsistenz. Ändert sich ein Feature, müssen alle sechs DevFlow-Dateien des Plugins auf Linie bleiben.
Scope-Disziplin. R1-Ziele werden nicht unbemerkt durch R2-Ideen erweitert.