Anders als die meisten Lehr-Lernplattformen und Kursmanagementsysteme, die sich momentan noch auf dem Markt behaupten können, wurde Stud.IP konsequent aus universitären Strukturen heraus ohne nennenswerte Finanzbeihilfen entwickelt. Der Grundstein wurde in einer Lehrveranstaltung am Göttinger “Zentrum für interdisziplinäre Medienwissenschaft (ZiM) im Wintersemester 1999/2000 gelegt, bei der jedoch bereits in der zweiten Sitzung die klassische Seminarstruktur zugunsten einer freien Arbeitsgruppe aufgegeben wurde. Gemeinsames Ziel der verschiedenen Gründungsmitglieder aus fünf verschiedenen Fachbereichen war die Einführung einer lehrunterstützenden Internetplattform auf Datenbankbasis und HTML-Oberfläche.

Die erste, für alle Veranstaltungen des ZiM im Wintersemester 2000/2001 eingesetzte Softwareversion (V 0.2), beinhaltet bereits wesentliche Elemente der jetzigen Software: Ein personalisiertes Vorlesungsverzeichnis mit der Möglichkeit für die Studierenden, ihre Studienplanung damit abzuwickeln sowie erste didaktische Werkzeuge innerhalb der einzelnen Veranstaltungen (Forensysteme, Dateiablage) zu nutzen. Die beiden Grundlinien, Motivation und Identifikation mit dem System durch Personalisierung sowie der rein unterstützende Ansatz von Präsenzlehre (mittlerweile bekannt als “blended learning”), waren klar erkennbar. Im Verlauf des Jahres 2001 kam es zu einem stetigen Anwachsen der Entwicklermannschaft und der ersten veröffentlichten Version auf http://sourceforge.net/projects/studip/.

Seitdem wurde der Funktionsumfang weiter ausgebaut, ohne dass von dem Konzept einer Mischung aus Verwaltungstool für die universitäre Lehre, Community-Plattform in Form eines virtuellen Kommunikations- und Aktionsraumes für alle Studierenden und Lehrenden sowie als eLearning-Umgebung zur Bereitstellung von Unterrichtsmaterialien abgewichen wurde.

Die Weiterentwicklung und Betreuung wurde im Jahr 2002 durch die Göttinger Firma data-quest vom ZiM übernommen, ferner wurde die Plattform in den Open-Source- Softwareverbund “CampusSource” aufgenommen – als bis dahin einzige, die nicht aus Nordrhein-Westfalen stammt. Ebenfalls im Jahr 2002 kam es zu einer ersten finanziellen Förderung in nennenswerter Höhe durch Drittmittel: im Rahmen des bmb+f Programmes “Notebook University” wurde Stud.IP Grundlage des Göttinger Antrages und um viele Funktionen für mobile Nutzungsszenarien erweitert (WAP-Schnittstelle, XML-Export, erweiterter Terminkalender mit Synchronisationsfunktionen, Literaturverwaltung mit Anbindung an Bibliothekssysteme u.v.a.).

Mit der ersten Stud.IP-Tagung am 24.09.2003 in Göttingen wurde ein weiterer Schritt in Richtung verteilter Entwicklung vollzogen: durch die neuen universitätsweiten Installationen der Software etwa in Osnabrück und Oldenburg wurden die Entwicklungskapazitäten weiter ausgebaut.

Im Frühjahr 2004 stellt sich Stud.IP als ausgereiftes Lernmanagementsystem mit umfassendem Funktionsumfang dar, das bundesweit von über 50.000 registrierten Studierenden und Lehrenden genutzt wird.

Grundgedanke von Stud.IP ist die Unterstützung universitärer Lehrveranstaltungen, nicht deren Ersetzung durch rein virtuelle Angebote. Zwar ist es möglich eigenständige Lernmodule in die Lernumgebung einzubinden, der Schwerpunkt liegt jedoch im Angebot von Werkzeugen für Didaktik und Administration.

