Wir haben schon lange ein Modell für die Verteilung von Verantwortung in der Kernentwicklung von ILIAS – das Maintainermodell. Für Komponente XY ist Person Z Maintainer*in, das bedeutet, dass der- oder diejenige zusammen mit Matthias alle Entscheidungen trifft, die in dieser Komponente zu treffen sind. Das hat sich nach meiner Beobachtung schon in der Vergangenheit als kompliziert herausgestellt für die Komponenten, die Querschnittsfunktionalitäten abbilden, wie bspw. das UI Framework, weil es da sehr, sehr viele Leute betrifft wenn etwas getan wird.

Zusätzlich ist es so, dass sich Softwareentwicklung in den Tätigkeiten, die ausgeübt werden, deutlich diversifiziert hat. Wenn es früher, etwas überspitzt, nur eine Person gab, die alles gemacht hat, gibt es jetzt viele Gewerke, die an der Softwareentwicklung teilnehmen. Leute die nur Qualitätssicherung machen, Leute die nur die Oberfläche bearbeiten, Leute die nur fachliche Themen bearbeiten, usw. Und auch dem wird das Maintainermodell nicht gerecht, da es verlangt, dass alle Aufgaben in einer Person vereint sind.

Für das UI Framework hatten wir bereits das Koordinatorenmodell eingeführt - da war die Idee, dass die oder der Koordinator*in offen ist für Beiträge von anderen und den Vorgang der Entwicklung koordiniert und nicht alles alleine macht und alleine entscheidet. Die Entscheidungen werden stattdessen gemeinsam im Jour Fixe getroffen.

Das Authorities-Modell ist eine Weiterentwicklung des Maintainermodells. Die Berechtigungen, die ein*e Maintainer*in bisher hatte, werden in vier Teile aufgeteilt. Sie können auch weiterhin von einer Person innegehalten werde, können aber jetzt auch an Einzelpersonen vergeben werden. Die Berechtigungen sind:

1. Code einführen dürfen,
2. Features einführen dürfen,
3. bestimmen zu dürfen, wer die anderen Authorities innehat und
4. über Testcases zu entscheiden.

Das eröffnet uns den Raum, um auch andere Modelle zu dokumentieren, die wir schon haben, wie zum Beispiel im Test & Assessment.

Wir befinden uns gerade noch in der Diskussion und warten einige Rückmeldungen ab. Das Vorgehen hat aktuell der Vorstand übernommen, damit es nun bald einen Abschluss findet.

Wir entwickeln unsere Software nicht von Grund auf selbst. Betriebssysteme, Datenbanken, Web Server etc. sind alles Komponenten, die nicht bei uns liegen. Ein Beispiel wäre Single Sign-on (SSO) – da braucht es Kryptographie, Mathematik, XML und so weiter. Es macht keinen Sinn, wenn jede Software das selbst entwickeln würde. Es gibt also Leute, die für bestimmte Funktionen Code bereitstellen, den man integrieren und nutzen kann.

Das ist auf der einen Seite sehr schön, weil man sich die Arbeit nicht selbst machen muss. Auf der anderen Seite birgt es aber natürlich auch eine Gefahr. Wir als Softwareentwickler*innen sind dazu aufgefordert, gut zu überlegen, auf was wir uns verlassen und was wir nutzen wollen.

Unsere ganze Umwelt ist irgendwie mit IT vernetzt und wenn ein Fehler alles zusammenbrechen lässt, ist das ein Problem. Das hat auch der Gesetzgeber erkannt und ich erwarte, dass wir bald gesetzlich verpflichtet sein werden, zu schauen, auf wen wir uns verlassen. Vorbote hierfür sind beispielsweise Fragebögen, die wir als Softwareanbieter schon jetzt ausfüllen müssen, zum Beispiel vom Bundesamt für Sicherheit in der Informationstechnik. In diesen Fragebögen wird abgefragt, ob wir wissen, aus welchen Teilen unser Programm eigentlich besteht.

