Auf der diesjährigen Mitgliederversammlung des ILIAS-Vereins in Köln wurde das Technical Board neu gewählt. Zur großen Freude der Wahlberechtigten waren vier der fünf Board-Mitglieder bereit, erneut zur Wahl anzutreten. So wurden Timon Amstutz, Michael Jansen, Richard Klees und Alexander Killing für eine weitere Amtszeit gewählt. Vervollständigt wird das Team durch Stephan Winiker von der Hochschule Luzern, der sich in diesem Jahr erstmals zur Wahl stellte.

Vor fast zwei Jahren hatten wir an dieser Stelle über das Strategiepapier des Technical Boards berichtet. Im Namen des "alten" Boards wurde dieses Papier auf der Mitgliederversammlung durch Richard Klees noch einmal kritisch gewürdigt. In ihrem Review haben die Board-Mitglieder geschaut, in welchen Bereichen Fortschritte erzielt wurden und in welchen nicht. Das vollständige Review ist online zu finden.

Wir haben Richard einige Fragen zu diesem Rückblick gestellt. Dabei sind wir auch noch einmal auf mögliche Änderungen im Maintainerschaftsmodell eingegangen - die auf der Mitgliederversammlung heiß diskutiert worden waren.

Hallo Richard! Eure Strategie war ja in verschiedene Bereiche aufgeteilt und dementsprechend fällt auch Euer Review aus. Im Bereich „Community-Driven“ seht Ihr Eure größten Erfolge. Unter anderem macht Ihr dies an der Zahl von Pull Requests fest, also den Beiträgen zum ILIAS-Code durch Dritte auf der Plattform GitHub. Diese stammen zum Teil von externen Entwicklern, die in der ILIAS-Szene bisher nicht aufgetreten waren.

In Eurem Review erwähnt Ihr, dass ein Contributor über diesen Weg zum Maintainer geworden ist. Kannst Du etwas mehr darüber erzählen, wie es dazu kam?

Neben MySQL/MariaDB, das sicherlich die Standarddatenbank für ILIAS ist, versucht ILIAS auch PostgreSQL als weiteres Datenbanksystem zu unterstützen. Die Unterstützung ist als "experimentell" gekennzeichnet, da bisher in der Community kein Nutzer von PostgreSQL sichtbar war und wir deshalb auch nicht wussten, wie gut die Unterstützung tatsächlich funktioniert.

Über die Pull Request wurden dann immer mehr Fixes für PostgreSQL von Lars Bruening (@lbruening) auf GitHub eingereicht. Unser Datenbank-Maintainer Fabian Schmid hat sich dem angenommen und gemeinsam mit Lars an den Pull Requests gearbeitet. Das hat so gut geklappt, dass Fabian Lars angeboten hat, die Maintainerschaft für PostgreSQL zu übernehmen. Der hat dankenswerterweise angenommen - so dass wir nun jemanden haben, der sich gezielt um die PostgreSQL-Unterstützung kümmert.

Das Beispiel zeigt, wie wir über die niedrige Hürde eines Pull Requests auf GitHub nicht nur Code sondern auch neue Maintainer gewinnen können, wenn wir uns hier als Community offen und kooperativ zeigen. Danke an Fabian dafür - und Dank auch an Lars, dass er sich PostgreSQL angenommen hat.

Die Maintainer-Frage stand ja auch im Beirat und in der Mitgliederversammlung im Fokus vieler Diskussionen. Dabei ging es unter anderem darum, ob in Zukunft auch Firmen oder Institutionen Maintainerschaften übernehmen können. Gibt es in dieser Frage im Technical Board einen Konsens oder diskutiert Ihr noch darüber?

Die Frage, wie unsere Codebase gewartet und erweitert werden kann, welche Rechte und Pflichten ein Maintainer hat und wie die Prozesse darum aussehen beschäftigt uns seit der Einführung des Technical Boards als Gremium. Das Thema ist vielschichtig und komplex und lässt sich nicht auf eine einfache Frage wie "Dürfen Unternehmen Maintainer sein: ja oder nein?" herunterbrechen. Stattdessen steht das Thema im Zentrum verschiedenster Ansprüche und Erwartungen aus allen möglichen Richtungen, die sich teilweise auch mehr oder weniger widersprechen. Die Fragen, die sich hier stellen, sind daher weitreichend und nicht leicht zu beantworten.

Das aktuelle Maintainermodel funktioniert - wenn auch sicherlich nicht immer für alle zufriedenstellend. Es funktioniert jedoch zumindest insofern, dass wir jedes Jahr eine neue stabile Version unserer Software veröffentlichen, an der auch Weiterentwicklungen zu sehen sind. Änderungen am Modell wollen wir deshalb mit Bedacht durchführen, um das, was wir haben, nicht unnötig zu gefährden.