Universitäre Lehrveranstaltungen sind in der Mehrheit in wöchentlichen Präsenzsitzungen organisiert: der Zeitraum zwischen den Sitzungen soll von den Studierenden zur Vor- und Nachbereitung genutzt werden. Eben hier liegen jedoch die Defizite der reinen Präsenzuniversität: viele Studierende nehmen nur die eigentlichen Seminartermine als “Studienzeit” war, die Sitzungen leiden in der Praxis an mangelnder Vor- und Nachbereitung seitens der Studierenden.

Diese “Lücke” zwischen den Präsenzterminen versucht Stud.IP zu schließen – die Themen der Veranstaltung sollen auch zwischen den Sitzungen präsent sein, im Forum diskutiert werden, im Wiki-System weiterentwickelt oder transparent vorbereitet werden, Thesenpapiere und Kommentare zeitig abrufbar sein.

Die Motivation der Studierenden, diese Angebote auch wirklich wahrzunehmen, wird durch zwei Strategien gesteigert: zum einen eine hohe Identifikation mit dem System durch starke Personalisierung (Real-Name-Pflicht, eigene Homepage, Community-Bereich), zum anderen Hilfe bei ungeliebten administrativen Aufgaben.

Dieser letzte Punkt motiviert auch die Lehrenden mit dem System zu arbeiten: die Seminarorganisation wird durch Ablaufpläne, Teilnehmerlisten, Zulassungsverfahren, ein Newssystem und vieles andere mehr, signifikant vereinfacht.

Durch die interdisziplinär zusammengesetzte Entwicklergruppe stellt Fachunabhängigkeit ein weiteres didaktisches Konzept von Stud.IP dar. Alle Funktionalitäten sollen nach Möglichkeit so flexibel konzipiert sein, dass sie nicht nur einem begrenzten Nutzerkreis dienlich sind, sondern gleichermaßen von Juristen, Wirtschaftswissenschaftlern, Naturwissenschaftlern, Medizinern und Geisteswissenschaftlern genutzt werden können. Auch auf den ersten Blick fachorientierte Funktionalitäten wie die systemweite TeX-Unterstützung (für den Bereich der mathematisch-naturwissenschaftlichen Fächer) offenbaren beim näheren Hinsehen Potential auch für andere Gebiete: etwa durch die Unterstützung von Notensatz oder die Einbettung arabischer Schriftzeichen. Durch die fachunabhängigen Funktionen finden die Nutzer ein einheitliches Bedienkonzept vor und müssen sich etwa als Magisterstudierende mit vielfältigen Fächerkombinationen nicht störenden Medienbrüchen stellen.

Eine der grundlegenden Entscheidung bei der Konzeption von Stud.IP wurde sehr früh getroffen: für die Entwicklung sollte ausschließlich auf Open-Source Komponenten zurückgegriffen werden, da diese nach Ansicht der Entwickler die passgenaueste Voraussetzung für Softwareentwicklungen an deutschen Hochschulen darstellt.

Als technische Basis dient ein klassisches LAMP-System: Linux als Betriebssystem (un-abhängig von der jeweiligen Distribution), ein Apache-Webserver, eine MySQL- Datenbank sowie PHP als eigentliche Skriptsprache. Das notwendige Sessionmanagement wird über eine leicht modifizierte Variante der PHPlib-Bibliothek realisiert und setzt Sessioncookies voraus. Durch Verwendung der PHPlib exisitiert eine Abstraktionsschicht für die Datenbankoperationen, sodass sich mit wenigen Modifikationen auch andere Datenbanken als MySQL einsetzen lassen.

Im Wesentlichen lassen sich drei unterschiedliche Implementierungen von Rechtesystemen in Lernmanagementsystemen unterscheiden:

Stud.IP setzt konsequent ein rollenbasiertes Rechtesystem ein, welches sich in den letzten Jahren gut bewährt hat: die Stukturen an deutschen Hochschulen sind relativ klar hierarchisch organisiert – von den Studierenden über Tutoren, wissenschaftlichen Hilfskräften hin zu Hochschullehrern, darüber noch eine Schicht von Administration und Verwaltung (etwa in den Dekanaten). Ebendiese Strukturen bildet Stud.IP 1:1 in der Plattform ab, wobei jeder Nutzer innerhalb seiner Rechterolle freien Handlungsspielraum genießt. Neben den Rollen prägen Institutionen die Hochschullandschaft: vom Lehrstuhl über das Institut bis zu Fakultät und Universität.

