Es hat zwar etwas gedauert, aber besser spät als nie. Stud.IP 1.6 steht ab sofort auf den Servern von SourceForge zum Download bereit. Eine Liste der Neuerungen befindet sich in der History.

Fehlerfreie Software gibt es ja bekanntlich nicht, aber Stud.IP ist schon dicht dran. Zumindest wurden wieder einige Bugs aufgespürt und erlegt. Ab sofort liegt die aktualisierte Version 1.5.0-2 auf den SourceForge-Servern zum Download bereit.

Ich glaube ja eigentlich nicht an solchen Schnickschnack, aber wenn man ein Zeichen, einen Wink und nicht nur einen kleinen sondern schon den sprichwörtlichen mit dem Zaunpfahl bekommt, sollte man der Sache vielleicht doch mal nachgehen und seiner Bestimmung folgen. Vorhin haben wir in gemütlicher Runde das Gummibären-Orakel befragt. Es ging der Reihe nach und die Runde staunte. Das Orakel kannte uns alle! Die Deutungen des Orakels stimmten meist zu 109%. Ich war an der Reihe und zog: “Zwei rote, ein gelbes, ein weißes und ein orangenes Bärchen”.

Das sei die Lieblingskombination von Alfred Hitchcock, sagt das Orakel!

Mir schwante nichts Gutes. Irgendwie hatte ich es ja schon immer gespürt: Irgendetwas stimmt in meiner Umgebung nicht. Ich konnte bisher nur nicht genau sagen was es ist, nur so ein ständiges ungutes Gefühl in der Magengegend.

Unsere Gäste sind längst gegangen und ich sitze am Computer und surfe etwas ziellos kreuz und quer durchs Internet. Im Hinterkopf geistert immer noch der Spruch des Orakels umher und treibt sein Unwesen.

Ich bin auf den Seiten von SourceForge angekommen, und freue mich über die Stud.IP-Downloadzahlen. Die Version 1.5 ist seit 4 Wochen online und wurde bereits 400 mal herunter geladen. Die vorherige Version hat es auf über 3000 Downloads geschafft. Plötzlich habe ich einen Satz von der letzten Tagung wieder im Ohr, ich glaube, er war von Marco:
“Es gibt ca. 60 bekannte Stud.IP Installationen.”

Die Zahlen passen doch irgendwie nicht zueinander. Da ist eine Differenz von 340 bzw. sogar 2940. Ich bekomme eine Gänsehaut – die Nackenhaare stellen sich auf. Sie können doch nicht zu Dutzenden von schwarzen Krähen angefallen oder schlimmer noch hinter Duschvorhängen … ich kann gar nicht dran denken. Tausend Gedanken schwirren mir plötzlich durch den Kopf. Irgend jemand lädt da junge ahnungslose Stud.IP’s herunter und lässt sie verschwinden. Gibt es irgendwo ein schwarzes Loch in den Weiten des Internets, in das sie wie die Lemminge einer nach dem anderen hineinmarschieren? Oder steckt da etwa die Konkurrenz dahinter? Aber nein, so verzweifelt kann sie doch noch nicht sein, dass sie Stud.IP’s fängt und für Experimente in kleine Käfige steckt, verkabelt und beobachtet?
Schnell bin ich bei google und fange an zu suchen. Aber was ich auch eingebe, es werden nicht wirklich mehr … Als letzten Versuch richte ich eine Mailadresse ein:

vielleicht haben es ja doch ein paar geschafft und konnten sich befreien und/oder entkommen …
Voller Frust beiße ich den Orakelbären erst den Kopf ab und verschlinge sie dann ganz.
So, selbst schuld!

Der große Vorteil von Open-Source-Projekten ist die dahinterstehende Manpower. Durch die Mitwirkung vieler Freiwilliger fließen mehr Personenstunden in den Code und das Testing, als ein einzelnes Unternehmen es sich jemals leisten könnte.
Nunja, vielleicht mit Ausnahme von MicroSoft und Google.

Nehmen wir mal an, ein Unternehmen möchte Stud.IP nachprogrammieren.
Von Grund auf.
Was müsste dafür investiert werden?
Die Antwort liefert OhlOH, ein Web 2.0-Service der lustigeren Sorte. OhlOh wird mit den Daten eines Entwicklungssystem gefüttert.

