Auf der letzten ILIAS-DevConf hat das Technical Board ein Strategiepapier (PDF-Download) vorgestellt, das die Schwerpunkte seiner zukünftigen Arbeit skizziert. Das Papier leitet sich aus der ILIAS-Vision ab, die bereits 2015 formuliert wurde. Über die Inhalte der Strategie und die daraus resultierenden Maßnahmen haben wir uns mit Board-Sprecher Alexander Killing unterhalten.

Hallo Alexander! In Eurem Strategiepapier konkretisiert Ihr einige zentrale Punkte, die bereits in der ILIAS-Vision zu finden sind und formuliert entsprechende Zielvorstellungen. Dabei sind diese Ziele naturgemäß noch recht weit gefasst. Wie konkretisiert Ihr sie für die Entwicklungspraxis?

Für jedes Ziel verwalten wir intern konkrete Maßnahmen. Diese entstehen zum Teil ad hoc in Reaktion auf aktuelle Anforderungen. Es ist jedoch unser Bestreben, auch systematisch vorzugehen. So, wie die Vision die Grundlage der Strategie bildet, soll im nächsten Schritt die Strategie als Grundlage für diese Maßnahmen dienen. Sie sollen priorisiert aus der Strategie abgeleitet werden. Unser Ziel ist es, alle wichtigen Aspekte der Software-Entwicklung mit entsprechenden Maßnahmen abzudecken.

Anschließend muss dann überprüft werden, ob die Maßnahmen auch funktionieren. Hier möchten wir in der Zukunft vermehrt mit Kennzahlen arbeiten. Diese sind aber leider nicht immer leicht zu beschaffen bzw. in ihrer Aussagekraft umstritten.

Hast Du Beispiele für diese Problematik?

Institutionelle Vereinsmitglieder können seit einiger Zeit Bugs priorisieren, um diese schneller beheben zu lassen, wenn sie für ihr Einsatzszenario problematisch sind. In den Jour Fixe-Protokollen führen wir seitdem eine Übersicht über die Anzahl offener, priorisierter Bugs pro Entwickler - auf den ersten Blick eine gute Kennzahl.

Allerdings berücksichtigt diese Übersicht noch nicht die Komplexität der zugrundeliegenden Module. Man könnte sich dazu beispielsweise den Umfang des Codes ansehen. Dieser ist im Test&Assessment natürlich viel größer als in der Bookmark-Verwaltung. Fairerweise müsste man also die Anzahl der gemeldeten Bugs in Relation zur Funktionalität des jeweiligen Moduls betrachten. Auch das Risiko, das von einem Bug ausgeht, sollte berücksichtigt werden: Wie dramatisch sind Fehler in den jeweiligen Komponenten? Im RBAC oder auch im Test&Assessment sind die Folgen eines Fehlers oft problematischer als in der Kommentarfunktion.

Wir werden nach Kennzahlen suchen, die es uns ermöglichen, Aussagen über die Qualität von Code und Prozessen zu machen, um Maßnahmen besser überwachen zu können.

Das erste Kapitel Eures Strategiepapiers widmet sich der durch die Community angetriebenen Entwicklung von ILIAS. Die Überarbeitung des Maintainer-Konzepts ist dabei ein wichtiges Thema. Welches Ziel hat diese Änderung?

Unser Ziel ist es, mehr Personen an der ILIAS-Entwicklung zu beteiligen. Dies schließt zunächst neben den Programmieren viele andere Personen wie Tester, Autoren von Feature-Wiki Einträgen oder Bug-Reporter mit ein. Auf der Code-Ebene gibt es neben unseren offiziellen Maintainern auch Leute, die keine Maintainer sein möchten, aber trotzdem etwas zur Entwicklung beizutragen haben. Dies sind die sogenannten "Code Contributors", deren Rolle wir nun erstmals definiert haben.

Was ist die Funktion dieser Rolle?

Am wichtigsten war uns zunächst die Schaffung eines geregelten Verfahrens für Beiträge von Nicht-Maintainern zum Programmcode.

Die Code-Änderungen erreichen uns als sogenannte "Pull Requests" direkt in in unserem Repository auf GitHub und werden auch dort verwaltet. Sie werden kategorisiert (z.B. als Bugfix oder Verbesserungsvorschlag) und können eingesehen, diskutiert, angepasst und bei Zustimmung des Maintainers in den Hauptcode von ILIAS übernommen werden.