Die Rechte in Stud.IP leiten sich daher im Wesentlichen aus dem Dreieck Person/Rolle – Institution – Veranstaltung ab. Dieses Dreieck ist flexibel, ein und dieselbe Person kann somit in einer Einrichtung Dozent einer Veranstaltung sein und Autor etwa in einem Organisationsgremium einer anderen Einrichtung.

Derartige Konstruktionen lassen sich auch mit granularen Rechtesystemen umsetzen, jedoch sind diese wesentlich schwieriger zu bedienen, insbesondere bei rekursiven Strukturen wenig performant und von Laien nicht ohne weiteres zu warten. Dem Vorwurf, rollenbasierte Rechtesystem könnten Sonderfälle nicht flexibel genug abbilden kann entgegengehalten werden: in vier Jahren ist bei mehreren tausend unterstützten Veranstaltungen in Göttingen kein Fall aufgetaucht, der sich nicht hätte umsetzen lassen – zumal sich spezialisierte Rollen wie Raum- oder Bibliotheksadministratoren hinzufügen lassen.

Ein System mit dezidiert offener Rechtestruktur wird sich unserer Einschätzung nach im universitären Umfeld nicht durchsetzen können, da es zu viele Reibungspunkte mit den gewachsenen Universitätshierarchien aufweist.

Deutsche Universitäten präsentieren sich als besonders heterogenes Biotop von unterschiedlichen Befindlichkeiten und Vorlieben – auch und gerade im Bereich des Technikeinsatzes. Während man im Bereich der betrieblichen Weiterbildung den Angestellten klare Vorgaben in Bezug auf die zu verwendende Software stellt (die Arbeitsplatzrechner werden inklusive Software zur Verfügung gestellt), muss man bei Studierenden die unterschiedlichsten Vorlieben bei der Wahl von Betriebssystem, Browser etc. berücksichtigen, wenn man wirklich eine breite Nutzerschaft erreichen will.

Stud.IP beschränkt sich daher konsequent auf den Einsatz von reinem HTML. Einige Komfortfunktionen werden über Javascript angeboten. Das System lässt sich jedoch auch in vollem Umfang ohne derartige Erweiterungen oder gar Plug-Ins bedienen, was bei den Studierenden auf große Zustimmung stößt – müssen sie sich doch nicht darum kümmern ein Flash-Plugin zu installieren oder eine Java-Runtime einzurichten.

Bei der GUI-Gestaltung wird ferner großer Wert auf konsistente und intuitive Bedienung gelegt, als vages Vorbild dient die Bedienung von Apple-Software mit klarer Iconographie und haptischen Entsprechungen wie “aufziehen”. Dabei wird in Rechnung gestellt, dass Studierende noch immer nicht flächendeckend über Breitbandzugänge verfügen: als Grundlage für die Menge der zu übermittelnden Daten dient immer noch das 56K-Modem. Daher finden keine großformatigen Schmuckgrafiken oder aufwändige Animationen Verwendung, vielmehr werden kompakte, immer wiederkehrende Grafikelemente verwendet.

Eine kontextsensitive Hilfe leitet den Nutzer durch das System: auf jeder Seite steht ein Hilfetext bereit, der sämtliche Funktionalitäten des jeweiligen Bereiches erläutert.

Die Förderprogramme im Bereich eLearning der letzten Jahre haben für eine unüberschaubare Flut an Insellösungen gesorgt. Schon länger wächst das Bewusstsein, dass diese Einzelmodule zumindest integrierbar sein sollten, im besten Fall kombinierbar. Im Bereich der Lernmodule bilden sich Standards wie SCORM heraus, auf anderen Ebenen existieren zumindest allgemein akzeptierte Datenstrukturen wie XML.

Stud.IP trägt dieser Entwicklung Rechnung und bietet diverse Schnittstellen zur Anbindung anderer System an: einen XML-Export für Veranstaltungskommentare und Teilnehmerlisten, eine iCal-Schittstelle zum Austausch und Synchronisation von Kalenderdaten sowie eine XML-RPC Schnittstelle zur Anbindung von spezialisierten Clientsystemen und zur “Fernsteuerung” des Systems.

