An der letzten Meile scheitern alle: Warum es keine pädagogische Open-Source-Anwendung für Schulen gibt

Wer IT-Verantwortlichen in Schulen zuhört, hört zwei Sätze immer wieder. Der erste: „Die Infrastruktur läuft gut.” Der zweite, direkt dahinter: „Aber die Lehrkräfte kommen damit nicht klar.”

Das ist kein Zufall. Es ist das Ergebnis einer strukturellen Lücke — und diese Lücke erklärt, warum die Frage nach Open Source an Schulen so selten zu befriedigenden Antworten führt.

Was funktioniert: die Infrastruktur

Die Open-Source-Welt hat beeindruckende Infrastruktur hervorgebracht, die in Schulen heute produktiv eingesetzt wird:

• UCS@school verwaltet Identitäten für hunderttausende Schülerinnen, Schüler und Lehrkräfte in Deutschland. Es ist stabil, gut dokumentiert und wird aktiv weiterentwickelt.
• Nextcloud speichert Dateien, synchronisiert Kalender, ermöglicht kollaboratives Arbeiten — DSGVO-konform, on-premise.
• Moodle ist das weltweit meistgenutzte Lernmanagementsystem und läuft in tausenden deutschen Schulen.
• Veyon ermöglicht Lehrkräften, Schülerbildschirme zu überwachen und zu steuern — quelloffen, stabil, in aktiver Entwicklung.

Diese Werkzeuge funktionieren. Sie werden von IT-Administratoren aufgesetzt, konfiguriert und betreut. Sie laufen auf Linux-Servern, die niemand mehr anfassen muss, weil sie zuverlässig tun, was sie sollen.

Und genau hier beginnt das Problem.

Was fehlt: die letzte Meile

Die Infrastruktur läuft — aber was sieht die Lehrkraft am Montagmorgen, wenn sie den Unterricht vorbereitet?

Sie öffnet einen Browser und navigiert zu einem Bookmark. Vielleicht kommt eine Login-Seite. Vielleicht nicht — manchmal ist der SSO nicht richtig konfiguriert, manchmal fehlt der Bookmark nach dem Gerätewechsel. Sie sucht den Stundenplan in einem System, die Materialien in einem anderen, das Klassenbuch in einem dritten.

Das ist die letzte Meile. Sie ist nicht technisch. Sie ist pädagogisch, ergonomisch, alltäglich. Und hier hat Open Source bislang systematisch versagt.

Warum das so ist

Die Ursachen sind strukturell und lassen sich in drei Kategorien fassen:

1. Open Source löst Probleme, die Entwickler haben

Die Menschen, die Open-Source-Software für Schulen schreiben, sind überwiegend IT-Experten. Sie lösen die Probleme, die sie kennen: Serveradministration, Protokollimplementierung, Sicherheit. Das sind echte und wichtige Probleme.

Die Probleme, die eine Grundschullehrerin hat — Wie finde ich schnell heraus, ob alle Schülerinnen heute da sind? Wie sende ich den Eltern eine Mitteilung? Wo ist das Formular für die Vertretungsregelung? — erscheinen im Open-Source-Universum nicht als Bugs, sondern als Anforderungen, die „jemand anderes” lösen soll.

2. Pädagogische Software braucht pädagogisches Wissen

Eine gute Schul-App zu bauen bedeutet nicht, eine gute App zu bauen und sie dann in Schulen zu installieren. Es bedeutet, zu verstehen, wie Unterricht funktioniert, wie Schulorganisation abläuft, welche Unterbrechungen tolerierbar sind und welche nicht, welche Informationen in welchem Moment verfügbar sein müssen.

Dieses Wissen liegt bei Lehrkräften, Schulleitungen und Pädagoginnen — nicht bei Entwicklerinnen. Der Brückenbau zwischen beiden Gruppen ist aufwändig, schlecht finanziert und in der Open-Source-Community strukturell unterrepräsentiert.

3. Motivation und Finanzierung folgen Incentives