Die Frage, ob Unternehmen Maintainer sein sollen, ist ein gutes Beispiel für die Komplexität. Wir sind absolut einig mit den Befürwortern, wenn es darum geht, gute Rahmenbedingungen für geschäftliche Aktivitäten im ILIAS-Umfeld sicherzustellen. Letztlich ist es gut für unsere Software, wenn Unternehmen oder Einzelpersonen Geld mit ihr verdienen können. Eine umfangreiche Software wie ILIAS lässt sich nicht als Hobby warten und weiterentwickeln. Investitionssicherheit ist hier sowohl für Auftraggeber als auch für Arbeitgeber von Maintainern sicherlich eine Dimension. Wir verstehen ebenfalls, dass es für Auftraggeber leichter ist, Unternehmen zu beauftragen, als Einzelpersonen.

Auf der anderen Seite haben wir als Community ein Interesse daran, das Know-How von Maintainern zu behalten - auch wenn diese ihren Arbeitgeber wechseln. Matthias Kunkel als Produktmanager benötigt Personen als Gegenüber, um mit ihnen die Weiterentwicklung von ILIAS-Komponenten zu konzipieren und zu entscheiden. Bei der Entwicklung einer Komponente durch ihre Nutzer und die Maintainer entstehen Beziehungen und Wissen, die sich nicht ohne weiteres auf jemand anderen übertragen lassen. Hier müssen wir ein schlüssiges Gesamtmodell entwickeln, dass all diesen und weiteren Ansprüchen gerecht wird.

Wir stellen weiterhin fest, dass es schon jetzt so ist, dass die reale Arbeit an einer Komponente nur selten vom Maintainer allein übernommen wird. Das wäre in vielen Fällen auch kaum zu leisten. Der Maintainer ist das Gesicht und die Klammer für ein ganzes Team von Menschen, die verschiedene Aufgaben übernehmen: Konzeption, Programmierung, Wartung, Kommunikation mit Nutzern, und alles weitere, was dazugehört.

Die Arbeit des Maintainers und seines Teams in der Community sollte hier auch nicht mit der Geschäftbeziehung zwischen dem Unternehmen des Maintainers und den Auftraggebern verwechselt werden. Wir werden ILIAS und seiner Community nicht gerecht, wenn wir die Kooperation in der Community nur in Auftragsbeziehungen denken.

Zurück zu Eurem Strategie-Review. Im Bereich "Reliable Learning Management" schaut Ihr unter anderem auf das Thema Sicherheit. Hier erwähnt Ihr, dass Ihr für die Betreuung der Security-Mailingliste Unterstützung aus der Community sucht.

Wie könnte eine solche Unterstützung aussehen - und wie würdet Ihr sicherstellen, dass vertrauliche Sicherheitslücken bei der Zusammenarbeit mit einer größeren Gruppe nicht sofort publik werden?

Zunächst geht es nur um die Betreuung unsere Eingangskanals security@lists.ilias.de. Hier sind z.B. Rückfragen zu stellen oder Rückmeldungen zu geben und die Meldungen in den Security-Bereich im Tracker einzustellen. Dafür brauchen wir zuverlässige Personen, die sich zeitnah um die eingehenden Meldungen kümmern können. Perspektivisch hoffen wir, eine Gruppe von fähigen Menschen zu formen, die auch weitergehende Aufgaben im Bereich Security, z.B. die Beantragung von CVE-Nummern, übernehmen kann.

Natürlich bedeutet das, dass die Mitglieder der Gruppe vertrauliche Informationen zu Gesicht bekommen werden und wir ihnen als TB dann auch vertrauen können müssen. Das heißt, wir werden sicherlich nicht einfach jeden zum Mitglied der Gruppe machen. Wir werden klare Verhaltensregeln und klare Prozeduren zum Ein- und Ausstieg aus der Gruppe schaffen. Dass dies funktionieren kann, zeigen viele größere und kleinere Open-Source-Projekte, die genau solche Gruppen haben.

Eine vielversprechende Verbesserung im Bereich "Usable for Everyone" ist, dass bei der Weiterentwicklung vermehrt auf das große Ganze und nicht nur auf isolierte Feature Requests geschaut wird. Das UI Framework („Kitchen Sink“) ist hierfür ein Paradebeispiel: Jedes neue Feature muss berücksichtigen, welche Interface-Elemente es benutzt und klären, ob ggf. Neuentwicklungen in diesem Bereich erforderlich sind.

Euer Wunsch im Review ist, dass die Kitchen Sink in der Konzeptphase noch besser genutzt wird. Wen sprecht Ihr mit diesem Wunsch genau an - und was können wir als ILIAS-Community-Mitglieder konkret tun, um unsere Feature Requests in diesem Bereich zu verbessern?

Über die Kitchen Sink stellen wir für Konzepter und Entwickler ein einheitliches Vokabular bereit, mit dem über unsere graphische Benutzerschnittstelle gesprochen werden kann. Wie du richtig schreibst, haben wir seit einiger Zeit in den Feature Requests entsprechende Abschnitte, um die GUI zu beschreiben. Hier kann das Vokabular genutzt werden, um zu beschreiben, was wann wie passiert: "Beim Klick auf den Primary Button öffnet sich ein Interruptive Modal mit folgendem Inhalt...".