Eine besondere Bedeutung kommt der LDAP-Unterstützung zu, mit deren Hilfe sich die Nutzerdaten etwa mit dem Studentenwerk abgleichen lassen – ein wesentlicher Schritt in Richtung universitätsweitem ”single-sign-on”. Durch die PlugIn-Architektur der Nutzer-Authentifizierung ist mit geringfügigen Modifikationen auch eine Anmeldung gegen einen Radius-Server möglich.

Als sehr praxistauglich hat sich auch das Konfigurationsmodul für die Anbindung externer Seiten erwiesen: relevante Daten wie Veranstaltungskommentar, Newsmeldungen oder Mitarbeiterdaten lassen sich aus Stud.IP heraus in bestehende Institutsseiten oder CMS-Systeme einbinden. Das Design der heraus gespiegelten Daten kann nahtlos dem Design der anfordernden Seite angepasst werden.

Eine weitere, sehr praxistaugliche Lösung finden die Anwender in der z39.50-Schnittstelle, mit der sich beliebige Bibliothekskataloge - etwa die Bestände der Deutschen Bibliothek (ddb) – abfragen und die Ergebnisse in die Lernumgebung integrieren lassen.

Kernaufgabe von Stud.IP ist die Unterstützung universitärer Lehre. Die dafür angebotenen Werkzeuge lassen sich einteilen in didaktische und administrative, wobei die Grenze fließend verläuft und Synergien angestrebt werden: ein eher didaktisch orientiertes Werkzeug wie das Forensystem kann auch administrative Abläufe unterstützen, etwa bei Nachfragen zum Ablauf der Veranstaltung: es ist effektiver die häufig gestellten Fragen einmalig im Forum zu beantworten, als in jeder Sprechstunde aufs neue.

Allen Werkzeugen gemein ist, dass sie innerhalb der Seminarumgebung für jede einzelne Veranstaltung zur Verfügung stehen.

Im Laufe der Stud.IP-Entwicklung gewann die Unterstützung der verschiedenen universitären Verwaltungsebenen zunehmend an Bedeutung – nicht zuletzt, weil die universitätsweite Akzeptanz auch von der Verwaltung bestimmt wird und eine scharfe Abgrenzung zu rein didaktischen Bereichen weder möglich noch sinnvoll erscheint (siehe oben).

Mit dem dynamischen Vorlesungskommentar können universitätsweit oder nur für einzelne Bereiche alle Veranstaltungen nach verschiedenen Kriterien sortiert oder gruppiert ausgegeben werden, auch ein Export (etwa im XML-Format) steht zur Verfügung.

An die Veranstaltungsverwaltung gekoppelt ist eine komplexe Raum- und Ressourcenverwaltung, die sowohl ein Makro- (mit Hilfe eines zentralen Ressourcenadministrators) als auch ein Mikromanagement (Ressourcen wie Beamer können von Abteilungen eigenverantwortlich verwaltet werden) ermöglicht. Die Belegungspläne aller Ressourcen können öffentlich eingesehen werden.

Die Anbindung externer Seiten über eine SRI-Schnittstelle wurde bereits beschrieben, ein praktisches Werkzeug, um die Außendarstellung der Universität aktuell und einheitlich zu halten.

Das Konzept der Personalisierung als ein zentrales Motivationsprinzip zieht sich durch alle Bereiche des Stud.IP-Systems: Ziel ist es, dass “soziale System” Universität auch mit seinen Menschen abzubilden und nicht die Benutzung einer "kalten" Verwaltungssoftware zu erzwingen. Eine Vielzahl von Funktionen konzentrieren sich daher auf die einzelnen Nutzer:

Für jeden registrierten Nutzer wird eine persönliche Homepage eingerichtet, die ohne HTML-Kenntnisse gepflegt und mit beliebigen Inhalten bestückt werden kann. Beispiele sind Angaben zum Lebenslauf oder Studienschwerpunkten. In einem Gästebuch können sich Besucher verewigen, großer Beliebtheit erfreuen sich auch die persönlichen Umfragen und Tests.

