Immer mal wieder werden wir gefragt, warum wir uns am HPI die Mühe machen, ein LMS komplett neu aufzusetzen, wenn es doch schon eine sehr erfolgreiche Open-Source-Software gibt: Moodle. Es ist eine Frage, die wir auch im Kontext der Entwicklung unserer Lernplattform openHPI immer wieder gestellt bekommen. Zunächst einmal vorweg: Moodle ist eine tolle Software mit einer lebendigen und aktiven Community. Ich selbst habe in der Vergangenheit Moodle öfter eingesetzt und auch bei uns an der Universität Potsdam sind einige Moodle-Instanzen in Betrieb.

Ein kurzer Exkurs: Moodle als MOOC-Platform?

Es gibt außerdem Projekte wie oncampus, die Moodle erfolgreich als unterliegende Plattform einsetzen. Das geht und kann sogar - mit entsprechenden Anpassungen - hübsch aussehen. Bei openHPI bestand unser Anspruch aber von Anfang an aus zwei Teilen: Zum einen wollten wir eine Plattform realisieren, die ganz spezifisch auf die Anforderungen von skalierendem, videobasiertem Lernen zugeschnitten ist: kein Knopf zu viel, alles optimiert auf den Use Case also den Anwendungsfall. Zweitens wollten wir eine Plattform, die für unsere Forschungsthemen und Abschlussarbeiten eine sinnvolle Umgebung ohne unnötigen Ballast bietet. Rückblickend gesehen war das eine gute Entscheidung.

Aber zurück zur HPI Schul-Cloud. Hier haben wir vom BMBF den Auftrag, herauszufinden, was die Gelingensbedingungen für cloudbasierte Infrastrukturen im schulischen Umfeld sind. Es haben sich schnell verschiedenste Dimensionen abgezeichnet. So haben wir in ersten Erhebungen herausgefunden, dass vorhandene Moodle-Systeme nur in einem Bruchteil ihrer Funktionalität genutzt werden. Das deckt sich mit Erkenntnissen über andere Systeme, die von Lehrenden immer nur in dem Maße genutzt werden, wie Features in Schulungen thematisiert worden sind. Nur wenige Nutzer explorieren weitere Funktionen von sich aus. In der Bilanz führt dies zu einem komplexen System, welches jedoch in der Vielzahl der Fälle nur für einfache Use-Cases benutzt wird. Wenn aber auch eine breitere Zielgruppe adressiert werden soll, so ist dies ein Hindernis. Was bedeutet das für unser Forschungs- und Pilotprojekt? Wir wollen beim Erproben möglichst wenig Zeit mit historischem Ballast verbringen und stattdessen lösungsorientiert vorgehen. So ist die Benutzeroberfläche der HPI Schul-Cloud eine schmale, eigenständige Anwendung und alle UI- und UX-bezogenen Arbeiten müssen sich lediglich mit dieser Komponente beschäftigen.

Auch wenn wir in unserem Projekt mit Moodle schneller zu sichtbaren Ergebnissen gekommen wären: spätestens wenn bei einigen Forschungsthemen, bspw. dem Thema Offlineverfügbarkeit, grundlegende Änderungen an Kernmodulen vorgenommen werden müssen, wären diese sehr aufwendig und viele hätten aufgrund ihres teilweise noch experimentellen Charakters keine Chance in den Master-Code des Projektes übernommen zu werden.

Modularität und Skalierbarkeit

Moodle ist eine historisch gewachsene Anwendung mit monolithischer Architektur. Sie ist zwar dank Plug-Ins gut erweiterbar, aber ihr Einsatz ist immer eine “Alles-oder-Nichts Entscheidung”. Die HPI Schul-Cloud ist demgegenüber eine modulare, dienstbasierte Infrastruktur. Dies ermöglicht zwei Szenarien: Zum einen lassen sich Module durch andere Module austauschen – etwa wenn neue Technologien zum Einsatz kommen oder auch um Individualisierungen zu ermöglichen. Zum anderen lassen sich Module als Microservices in anderen Projekten verwenden. So folgen wir nicht nur guter Software-Architektur, sondern sorgen auch für die Nachhaltigkeit, indem wir die Verwendung von einzelnen Komponenten in anderen Kontexten erlauben und fördern. Dafür muss nicht eine proprietäre Plugin-Schnittstelle bereitgestellt werden, sondern die Komponente wird generisch per REST angebunden.

Native Cloud

Moodle kommt aus einem Zeitalter, als Cloud noch kein Buzzword war. Es gibt Moodle-Instanzen, die so angepasst wurden, dass sie zentral gehostet und auch für erhebliche Nutzermengen verfügbar sind (bspw. mebis in Bayern), doch das macht daraus noch keine Cloud-Anwendung.

Unter einer Cloud verstehen wir neben einer wirklichen Vernetzung von internen und externen Diensten auch die Verwendung von Technologien, die sich in der Cloud ohne Probleme skalieren lassen (bspw. Microservices und dokumentenorientierte Datenbanken).

Ist weniger mehr?

Kürzlich wurde im Internet auf einem Lehrerblog eine Gegenüberstellung veröffentlicht, die detailliert den Funktionsumfang von Moodle mit dem der HPI Schul-Cloud vergleicht. Auf Twitter wurde gar das Bild Auto vs. Bobby-Car bemüht. Hier liegen verschiedene Annahmen im Argen. Zum einen werden hier Äpfel mit Birnen verglichen (bzw. ein lang gewachsenes Projekt mit großer Community mit einem jungen Pilotprojekt). Zum anderen ist die Anzahl der Features keine Qualitätsmetrik. Hierzu muss man nur zehn Jahre zurückschauen, als Apple sein erstes iPhone vorstellte. Es gab zeitgleich Mobiltelefone von Nokia mit mehr Features. Der Rest ist Geschichte: Nokia verschwand in der Bedeutungslosigkeit; Apple schaffte es auch dank intensiver Nutzerfokussierung der Geräte zu einem der wertvollsten Unternehmen der Welt zu werden.

Wir wollen mit der HPI Schul-Cloud nicht zu einem wertvollen Unternehmen werden, aber wir wollen unseren Nutzern einen wertvollen digitalen Mehrwert bieten. Denn nur so - davon sind wir überzeugt - gelingt der Weg zu einer erfolgreichen Digitalisierung des Lernraums Schule. Dieser Weg führt eng entlang der Bedürfnisse der Nutzer. Am Ende des Tages können die HPI Schul-Cloud und Moodle problemlos nebeneinander bestehen. Und tatsächlich kann Moodle von Erkenntnissen und Modulen unseres Projektes profitieren und daran partizipieren.

Hinweise der Redaktion
Bildnachweise: HPI/K. Herschelmann
Sprachlicher Hinweis: Es sind stets Personen männlichen und weiblichen Geschlechts gleichermaßen gemeint; aus Gründen der einfacheren Lesbarkeit wird an dieser Stelle nur die männliche Form verwendet.