Auf der anderen Seite haben wir mittlerweile einen großen Bestand an ILIAS-GUI-Elementen in der Kitchen Sink versammelt, der für neue Features genutzt werden kann. Dort ist jeweils der Zweck eines Elements beschrieben. So kann für neue Features auf bestehende Lösungen für GUI-Probleme zurückgegriffen werden, statt neue Elemente zu entwerfen, die ein Problem ein zweites Mal lösen.

Ein gutes Beispiel für diese Wiederverwendung ist das am 08.04. im Jour Fixe besprochene Feature "Global Starting Point for Course Registration", das die bestehende Komponente "Presentation Table" verwendet. Die Konzeptarbeit kann hier profitieren, da bestimmte Probleme einfach nicht mehr gelöst werden müssen. Im besten Fall kann aus den graphischen Darstellungen der bestehenden Elemente einfach ein Mock-Up für den Feature Request zusammenkopiert werden.

Im Bereich "Learning Everywhere Anytime" Eurer Strategie seht Ihr die geringsten Fortschritte. Es ging hier u.a. um die Unterstützung kleiner Bildschirme, aber auch um eine mögliche Offline-Funktionalität von ILIAS. Beide Bereiche wurden mit der Pegasus-App angegangen, die aber außerhalb Eurer Zuständigkeit liegt. Auch im Bereich "Page Layout Revision" war ein umfassendes Umdenken zu beobachten: Kleine Screens wurden in der Konzeption von Anfang an berücksichtigt.

Was bedeutet es, wenn Ihr nun darüber nachdenkt, diesen Bereich der Strategie zu überarbeiten und andere Schwerpunkte zu setzen? Die genannten Aspekte sind doch nach wie vor höchst bedeutsam - denkt Ihr, dass die Thematik in der Community ohnehin schon ausreichend beachtet wird?

Die genannten Aspekte sind in der Tat bedeutsam. Die Frage, die die Strategie beantworten soll, ist aber, wie wir uns hier weiterentwickeln können - welchen Weg vorwärts wir sehen. Die alte Strategie ist in dem angesprochenen Bereich leider sehr unkonkret und daher auch nicht hilfreich. Das wollen wir in der neuen Strategie ändern.

Als zwei wichtige Punkte, die in unserer alten Strategie keinen Platz gefunden haben, haben wir in vergangen zwei Jahren identifiziert: die Konnektivität mit anderen Systemen über APIs und die Organisation unseres client-seitigen Codes. Das sind zwei Bereiche, welche die Mobilfähigkeit unserer Software erhöhen werden und bei denen wir glauben, konkretere Ziele formulieren zu können als in der letzten Strategie.

Alle, die am Entwicklungsprozess von ILIAS beteiligt sind, wissen, dass Ihr unmöglich alle wünschenswerten Aufgaben erledigen könnt. So seht Ihr auch im Bereich "Beyond Standard" nur kleinere Verbesserungen. Hier stehen Plugins und Anpassungen am Look und Code im Vordergrund. Hattet Ihr Euch bei der Strategie 2017 zu viel vorgenommen? Und wird dies bei einer Überarbeitung der Strategie anders sein?

Ja, die Strategie 2017 hat letztlich mehr Ziele enthalten, als die Community und wir in den zwei Jahren seit ihrer Erstellung erreichen konnten. Wir sehen die Strategie allerdings nicht nur als Leitfaden für uns, sondern wünschen uns auch, dass andere Community-Mitglieder sie wahrnehmen und entsprechende Schwerpunkte in ihrer jeweiligen Arbeit setzen.

An einem Open-Source-Projekt wird letztlich immer von vielen Leuten mit unterschiedlichsten Ansprüchen gearbeitet und gezogen, so dass ein kohärentes Vorgehen der gesamten Community nicht das Ziel sein kann. Trotzdem glauben wir fest daran, dass wir gemeinsam mehr schaffen können als jeder allein - und versuchen dafür, unsere Überlegungen und Schwerpunktsetzungen mit Euch allen zu teilen. Dies geschieht in Form der Strategie, aber auch in anderer Form. Dabei nehmen wir auch Inputs aus der Community auf.

Wir werden hoffentlich auch in der nächsten Strategie wieder mehr Ziele formulieren, als wir erreichen können. Wenn das nicht so wäre, hätten wir wahrscheinlich das vorhandene Potential nicht ausgeschöpft.

Zum Abschluss bleibt mir nur zu sagen, dass ich Eure Arbeit und Eure transparente Berichterstattung darüber als Community-Mitglied sehr geschätzt habe. Ich freue mich sehr, dass vier von Euch für eine weitere Amtszeit antreten und Ihr mit Stephan Winiker einen fünften Mitstreiter gefunden habt. Vielen Dank für Euren Einsatz für ILIAS und auf zwei weitere erfolgreiche Jahre!

Auch wir freuen uns sehr, dass Stephan nun dabei ist und sind gespannt, was er beitragen wird. Den Dank kann ich nur zurückgeben, deine Arbeit im Blog ist zu einem wichtigen Teil unserer Transparenz geworden. Wir freuen uns auf die nächsten zwei Jahre mit euch allen!