In speziell eingerichteten Community-Veranstaltungen kann losgelöst vom Fach oder der Veranstaltung mit anderen Nutzern über politische oder kulturelle Dinge debattiert werden. Dieses ist in vielen Fällen der zwanglose “Einstieg”, um sich mit den grundlegenden Funktionen der Plattform vertraut zu machen.

Der persönliche Terminkalender bietet weitreichende Organisationsmöglichkeiten. Die einzelnen Präsenzsitzungen werden automatisch eingetragen, eigene private Termine können ergänzt werden.

Auf der “Wer ist online”-Seite sieht man, wer außer einem selbst gerade im System eingeloggt ist. Auf der Score-Liste treten die Nutzer, wenn sie möchten, in einen humorvollen Wettbewerb um den höchsten Aktivitätswert im System.

Im Adressbuch werden die Kontaktdaten anderer Nutzer gesammelt und automatisch aktualisiert, wenn die eingetragenen Nutzer etwas an ihren eigenen Daten ändern. Die Einträge können in Gruppen organisiert und mittels vCard-Export in Organizer übertragen werden.

Im systemweiten, veranstaltungs- oder personenbezogenen Chat kann synchron kommuniziert werden. Ferner existiert ein systeminternes Nachrichtensystem mit aktivierbarer Mailweiterleitung zur asynchronen Kommunikation.

Generell gilt im Stud.IP-System: alles was gesagt und getan wird, wird von jemandem gesagt und getan. Durch die Realnamepflicht reicht ein Klick auf den Benutzernamen, um die persönliche Homepage aufzurufen. Das System erhält dadurch einen freundlichen und lebendigen Anstrich. Beispielsweise fällt die inhaltliche Bewertung von Diskussionbeiträgen aufgrund der zusätzlichen Informationen über den Autor leichter.

Besonders bei der Weiterentwicklung und der Qualitätssicherung kann es zu Zielkonflikten zwischen dem Open-Source-Ansatz "jeder kann partizipieren" und den Ansprüchen der Stud.IP-Betreiber (z.B. Rechenzentren) nach garantierter Qualitätssicherung, ständig verfügbarem Support und verbindlichen Ansprechpartnern kommen. Deshalb wird bei Überlegungen zur Anschaffung von Open-Source-Software immer wieder die Kritik geäußert, dass durch fehlende Organisationsstrukturen und fehlendem Support der Einsatz mit einem Risiko behaftet sei. Im Folgenden zeigen wir, dass diese Bedenken bezüglich des Einsatzes von Stud.IP als Open-Source-Software an zentraler Stelle in der Organisation einer Hochschule unbegründet sind. Dieses erreichen wir durch transparente Organisationsstrukturen bei Weiterentwicklung und Qualitätskontrolle sowie durch das Angebot eines geregelten Supports.

Wenngleich Stud.IP unter einer Open-Source-Lizenz steht, so handelt es sich keinesfalls um “Freeware”, für die sich niemand verantwortlich fühlt. Die data-quest GmbH hat Stud.IP in großen Teilen entwickelt und bietet Betreibern all jene Support-Leistungen an, welche oft nur von Closed-Source-Anbietern erwartet werden. Daneben werden spezielle Modifikationen und umfangreiche Weiterentwicklungen für die Betreiber angeboten. Generell lässt sich feststellen, dass Betreiber, Entwickler und Nutzer einer eLearning-Plattform unterschiedliche Anforderungen an Nachhaltigkeit und Support stellen.

Bei den Betreibern von Stud.IP handelt es sich in der Regel um Hochschul-, Fakultäts- oder Institutsleitungen, welche die technische Verantwortung für den Betrieb des Systems an Rechenzentren oder EDV-Abteilungen delegieren.

Die data-quest GmbH informiert die Betreiber über anstehende Entwicklungen, Updates oder Bugs. Auf Wunsch werden auch Backups der Systeme durchgeführt. Daneben werden die Betreiber über Wünsche und Weiterentwicklungen Dritter informiert, sodass sich Interessengruppen bilden können. Hierdurch lassen sich gemeinsame Entwicklungen koordinieren, Arbeiten verteilen und damit Kosten für die Betreiber einsparen. Daneben bietet sich die Möglichkeit, gemeinsam Drittmittelanträge zu stellen.

