Hunderttausende Studierende loggen sich täglich in Stud.IP ein, klicken durch Veranstaltungen, laden Dateien hoch, schreiben im Forum. Stud.IP ist eine quelloffene Lernplattform (Campus-Management-System), die an zahlreichen deutschen Hochschulen im Einsatz ist. Doch wie entsteht eigentlich die Software dahinter? Die Stud.IP Kernentwicklung folgt Regeln, die man bei Open-Source-Projekten selten findet – und genau das macht sie so besonders.
Wer über die Stud.IP Kernentwicklung spricht, muss zunächst verstehen, dass nicht alles gleich ist. Die Software unterscheidet klar zwischen Kern und Plugins.
Der Kern bildet das Fundament. Hier steckt alles drin, was Stud.IP zu Stud.IP macht: Wie funktioniert das Login? Wie greift die Software auf die Datenbank zu? Wie werden Nutzerinnen und Nutzer authentifiziert? Dazu kommen Module, die so grundlegend sind, dass sie einfach dazugehören: das Forum, der Chat „Blubber", die Dateiablage.
Plugins hingegen sind Erweiterungen. Sie docken an den Kern an, erweitern ihn, passen ihn an lokale Bedürfnisse an. Der entscheidende Unterschied: Was in den Kern kommt, muss höchsten Qualitätsansprüchen genügen. Plugins sind freier, aber auch auf sich gestellt. Wenn ein Plugin nicht mehr gepflegt wird, ist das Problem der Hochschule, die es nutzt. Beim Kern gibt es diese Garantie: Hier kümmert sich immer jemand.
Wer entscheidet, was in den Stud.IP-Kern darf? Das ist die Stud.IP Core-Group, ein Gremium aus aktuell 19 Personen. Sie kommen von verschiedenen Hochschulen, von Dienstleistern wie data-quest oder dem elan e.V., manche sind Entwickler:innen, andere Didaktiker:innen, wieder andere kümmern sich um Dokumentation oder Übersetzungen.
Vom elan e.V. sitzen Till Glöggler, Ron Lucke und Marcus Eibrink-Lunzenauer in der Core-Group. Sie bringen ein, was sie aus der täglichen Arbeit mit Open-Source-Software für Hochschulen kennen. Mehr über die Menschen und Organisationen hinter Stud.IP erfahrt ihr in unserem Artikel „Wer steckt eigentlich hinter Stud.IP?".
Die Core-Group trifft sich einmal im Monat online, dazu ein- bis zweimal im Jahr in Präsenz. Der tägliche Austausch läuft über Element, einen Messenger. Entscheidungen fallen demokratisch: Ein neues Feature braucht mehr Ja- als Nein-Stimmen. Wer neu in die Core-Group aufgenommen werden will, braucht eine Zweidrittelmehrheit.
Das klingt bürokratisch? Ist es auch. Und zwar mit Absicht. Denn was einmal im Kern landet, bleibt dort. Und muss funktionieren. Für Hunderttausende.
Angenommen, jemand hat eine Idee. Ein neues Modul, eine bessere Funktion, eine Überarbeitung von etwas Bestehendem. Wie wird daraus ein Teil von Stud.IP?
Der Prozess beginnt mit einem StEP – einem Stud.IP Enhancement Proposal. Das ist im Grunde ein strukturierter Vorschlag, der mehrere Fragen beantwortet:
Der letzte Punkt ist entscheidend. Bei Stud.IP gibt es niemanden, der sagt: „Tolle Idee, das bauen wir für dich." Wer einen StEP einreicht, muss selbst – oder mit einem Auftraggeber im Rücken – für die Umsetzung sorgen. Erst wenn das geklärt ist, geht es weiter.
Der StEP wird im GitLab eingetragen und automatisch im Forum auf develop.studip.de veröffentlicht. Dann beginnt die Diskussion. Jeder kann mitdiskutieren, Fragen stellen, Bedenken äußern. Wenn alle offenen Punkte geklärt sind, stimmt die Core-Group ab.
Wird der Vorschlag angenommen, startet die eigentliche Arbeit. Wer den gesamten Weg von der ersten Idee bis zum fertigen Feature im Detail nachvollziehen möchte, findet in unserem Artikel „Von der Idee zum Feature" eine ausführliche Beschreibung.
Ein angenommener StEP ist noch lange kein fertiges Feature. Der Code wird in einem eigenen Branch entwickelt und dann beginnt die Qualitätssicherung. Sie umfasst acht Kategorien, jede mit eigenen Verantwortlichen aus der Core-Group:
Für jede Kategorie vergibt der oder die Verantwortliche ein Plus oder ein Minus. Minus heißt: Nacharbeiten. Plus heißt: Diese Hürde ist genommen. Erst wenn alle acht Kategorien grünes Licht geben, darf das Feature in den Kern.
Aber selbst dann ist noch nicht Schluss. Zweimal im Jahr erscheint eine neue Stud.IP-Version. Vor jedem Release gibt es Beta-Tests – und die finden nicht in einer Laborumgebung statt, sondern an echten Hochschulen mit echten Studierenden.
Warum das wichtig ist? Weil keine Testumgebung simulieren kann, was passiert, wenn plötzlich 10.000 Menschen gleichzeitig dieselbe Funktion nutzen. Wenn nicht 50 Dateien im Dateibereich liegen, sondern 50.000. Wenn Studierende Dinge tun, an die bei der Entwicklung niemand gedacht hat.
Die Beta-Hochschulen installieren die neue Version früher als alle anderen und melden zurück, was funktioniert und was nicht. Erst danach geht die Version für alle live.
Bei all dem technischen Prozess könnte man fast vergessen, dass hinter Stud.IP eine Idee steht. Die Stud.IP-Philosophie umfasst sieben Grundsätze, die jede Kernentwicklung erfüllen muss. Ein Feature, das ihnen widerspricht, wird abgelehnt – die Philosophie ist keine Empfehlung, sondern ein Ausschlusskriterium.
Zwei davon stechen besonders hervor:
Gleichheit. Alle Nutzenden haben dieselben Grundfunktionen. Es gibt kein Premium-Modell, keine Studierenden erster und zweiter Klasse. Ein Feature, das manche bevorzugt behandelt? Kommt nicht in den Kern.
Keine Überwachung. Studierende dürfen nicht getrackt werden. Learning Analytics, die das Verhalten von Studierenden aufzeichnen, um ihnen „bessere Ratschläge" zu geben? Im Kern verboten.
Wer solche Funktionen dennoch braucht, kann sie als Plugin entwickeln. Aber der Kern bleibt sauber. Das ist ungewöhnlich für ein Open-Source-Projekt. Und genau das macht Stud.IP besonders.
Die restlichen fünf Grundsätze der Stud.IP-Philosophie findet ihr hier.
Nicht jedes Feature beginnt seinen Weg als StEP. Manchmal existiert ein Plugin bereits, wird an einzelnen Hochschulen genutzt und erweist sich als so nützlich, dass immer mehr Standorte es haben wollen. Erst dann – wenn der Bedarf breit genug ist – durchläuft es den regulären Aufnahmeprozess und wird offiziell Teil des Kerns.
Ein Beispiel ist Vips, das Aufgabentool für Tests und Übungsblätter. Es existierte bereits vor über 15 Jahren als eigenständiges System und wurde über viele Jahre als Plugin gepflegt und weiterentwickelt. Irgendwann war die Nachfrage an den Hochschulen so groß, dass es Sinn ergab, Vips fest in den Kern zu integrieren – mit allen Qualitätsanforderungen, die dazugehören.
Ähnlich lief es bei Courseware, dem Modul für multimediale Lerneinheiten. Courseware wurde 2016 als eigenständiges Plugin veröffentlicht, wuchs durch den Einsatz an zahlreichen Hochschulen kontinuierlich und wurde 2021 nach einer umfangreichen technischen Neuentwicklung fester Bestandteil von Stud.IP – erstmals ausgeliefert mit Version 5.0.
Der Weg in den Kern ist in beiden Fällen derselbe wie bei jedem neuen Feature: Diskussion, Abstimmung, Qualitätssicherung, Beta-Test, Release. Keine Abkürzungen – nur ein anderer Ausgangspunkt für die Stud.IP Kernentwicklung.
Die kurze Antwort: alle.
Die etwas längere: Es hilft, wenn man Interesse zeigt und sich einbringt. Wer regelmäßig in Diskussionen auftaucht, Fehler meldet, Dokumentation verbessert oder Code beisteuert, wird irgendwann wahrgenommen. Und irgendwann schlägt jemand aus der Core-Group vor, diese Person aufzunehmen.
Programmierkenntnisse sind dabei keine Voraussetzung. Die Core-Group braucht Menschen, die Code reviewen – aber auch Menschen, die Barrierefreiheit prüfen, Übersetzungen anfertigen, Dokumentation schreiben oder strategische Entscheidungen mitgestalten.
Der Einstieg ist niedrigschwellig:
Wer fragt, bekommt Antworten.
Die Stud.IP Kernentwicklung ist gründlich – aber sie ist auch langsam. Kommerzielle Anbieter können Features in Wochen ausrollen. Bei Stud.IP dauert es Monate, manchmal länger.
Das ist der Preis für Qualität. Für die Garantie, dass etwas funktioniert, bevor es bei Hunderttausenden landet. Für die Sicherheit, dass der Kern nicht von heute auf morgen anders aussieht.
Es ist auch der Preis für Unabhängigkeit. Stud.IP gehört keinem Konzern. Es gibt keinen Investor, der auf schnelle Releases drängt. Die Hochschulen, die Stud.IP nutzen, finanzieren die Entwicklung – und bestimmen mit, wohin die Reise geht.
Was ist ein StEP bei Stud.IP? Ein Stud.IP Enhancement Proposal (StEP) ist ein strukturierter Vorschlag für ein neues Feature oder eine Änderung am Kern. Er beschreibt, was entwickelt werden soll, warum es sinnvoll ist und wer die Umsetzung übernimmt.
Wer entscheidet, was in den Stud.IP-Kern kommt? Die Stud.IP Core-Group, ein Gremium aus 19 Personen von Hochschulen und Dienstleistern, stimmt demokratisch über jeden StEP ab.
Wie oft erscheint eine neue Stud.IP-Version? Zweimal im Jahr, jeweils nach einer Beta-Testphase an ausgewählten Hochschulen.
Kann ein Plugin später Teil des Stud.IP-Kerns werden? Ja. Wird ein Plugin an vielen Hochschulen genutzt und sehr erfolgreich, kann es nachträglich in den regulären Aufnahmeprozess überführt und Teil des Kerns werden – wie es bei Vips und Courseware der Fall war.
Die Stud.IP Kernentwicklung ist aufwendig, reglementiert und manchmal zäh. Aber genau deshalb funktioniert sie. Seit über 25 Jahren.
Für den elan e.V. ist die Mitarbeit an dieser Kernentwicklung Teil unserer Arbeit für Open-Source-Software in der Hochschullehre. Drei unserer Mitarbeiter sitzen in der Core-Group und gestalten mit, was morgen auf den Laptops der Studierenden landet.
Wenn ihr mehr darüber erfahren möchtet, wie Stud.IP funktioniert, oder selbst einsteigen wollt: develop.studip.de ist ein guter Anfang. Oder sprecht uns einfach direkt an.