Neue Features müssen allerdings weiterhin den Weg über den Jour Fixe gehen. Die genauen Regeln finden sich in unserem auch in unserem Repository auf GitHub.

Wird sich an der bestehenden Rolle der Maintainer auch etwas ändern? Und was ist mit der Rolle des Jour Fixe?

Die klassischen Maintainer wird es weiter geben. Sie haben mit dem neuen Contributing-Prozess auch neue Verantwortlichkeiten bekommen. Denn sie sollen Pull Requests von Außenstehenden ähnlich behandeln wie Bug-Meldungen: Nach spätestens 21 Tagen sollen die Beitragenden Feedback erhalten.

Wie auch bei Bugs besteht natürlich die Möglichkeit, Pull Requests auf die Jour Fixe-Agenda zu setzen. Der Jour Fixe bietet auch hier einen Ort für die Diskussion von Fragen und Problemen - und bei Bedarf natürlich auch zur Konfliktlösung. Diese Möglichkeit steht nicht nur den Maintainern offen, sondern auch den Beitragenden von außerhalb.

Zurück zum Maintainer-Modell…

Wir klären zurzeit die Verantwortlichkeiten der klassischen Maintainer für die verschiedenen Teile des Codes. Diese sollen direkt innerhalb der Codeverzeichnisse noch besser dokumentiert werden.

Zudem gibt es das Bestreben, ein zusätzliches Maintainer-Modell zu erarbeiten. Das klassische Modell funktioniert sehr gut für stark anwendungsbezogene Module wie zum Beispiel das Forum, das Lernmodul oder das Test&Assessment. In diesen Bereichen ist es notwendig, spezielle Kenntnisse über die Konzepte und Prozesse der Anwendungsfälle zu haben.

Es gibt aber auch Teile im Programmcode, welche technische Grundlagen für viele weitere Komponenten sind. Besonders wenn diese Teile sehr komplex werden ist ein stärker kollaborativer Ansatz interessant. Die Kitchen Sink ist dafür ein gutes Beispiel: Der Code für unsere Benutzeroberfläche wird von allen Maintainern genutzt und hat daher viele Abhängigkeiten. Hier ist es sinnvoll, Beiträge einer größeren Anzahl von Entwicklerinnen und Entwicklern zu ermöglichen.

Welche Probleme würde ein solches kollaboratives Modell mit sich bringen?

Zunächst muss sichergestellt werden, dass die Pflege des Codes funktioniert. Zum Beispiel im Falle einer Bugmeldung führt die kollaborative Verantwortung idealerweise dazu, dass sich auch stärker Entwickler beteiligen, die den konkreten Code gar nicht selber geschrieben haben. Allerdings kann es in einer größeren Gruppe auch dazu kommen, dass sich jeder denkt "es wird schon jemand anders richten". Das muss natürlich verhindert werden.

Zudem erhöht sich der Kommunikationsaufwand - insbesondere wenn man mit einer Komponente eine klare und konsistente Strategie verfolgen will. Hier gibt es erhöhte Anforderungen an gute Regeln und eine gute Dokumentation.

Das Thema einer kollaborativen Maintainerschaft wird uns noch eine Weile beschäftigen. Unser übergeordnetes Ziel ist es, die gemeinsame Arbeit an Querschnittsfunktionen zu vereinfachen und zu verbessern.

Das nächste große Thema des Strategiepapiers ist die Zuverlässigkeit des Systems. Ein Ziel sind weitere Qualitätsverbesserungen mit Hilfe von Unit Tests. Kannst Du uns erklären, was Unit Tests überhaupt sind?

In der Community sind im Testbereich ja vor allem die TestRail-Testfälle bekannt, die im Herbst von einer Vielzahl von Freiwilligen durchgetestet werden. Im Gegensatz dazu können Unit Tests automatisiert durchgeführt werden. Jeder Entwickler kann diese laufen lassen und damit überprüfen, ob die durch Testfälle abgedeckten Elemente im Code auch nach seinen Änderungen noch funktionieren. Dabei überprüfen Unit Tests aber - im Gegensatz zu den manuellen Tests in TestRail - nur sehr feingliedrig einzelne Elemente im Code, wie z.B. einzelne Code-Klassen.