Ein solches Entwicklungs- oder Versionsverwaltungssystem muss man sich wie eine Werft vorstellen. Darin liegt die Software (das Schiff) im Trockendock. Alle Entwickler arbeiten daran, verbessern hier was, fügen dort neue Teile hinzu oder schrauben einfach ein wenig herum. Dabei steht der Werftvorarbeiter hinter den Schraubern und protokolliert jede einzelne Änderung akribisch auf seinem Klemmbrett. Sollt nun durch ungeschickte Schrauberei das Heck des Schiffes versehentlich explodieren, kann der Vorarbeiter alarmiert und auf Knopfdruck alle Änderungen rückgängig gemacht werden um den alten Zustand wieder herzustellen.
Die Werft kann noch mehr, aber das interessiert hier gerade nicht.
Wichtig ist, dass in dem Entwicklungssystem der gesamte Code liegt, sowie die Informationen wer-was-wann-wo-gemacht hat.

OhlOh wertet Informationen von Entwicklungssystemen (unseres heist übrigens SUBVERSION – wie auch sonst, knick-knack, sie wissen schon) aus und stellt die Ergebnisse zur Verfügung.
Dennis Reill, vormals Mitglied der Stud.IP CoreGroup, hat OhlOh mal mit den Daten des Stud.IP-Versionsverwaltungs- und Entwicklungssystems gefüttert. Die Ergebnisse sind durchaus interessant und führen einem mal wieder vor Augen, wieviel eigentlich in Stud.IP steckt.

Um auf die Frage zurückzukommen, was man investieren müsste um Stud.IP neu zu schaffen:
Stud.IP soll, allein von der investierten Arbeitszeit her, 4.6 Millionen Dollar wert sein. Das entspricht etwa 3.407.750 Euro (oder 345.887.800 Angolanischer Kwanza).
Zumindest wenn man davon ausgeht, dass ein Programmierer rund 50.000 US-Dollar pro Jahr verdient. Tatsächlich sind deutsche Programmierer besser bezahlt als Ihre amerikanischen Kollegen. Nimmt man die c´t-Gehaltsstudie für Angestellte als Grundlage, kommt man bei einem durchschnittlichen Gehalt auf einen Wert von rund 4,8 Millionen Euro (das entspricht rund 428.404.541 Bangladeschischer Taka).
Beeindruckend, nicht wahr?

Man bräuchte rund 84 Mannjahre an Arbeitszeit, rechnet OhlOh aus, um die 320.000 Zeilen Code nachzuprogrammieren. Außerdem stellt die Seite gleich noch ein Zeugnis für das Projekt aus, prophezeit die Zukunft und gibt Statistiken an, wer wohl der fleissigste Programmierer ist.

Alles in allem ein netter Spaß, den sich jeder mal ansehen sollte: http://www.ohloh.net/projects/5227
Für den Fall, dass jetzt jemand auf die Idee kommt uns kaufen zu wollen: inkl. aller NICHT im Subversion erfassten Tätigkeiten dürfte Stud.IP rund 15 Millionen Euro wert sein.
Runden sie auf 20 und wir kommen ins Geschäft.
Vielleicht

Es war zwar ein Freitag der 13. aber wir haben es trotzdem gewagt und das 1.5er Release von Stud.IP veröffentlicht. Herunterladen kann man es – wie immer – von den SourceForge-Servern. Eine Liste der Neuerungen findet sich in der History. Es hat sich diesmal zwar nicht soooviel sichtbares geändert aber dafür wurde unter der Motorhaube mal kräftig aufgeräumt und viele Dinge neu sortiert. Das bringt mehr Übersichtlichkeit auf dem Server und erleichtert die Arbeit der Programmierer. Außerdem kann man Stud.IP jetzt auch auf einem Server mit PHP5 (passend zu der 5 in der Releasenummer ) betreiben.

Bei anderen gilt: Schnittstellen gut abdecken, sonst trocknet das Produkt aus. Nicht so bei Stud.IP.

Ein großes Thema beim Entwicklertreffen 2007 in Halle waren Schnittstellen im allgemeinen und die Frage nach dem Datenfluss zwischen HIS-Systemen und Stud.IP in besonderen. Gleich zwei Workshops waren dafür reserviert und das Interesse groß.