Und dieses Thema können wir als Community gut angehen. Schon seit längerem existiert der Vorgang, dass wenn Code von wem anders neu aufgenommen werden soll, der gemeinsam im Jour Fixe bewertet wird. Es kann jedoch sein, dass wir vor 10 Jahren Code aufgenommen haben, auf den wir uns immer noch verlassen. Vielleicht macht derjenige, der den Code erstellt hat, aber mittlerweile etwas ganz anderes.

Jetzt geht es also darum, dass wir nicht nur einmal beim Aufnehmen schauen, ob ein Stück Code in Ordnung ist, sondern dass wir auch regelmäßig den Code, den wir schon verwenden, überprüfen. Wir müssen gemeinsam darauf schauen. Solche Entscheidungen sollten nicht ohne Rücksprache getroffen werden, denn es geht letztlich um eine Risikoabwägung: wie sehr kann man sich auf die Leute verlassen? Ist der Code so wichtig, dass wir uns darauf verlassen wollen? Was könnte passieren, wenn es das nicht mehr gibt? Was wären dann die Schritte? Kann man das einfach abschaffen oder müssen wir das dann selbst bauen? Gibt es Alternativen?

Diese Art der Risikoabwägung wollen wir jetzt regelmäßig machen und haben das letztens auch zum ersten Mal gemacht.

Ich glaube schon, weil man sich für das Thema warmlaufen muss. Vorschläge für die zur Wahl stehenden Technical Board-Mitglieder können beim Vorstand eingereicht werden. Der prüft die Vorschläge und stellt mögliche Mitglieder zur Wahl. Ich glaube es ist wichtig, dass man eine gewisse Bekanntheit in der Community hat, bevor man sich bewirbt. Wenn man sich also überlegt zu kandidieren, wäre es eine gute Idee sich jetzt schon zu überlegen: Was muss ich machen, um sichtbar zu werden? Was sind Themen, um die ich mich kümmern kann? Kann ich vorher schon zum Beispiel auf der Dev Conf (Entwicklerkonferenz) darüber reden? Kann ich mich irgendwie positionieren?

Ich glaube, wir hatten bisher nur ein einziges Mal eine echte Wahl. Ansonsten ist es immer so, dass wir Probleme hatten, geeignete Kandidat*innen zu finden – Kandidatinnen wären übrigens mal sehr schön. Was passiert also, wenn ich mich im September dafür entscheiden würde, nicht mehr zu kandidieren oder auch jemand anderes – gibt es dann überhaupt noch fünf Leute, die das machen wollen?

Es wäre also für uns als Community wichtig, dass wir einen sichtbaren Pool an Leuten haben, die sich als Technical Board-Mitglieder anbieten würden. Auf die auch der Vorstand direkt zugehen könnte.

Wenn ihr Lust habt oder wenn ihr euch vorstellen könnt, beim Technical Board mitzuwirken, dann sprecht uns gerne an. Wir können ins Gespräch darüber kommen, was wir aktuell machen, was die Möglichkeiten sind, was die Zeit ist, die dafür aufgewendet werden möchte. Keiner von uns macht das ehrenamtlich, also in der Freizeit. Das heißt, es wird dann auch bei allen potentiellen Kandidat*innen – hoffe ich – ein Thema sein, zu schauen, ob ihre Organisation das mit Arbeitszeit sponsoren kann.

Und sprecht auch gerne mit uns darüber, was ihr dafür tun könnt, um euch vorzubereiten. Wir wollen gerne, dass mehr Leute zur Wahl stehen, als dann letztlich gewählt werden. Wir wollen auch alle gerne das Gefühl haben, dass es nicht an uns persönlich hängt, ob wir uns nochmal zur Wahl stellen, weil sonst keine fünf Leute zu finden sind.

Der Name Technical Board führt vielleicht ein bisschen auf eine falsche Fährte. Es ist nicht so, dass wir nur Programmierer*innen sind. Beschäftigung mit Code ist sicherlich ein Thema, aber ganz viel reden wir auch über Prozesse oder über andere Themen, die nur am Rande mit Code zu tun haben. Das heißt es sind durchaus auch Leute angesprochen, die sich selber nicht als Entwickler*in sehen.