Dieses automatisierte Testen erlaubt es den Entwicklerinnen und Entwicklern, größere Überarbeitungen des Codes ("Refactorings") wesentlich sicherer durchzuführen. Dies war zum Beispiel für die Umsetzung der PHP7-Unterstützung von Bedeutung: Geänderter Code konnte mit Hilfe von Unit Tests schnell überprüft werden. Auf diese Weise kann vermieden werden, dass Änderungen an einer Stelle anderswo im Code Probleme erzeugen.

Was sind Eure Pläne in diesem Bereich?

Das Ziel des Technical Board ist es, die Umsetzung von Unit Tests zu erleichtern und Regeln aufzustellen, in welchen Bereichen sie angelegt werden müssen. Hier sind natürlich Querschnittskomponenten bedeutsam, von denen viele Entwicklerinnen und Entwickler abhängig und die besonders wichtig für die Funktion von ILIAS sind.

Wir haben kürzlich ein virtuelles Treffen veranstaltet, um gemeinsam mit den Entwicklern "Best Practices" und typische Probleme bei der Erstellung von Unit Tests zu identifizieren. Weitere Treffen werden sicherlich folgen.

Zwei zentrale Kapitel Eurer Strategie widmen sich der Nutzbarkeit von ILIAS für verschiedenste Institutionen und Usergruppen. Worum geht es im Kapitel "Usable for Everyone"?

Dieser Abschnitt macht klar, dass ILIAS sich an zahlreiche Zielgruppen richtet, deren Technikverständnis sich stark unterscheidet. Unser Ziel ist es, dass sich alle Benutzerinnen und Benutzer gut in ILIAS zurecht finden. Dies soll auch dann klappen, wenn sie sich nicht besonders gut mit Technik auskennen. Außerdem spielt hier natürlich das Thema Barrierefreiheit eine große Rolle.

Und worum geht es - in Abgrenzung dazu - im Kapitel "Beyond Standard"?

Hier betrachten wir stärker die technische Seite und die Anpassbarkeit des Systems an verschiedene Kontexte. So soll es möglich sein, ILIAS in bereits vorhandene IT-Infrastruktur einzubetten, z.B. über Schnittstellen zu anderen Systemen wie Hochschulverwaltungssoftware. Auch die Erweiterbarkeit durch Plugins soll auf einfache Weise gewährleistet werden.

Dieses Kapitel ist besonders für unsere Service Provider interessant. Die Anforderungen ihrer Kundinnen und Kunden sollen durch die Softwarearchitektur von ILIAS noch leichter erfüllbar sein. Plugins, Patches und unterschiedlichste Konfigurationen sollen es erleichtern, ILIAS über den Standard hinaus an den eigenen Bedarf anzupassen.

Verabschiedet Ihr Euch damit nicht auch vom traditionellen integrierten ILIAS-Ansatz? Von Anfang an war es ja ein wichtiges Ziel von ILIAS, bereits mit dem Kern eine vollständige Lernplattform anzubieten. Werden Plugins zukünftig im Vergleich zum Kern eine wichtigere Rolle spielen?

Es ist richtig, dass der ILIAS-Standard über einen langen Zeitraum durch eine stetig wachsende Anzahl an Funktionen gekennzeichnet war. Das Plugin-Konzept kam erst relativ spät dazu. Das Technical Board hat allerdings nicht das Ziel, die vorhandene, integrierte Funktionalität aufzulösen. Es geht uns vielmehr darum, mit ILIAS noch weitere Anwendungsszenarien effizient zu unterstützen, ohne dass jegliche Neuerung gleich fest integriert werden muss.

Die Nutzung von Plugins hat einen weiteren Vorteil: Sie ermöglicht es, neue Trends oder Standards aufzunehmen und Erfahrungen zu sammeln, bevor diese in den Kern wandern. Ein Beispiel hierfür ist die LTI-Unterstützung. Sie wurde zunächst als Plugin durch Fred Neumann ermöglicht und wird nun Teil des Kern-ILIAS, da sich immer mehr ILIAS-Nutzerinnen und Nutzer für eine Integration ausgesprochen haben.

Auf der anderen Seite sind wir offensiver darin geworden, nicht mehr benötigte Features aus dem Kern zu entfernen. Das Payment-Modul ist hierfür ein Beispiel. Wir achten also darauf, dass das System trotz vieler integrierter Neuerungen beherrschbar bleibt.