Bereits erfolgreiche Lösungen

Im ersten Teil hat Marco Bohnsack von data-quest Lösungen vorgestellt, die sich bereits jetzt im Praxiseinsatz bewähren. Die Unis Hannover und Halle sowie die TU Clausthal importieren Veranstaltungsdaten aus HIS-LSF, beschreiten dabei allerdings wenig standardisierte Wege, die im Einzelfall prima funktionieren, aber nicht ohne weiteres verallgemeinerbar sind. Die FH Osnabrück, die Uni Bremen und die Uni Oldenburg importieren ihre Veranstaltungsdaten aus selbst entwickelten Planungssystemen. Die Unis Halle, Passau und Osnabrück nutzen Stud.IP direkt als Primärsystem für alle Veranstaltungsdaten. Michael Schaarschmidt von der Uni Halle stellte in einer vielbeachteten Präsentation eine sehr ausgereift wirkende Stud.IP-Erweiterung für den Umgang mit Studienmodulen vor, die zwar Basisdaten aus einem anderen System importiert, aber Stud.IP zu einem weiterhin autark nutzbaren System zur Verwaltung und Organisation von Veranstaltungen und jetzt auch Modulen ausbaut. An vielen Hochschulen, die Stud.IP erfolgreich einsetzen, stehen Entscheidungen darüber an, wie und mit welchen Systemen zukünftig Veranstaltungsdaten verwaltet werden sollen. Ein einheitlicher Trend ist nicht erkennbar, so dass sich für das Stud.IP-Projekt die Frage stellt: Wie halten wir es mit den Schnittstellen, so dass Stud.IP sowohl als Primär- als auch als Sekundärsystem für Veranstaltungs- und andere Daten sinnvoll eingesetzt werden kann?

Der weitere Weg: Eine allgemeine Schnittstellendefinition

Diese Frage wurde im zweiten Teil des Workshops diskutiert und das Ergebnis: In den nächsten Wochen werden die Anforderungen zusammengetragen und ein allgemeiner Rahmen für Import-, Export- und Synchronisationsschnittstellen für verschiedenste Daten definiert. Ziel ist ein einheitliches Datenformat, das über verschiedene Kanälen wie Webservices oder Batchschnittstellen genutzt werden kann, um Daten mittels geeigneter Abbildungen mit anderen Systemen zu synchronisieren. Eine solche Abbildung wird z.B. zur IMS Enterprice Specification definiert, aber auch zu HIS-Datenstrukturen und -Schnittstellen, soweit sie spezifiziert sind. Auch andere Szenarien sind wichtig: Mehrere Stud.IP-Installationen miteinander kommunizieren zu lassen oder erweiterte Backupmöglichkeiten für einzelne Stud.IP-Objekte wie z.B. Veranstaltungen zu schaffen. Bereits exisitierende Lösungen werden soweit möglich integriert und die Ideen konfligieren nicht mit anderen Bestrebungen, das Campusmanagement zu vereinfachen. Die konkrete Umsetzung kann bald beginnen: Ressourcen für die Entwicklung stehen zum Teil bereits zur Verfügung, zum Teil könnten sie über ein Konsortialmodell aufgebracht werden, das bei der Entwicklung der ILIAS-Lernmodul-Schnittstelle von data-quest bereits erfolgreich war.

Beteiligung erwünscht

Die Planungsphase ist angelaufen. Erste Anforderungen sind formuliert, gleichzeitig arbeiten wir an einem XML-Datenmodell, dass die Stud.IP-Datenbankinhalte umfassend, flexibel und sicher nach außen darstellen kann. Wie immer bei Stud.IP passiert das öffentlich, und zwar auf dem Developer-Server, aus historischen Gründen in der Veranstaltung »(Studien)Modularisierung im Rahmen von Stud.IP und HIS« . Alle Interessierten sind aufgerufen, sich so früh wie möglich einzubringen: Mit Anforderungen, Vorschlägen, Verbesserungsideen und Kritik. Denn Stud.IP ist ein Open-Source-Projekt und das bedeutet bei uns: Wer sich engagiert und dabei bereit ist, über den eigenen Tellerrand hinauszuschauen, der bestimmt mit, wie es weitergeht.