Betreiber können Supportverträge mit der data-quest GmbH abschließen. Der Support umfasst jene Stud.IP-Versionen, welche unter http://sourceforge.net/projects/studip oder http://www.campussource.de von der data-quest GmbH publiziert wurden. Diese Verträge können technischen und/oder administrativen Support umfassen. Grundlage der Verträge ist ein Support-Punkte-System, wobei der tatsächlich geleistete Zeitaufwand abgerechnet wird. Die Abrechnung erfolgt viertelstundenweise. Reaktionszeiten sind vertraglich geregelt und liegen an Werktagen bei maximal vier Stunden. Der Bearbeitungszustand von Supportanfragen und alle gestellten Anfragen und deren Lösungen können in einem Statustracking-System verfolgt werden. Bei Bedarf lassen sich auch individuelle Supportverträge mit der data-quest GmbH aushandeln.

Neben den Entwicklern der data-quest GmbH und der Göttinger Universität, entwickeln zunehmend Programmierer anderer Hochschulen mit an der Software. Daneben gibt es einige Privatpersonen (meist Studenten), die sich an der Entwicklung beteiligen. Insgesamt zählt die Entwickler-Community derzeit ca. 15 bis 20 Personen.

Die Entwicklung wird über einen eigens eingerichteten “Developer-Server” (http://develop.studip.de) koordiniert.

Für die Entwickler wurde eine eigene Stud.IP-Installation eingerichtet. Diese enthält den jeweils tagesaktuellen Entwicklungsstand der Software. Hier finden sich alle Richtlinien, die von den Entwickler zu beachten sind. Diese betreffen z.B. Codestyle, Internationalisierung, Sonderzeichenbehandlung und Kommentierungen. Das Bugtracking erfolgt ebenfalls auf der Developer-Installation. Bugs werden hier in einem Forum eingestellt, bewertet und die zuständige Person zur Behebung aufgefordert. Hieraus ergeben sich regelmäßig Diskussionen unter dem Aspekt “Bug oder Feature”. Die Nutzung einer Stud.IP-Installation für die Weiterentwicklung der Plattform gewährt ein umfangreiches Testen des Systems bereits während der Entwicklung.

Das stets aktuelle CVS ist generell für jeden mit einem Lesezugriff freigegeben. Die externen Entwickler “ziehen” sich einen CVS-Snapshot, machen ihre Weiterentwicklung und liefern ein kommentiertes Diff an data-quest. Hier werden die externen Komponenten einer Qualitätskontrolle unterzogen und in die offiziellen Modulen des Stud.IP-CVS eingearbeitet.

Entwicklungen, welche keiner Qualitätskontrolle von data-quest unterzogen wurden, können im CVS-Modul “Stud.IP-unsupported” ebenfalls der Allgemeinheit zur Verfügung gestellt werden. Für diese Entwicklungen kann natürlich keine Gewährleistung und kein Support übernommen werden.

Dokumentationen zur Entwicklungen lassen sich für Entwickler und Interessierte über die Systeme PHPDoc und Xref einsehen.

Das offizielle Release einer neuen Stud.IP-Version erfolgt zweimal jährlich bei Sourceforge (http://sourceforge.net/projects/studip) und bei CampusSource (www.campussource.de). Service-Releases mit Bugfixes erscheinen bei Bedarf. Da Stud.IP bisher hauptsächlich an Hochschulen zum Einsatz kommt, orientiert sich der Release-Zyklus am hochschulspezifischen Halbjahresrhythmus. Die Entwicklung findet auf dem Entwickler-System statt, anschließend werden die Neuentwicklungen vor Semesterbeginn an der Universität Göttingen auf dem Produktivsystem installiert. Hier erfolgt nun der abschließende “Test” für den Produktiveinsatz durch derzeit fast 9.000 Nutzer. Unter Umständen werden Hotfixes für diese Installation im laufenden Semester vorgenommen. Gegen Ende des Semesters wird abschließend von data-quest ein Release veröffentlicht.