Ein weiteres Thema, das zur Zeit viele in der ILIAS-Community bewegt, ist die mobile Nutzung der Software und der Wunsch nach einer App. ILIAS-Anwender wie die Uni Hohenheim und die Uni Freiburg haben erste Funktionalitäten erfolgreich als App umsetzen lassen. Unter dem Titel "Learning Everywhere Anytime" findet sich dieses Thema auch in Eurem Strategiepapier. Wie seht Ihr die aktuellen Initiativen?

Schon seit längerer Zeit wird bei der ILIAS-Entwicklung ein starker Fokus auf die Responsivität gelegt. Das heißt, dass ILIAS auf kleinen ebenso wie auf großen Bildschirmen genutzt werden kann. Die Projekte Kitchen Sink und die Überarbeitung der Benutzeroberfläche verfolgen beide dieses Ziel. Mit ILIAS 5.3 wird es hier weitere Verbesserungen geben.

Doch gehen diese Bemühungen vielen Mitgliedern der ILIAS-Community nicht weit genug. So wurde durch die Uni Freiburg in der Tat die Entwicklung einer echten ILIAS-App angestoßen, die auf der DevConf bereits vorgestellt wurde.

Zurzeit ist diese Entwicklung vor allem eine Initiative mehrere Mitglieder der SIG Mobile. D.h. sie findet unabhängig von den Prozessen des ILIAS-Standards (wie z.B. Entscheidungen im Jour Fixe, Nutzung des Feature Wikis oder des ILIAS Bug Trackers) statt. Das Technical Board möchte versuchen, die ursprünglichen Anforderungen auch durch Entwicklungen im ILIAS-Standard stärker zu berücksichtigen. Wir befinden uns in Kontakt mit der SIG und werden uns um eine offene und integrierte Strategie bemühen.

Der Aufwand für eine vollständige ILIAS-App wäre sicherlich groß. Es gibt aber auch Stimmen, die der Ansicht sind, dass ein Großteil der Funktionalität auch im Smartphone-Browser abgebildet werden könnte. Welche Probleme und Chancen siehst Du da?

In der Vergangenheit hatten native Apps wesentliche Eigenschaften, wie z.B. Push-Benachrichtigungen, standortbezogene Dienste und Offline-Nutzung, die für browsergestützte Web Apps nicht zur Verfügung standen. Diese Eigenschaften machen aber ein wesentlichen Teil der mobilen Nutzung aus.

Dieses Bild ändert sich jedoch fortwährend. Moderne Browser unterstützen solche Funktionen zunehmend. D.h. sie können dann über Javascript angesprochen werden, was wiederum eine Integration in das Standard-ILIAS erleichtert. Es ist also möglich, auch über den Browser den eigenen Standort mit einer Software wie ILIAS zu teilen, um beispielsweise eine Idee wie die Lernorte umzusetzen.

Eine besondere Herausforderung ist dabei die Nutzung der Anwendung ohne Verbindung zum Internet. Moderne Browseransätze mittels sog. Service Worker werden noch uneinheitlich von aktuellen Browsern unterstützt. Eine Gruppe um Stefan Schneider untersucht genau diesen Punkt zurzeit bei der Entwicklung eines neuen SCORM-Offline-Players für ILIAS 5.3.

Interessant ist, dass der SCORM-Offline-Player ursprünglich nicht moderne Geräte wie Smartphones oder Tablets adressiert hat, sondern eher die Nutzung auf einem klassischen Laptop ohne Verbindung zum Internet. Diese Bedürfnisse werden von einer nativen App aber überhaupt nicht bedient. Das macht den Ansatz in Richtung einer progressiven Web App sehr attraktiv. Im besten Fall kann man mit einer Code-Basis auf allen Plattformen, die einen Browser unterstützen, die mobilen Anforderungen der Nutzerinnen und Nutzer realisieren. Eine einheitliche Code-Basis würde zudem automatisch die Nutzung bestehender Entwicklungsprozesse und Ressourcen bedeuten.

Ich hoffe, dass der Ansatz des SCORM-Offline-Players sich auch auf andere ILIAS-Komponenten, wie z.B. ILIAS-Lernmodule, Glossare, Dateien und Mediacasts übertragen lässt.

Ohne Frage wird die mobile Strategie uns noch eine Weile beschäftigen. Hier müssen wir sicher in der Community weiter diskutieren, wie die bestehenden Herausforderungen am besten gemeistert werden können. Das Technical Board wird sich an der Diskussion selbstverständlich rege beteiligen.

Dann sind wir mal gespannt, wie es weitergeht. Alexander, vielen Dank für das Gespräch!