Wenn die Schnittstelle fertig konzipiert oder gar programmiert ist, ist die Welt allerdings noch nicht gerettet. Denn die Anbindung kann nur an Systeme gelingen, die Daten in verwertbarer Form exportieren oder importieren mögen. Und daran, finden wir, hapert es bei einigen.

Es gibt in der Stud.IP-Welt zwei große, jährlich wiederkehrende Ereignisse die sich niemand, der mit Stud.IP arbeitet, entgehen lassen sollte:
1. Die Stud.IP-Tagung
Findet traditionell im Herbst in Göttingen statt und richtet sich besonders an Betreiber und Anwender. Der Schwerpunkt liegt auf der Nutzung des Systems: wie wird es an den unterschiedlichen Standorten eingesetzt, was wird damit gemacht, welche Szenarien lassen sich abbilden. Natürlich geht es auch um Technik, aber die steht nicht im im Mittelpunkt, denn dafür gibt es

2. Die Entwicklertagung
Welche im Frühjahr an wechselnden Orten stattfindet. Hier geht es um Code, weitere Entwicklungen, neue Features usw.
Für Interessenten ist die Entwicklertagung eine gute Gelegenheit die Entwickler hinter Stud.IP kennenzulernen und in den Diskussionen um die Weiterentwicklung des Systems eigene Ideen einzubringen.

Nun haben wir ja meteorologisch gesehen Frühling – die Entwicklertagung steht also an.
Und zwar am 29.03.07 in Halle – und alle sind herzlich eingeladen!
Informationen finden sich wie immer auf www.studip.de

Auf nach Halle!

Schon in der E-Learning-Steinzeit, so ca. 1997, wurde in Osnabrück elektronisch geübt und geprüft. Das Projekt »Virtueller Campus Sprache – Wissen – Information« hatte es sich zum Ziel gesetzt, den Übungsbetrieb für Programmiervorlesungen zur Künstlichen Intelligenz mit einer elektronischen Übungsumgebung zu erleichtern. Es folgte eine wechselvolle Geschichte von Implementationen, Reimplementationen, Erweiterungen und hochinnovativen KI-Korrekturmechanismen.

Eine Besonderheit des Projektes war, dass von Anfang an der Praxiseinsatz im Mittelpunkt stand. An den Unis in Osnabrück, Hildesheim und Hannover wurde der »Virtual Campus Prolog Tutor« von mehreren hundert Studierenden eingesetzt. Mit der Evolution der E-Learning-Landschaft hat sich auch das Produkt gewandelt. Stand zunächst eine komplexe, ausgewachsene Java-Client-Anwendung für den Versuch, eine Softwareentwicklungsumgebung in den Browser zu bringen, spielte später eine schlanke Weiterentwicklung von Helmar Gust die Hauptrolle. Dieses System, der “minimal virtual campus” (mvc) brachte auch das erste Mal ein Modul für elektronische Klausuren mit, die damit seit Jahren im Studiengang Cognitive Science an der Uni Osnabrück geschrieben werden.

Der bislang letzte Evolutionsschritt war die Integration des »virtuellen Prüfungssystems«, wie es jetzt unter dem Kürzel ViPs firmiert, in eine vollständige Lernplattform. Nämlich Stud.IP. Damit ist es nun möglich, für jede Veranstaltung Übungsblättter und Klausuren anzulegen und Tutoren und Dozenten bei der Korrektur zu unterstützen. ViPs beschränkt sich nicht auf Programmieraufgaben, sondern erlaubt es, beliebige Inhalte über Multiple-Choice und Freitextaufgaben abzufragen. Neue Aufgabentypen können leicht hinzugefügt werden. Über die Integration in Stud.IP, die Möglichkeiten des Systems und unsere Erfahrungen habe ich schon im November 2005 bei der Fachtagung »Computergestützte Prüfungen« (Videoaufzeichnung) in Bremen berichtet.