Wer schreibt Open Source? Meistens: Menschen, die ein persönliches Jucken haben, ein professionelles Interesse, oder ein Unternehmen, das die Software selbst nutzt und von der Gemeinschaftsentwicklung profitiert.

Schulsoftware hat keinen dieser Treiber in ausreichendem Maß:

• Entwicklerinnen selbst nutzen keine Schulverwaltungssoftware
• Unternehmen, die solche Software bräuchten, sind Schulträger — öffentliche Einrichtungen ohne die Ressourcen, Open-Source-Projekte zu finanzieren
• Stiftungen und staatliche Förderprogramme schreiben selten Mittel für „UX für Lehrkräfte” aus

Das Ergebnis: Die Infrastruktur wird gebaut, weil sie technisch interessant ist. Die Oberfläche wird nicht gebaut, weil sie mühsam ist und niemand direkt davon profitiert.

Warum proprietäre Anbieter das nicht lösen

Man könnte einwenden: Kein Problem, das lösen dann die proprietären Anbieter — und Schulen kaufen ihre Produkte eben ein.

Das tun sie. Und sie merken nach drei Jahren, was das bedeutet:

• Die Anwendung hat eine schöne Oberfläche, aber keine offene Schnittstelle zur Identitätsverwaltung. Also hat die Lehrkraft doch wieder zwei Logins.
• Der Anbieter integriert nur seine eigenen Produkte. Wer Moodle statt der eigenen Lernplattform nutzt, ist außen vor.
• Das Abo ist nach zwei Jahren teurer geworden. Der nächste Vertrag läuft vier Jahre.

Proprietäre Lösungen lösen die letzte Meile — aber sie schaffen dafür neue Abhängigkeiten, die ihrerseits schwer zu lösen sind. Das ist kein Versagen, das ist Geschäftsmodell.

Was tatsächlich helfen würde

Die Antwort auf das Problem der letzten Meile liegt nicht in mehr Open-Source-Entwicklung nach dem bisherigen Muster. Sie liegt in einem anderen Ansatz:

Integration statt Neuentwicklung: Anstatt eine neue Schulanwendung zu bauen, die dieselben Probleme löst wie Nextcloud, Moodle und Veyon, braucht es eine Integrationschicht — eine Oberfläche, die vorhandene Werkzeuge zusammenbringt. Genau das ist der Ansatz von openschooldesk.

Lehrkräfte als Designpartner, nicht als Endnutzer: Software, die im Schulalltag funktioniert, muss mit Lehrkräften entwickelt werden — nicht für sie. Das bedeutet Feldforschung, Prototyping und Iteration im echten Schulumfeld.

Strukturierte Finanzierung: Die Infrastruktur wird durch Fördergelder, Unternehmensinteressen und Community-Arbeit finanziert. Die letzte Meile braucht ein eigenes Modell — zum Beispiel durch Schulträger-Konsortien, die gemeinsam eine UX-Schicht beauftragen und finanzieren, die dann allen gehört.

Offene Standards als Voraussetzung: Wenn alle Komponenten (Identitätsverwaltung, Dateispeicher, LMS, Kommunikation) über offene Standards kommunizieren, kann die Integrationsoberfläche gewechselt werden, ohne dass die Infrastruktur anfasst werden muss. Das macht das Risiko eines Scheiterns handhabbar.

Fazit: Die Lücke ist real — und schließbar

Es gibt keine pädagogische Open-Source-Anwendung für Schulen, die im Alltag funktioniert, weil die Open-Source-Community das Problem bislang falsch adressiert hat: Sie hat Infrastructure-as-Code gebaut, wo User-Experience gefragt war.

Das ist kein unüberwindliches Hindernis. Es ist eine Aufgabe, die Ressourcen, Kooperation und den Willen erfordert, pädagogisches Wissen ernstzunehmen.

Die Infrastruktur ist bereit. Die Komponenten laufen. Was fehlt, ist die letzte Meile — und die zu bauen ist genau das, woran wir arbeiten.