Der Grund, warum ViPs jetzt eine Meldung wert ist: Elmar Ludwig hat aus der bislang ausschließlich osnabrückischen Erweiterung ein Plugin gebaut, das mit der im April kommenden Stud.IP-Release-Version 1.5 für alle Stud.IP-Betreiber einsetzbar ist. Seit heute liegt eine erste Fassung des Plugins auf dem Developer-Server und kann von Interessierten bereits mit der aktuellen SVN-Version getestet werden.

Wir freuen uns auf Diskussionen mit allen, die sich für die Abwicklung des Übungsbetriebs und elektronische Klausuren mit Stud.IP interessieren.

Das CoreGroup-Treffen liegt nun bereits wieder eine Woche zurück und eigentlich war alles wie erwartet: Mein Zug hatte Verspätung, Marcos Auto hat durchgehalten und uns sicher nach Hannover gebracht und wir haben zwei Stunden, überzogen um alle Punkte diskutieren zu können. Die Verpflegung in der Mensa war ok und am Nachmittag gab es einen erstklassigen, von Helge selbstgebackenen Kuchen. Zurück in Göttingen haben wir uns noch ein leckeres Essen beim Italiener gegönnt, bevor mich mein Zug wieder zurück gebracht hat, der diesmal pünktlich kurz vor Mitternacht in Jena eintraf.
Soweit so gut, aber viel interessanter wäre ja vielleicht eine Antwort auf die Frage: “Was haben die da den ganzen Tag beredet?”. Oh, es war viel z.B.:

Die Stud.IP-CoreGroup, schon etwas erschöpft – kurz vor Ende
des Treffens

• programmtechnische Fragen
• Zeit- u. Releaseplanung
• Zukunftsplanung
• politische Fragen

Etwas konkreter und für Programmierer und Betreiber sicher am interessantesten: Stud.IP unterstützt ab Version 1.5 erstmals PHP 5 und MySQL 5 und wird ab Version 1.6 die Unterstützung für PHP 4 und MySQL 4.0 einstellen. Stud.IP v.1.5 wird voraussichtlich Ende März an den bekannten Stellen im Internet zur Verfügung stehen. Zur besseren Darstellung des weiteren Weges wird es in kürze eine Roadmap der Entwicklungsziele und Visionen von Stud.IP geben. Um die anstehenden Aufgaben auf breitere Schultern zu verteilen, werden weitere aktive Programmierer in die CoreGroup aufgenommen – die Abstimmungen laufen gerade. Die nächste Entwicklertagung findet Mitte/Ende März statt – voraussichtlich in Halle.

Die neue Stud.IP-Online-Hilfe

Seit dem letzten Release (Version 1.4) gibt es eine neue Online-Hilfe. Wurde früher die gesamte Hilfe zusammen mit Stud.IP ausgeliefert und lokal installiert, gibt es jetzt eine gemeinsame, zentrale Hilfe für alle Installationen.

Einerseits ist das großartig: Änderungen an der Hilfe sind gleich für alle Standorte verfügbar und Doppelarbeit bei der Überarbeitung der Hilfe entfällt. Andererseits ist das nicht so großartig: Was ist mit lokalen Anpassungen? Den Hinweisen auf die hervorragende Hotline der Uni Düsselburg oder den ganz speziellen Regelungen bei Anmeldungen in Oldenschweig? Für diese Probleme wurde eine Lösung gefunden: Jeder Standort kann eine eigene Sicht auf die Zentralhilfe bekommen, in der nur die Informationen abweichend eingegeben werden müssen, die tatsächlich abweichend sind. Der Rest aktualisiert sich automatisch. Bislang machen sieben Hochschulen davon Gebrauch, Tendenz steigend.

Der guten Nachrichten ist aber noch kein Ende: Du kannst mithelfen, die Hilfe zu verbessern. Ja, du, genau du, der du diesen Satz jetzt liest! Klick einfach auf “Seite bearbeiten” und leg los. Das ist nicht schwierig, macht Spaß und beliebt. Um Spam und grobe Fehler zu vermeiden, wird deine Änderung dann allerdings nicht sofort aktiv, sondern muss von einem Admin noch publiziert werden. Aber keine Angst: Gute Arbeit lohnt sich immer und auch kleine Korrekturen, Ergänzungen etc. sind hochwillkommen. Denn: Es gibt immer etwas zu verbessern!

Die URL für den Direktzugriff: hilfe.studip.de.