Chatprotokoll Florian Gnägi
Chattranskript zum e-teaching.org-Expertenchat mit Florian Gnägi, Geschäftsführer der frentix GmbH und Mitentwickler des Learning Management Systems OLAT zum Thema „Open Source Software – Wer profitiert vom freien Code?“ am 21. 11. 2011 von 14:00 bis 15:00 Uhr.
Die Fragen im Überblick. Per Klick können Sie direkt zu einer Frage springen:
Florian Gnägi: Guten, Tag, vielen Dank für die freundliche Einladung, ich freue mich sehr auf diese interessante Diskussion!
Mike: Worin unterscheiden sich Open Source Software, Freeware und Shareware im Detail?
Thoron: Freeware, Open Source, Freie Software. Oberflächlich gesehen, scheinen die Begriffe das gleiche zu bedeuten. Können Sie hier etwas konkreter werden und den Begriff Open Source Software besser zu ähnlichen Konzepten abgrenzen?
Florian Gnägi: Eine sehr gute Frage, denn vordergründig könnte man meinen, es sei dasselbe:
Markus Schmidt: Auch bei Open Source Software entstehen in der Einrichtung, die solche Software einsetzt, Kosten, wie Personalausgaben für Installation, Pflege und Aktualisierung. Rechnet sich der Einsatz von Open Source Software?
Florian Gnägi: Ja, das ist in der Tat eine sehr gute und wichtige Frage. Denn es geht hier um die Grundsatzfrage: Open Source oder Closed Source. Man darf das allerdings nicht verwechseln mit kommerziell versus nicht-kommerziell, denn auch für Open Source Lösungen braucht es kommerzielle Anbieter, die die entsprechenden Services anbieten und Kontinuität garantieren. Es gibt eine berühmte Aussage: „not free as in "free beer" but free as in "free speech"“. Das ist es, worum es bei Open Source Software geht. Es ist ein schlechter Grund OSS (Open Source Software) zu verwenden, um primär Kosten zu sparen. Auch bei kommerzieller Software entstehen Personalkosten, es braucht Geld für Lizenzen. Im Wesentlichen entsteht ein ähnlicher Aufwand wie bei OSS.
Gerade im Hochschulbereich ist es meiner Meinung nach aber absolut essentiell, OSS einzusetzen und das aus einem einfachen Grund: Die Lehre ist die Kernkompetenz der Hochschulen. Ein Learning Management-System ist eine Basisinfrastruktur, um die Lehre zu unterstützen. Aus diesem Grund sollte man sich in keine Abhängigkeit zu einem Closed Source-Angebot begeben. Bei Closed Source gibt es ein sehr großes Problem: Es gibt keine Exit-Strategie oder diese ist sehr teuer. Wenn eine Software nicht mehr unterstützt wird oder die Entwicklung in eine Richtung läuft, die man nicht mehr unterstützen möchte, dann hat man mit OSS immer die Möglichkeit, die Software selbständig weiter zu betreiben, jemanden anzustellen, der das tut oder einen Exportmechanismus zu programmieren etc. Das, die grundsätzlich offene Exit-Strategie, ist der Grund, warum OSS in Hochschulen eingesetzt werden sollte, nicht die Kostenreduktion. Oft können Kosten auch reduziert werden, aber es ist offensichtlich: Von Liebe allein kann niemand Software entwickeln. Gelder müssen zwingend fließen, sonst stirbt eine Software weg.
StfnKcke: Und wo liegen dann die Vorteile der Open Source Software?
Florian Gnägi: Ich denke, das Wichtigste habe ich schon erwähnt. Ein weiterer Vorteil ist die Anpassbarkeit an die lokalen Gegebenheiten, wobei das natürlich auch immer ein Risiko birgt, dass die Anpassungen bei einem Update problematisch sein könnten. Dadurch, dass der Code vorhanden ist, kann ich mir selbst ein Bild machen, ob die Software eine gute Qualität hat oder nicht. Durch die Community kann ein Austausch und ein Netzwerk entstehen, das sehr vorteilhaft ist, speziell, wenn verschiedene Anwender in einem ähnlichen Einsatzgebiet unterwegs sind.
OpenAccess: Für wen eignet sich aus Ihrer Sicht Open Source Software am besten? Und welche Art von Software? Was empfehlen Sie beispielsweise kleinen Unternehmen?
Florian Gnägi: Ich denke, OSS eignet sich in verschiedensten Bereichen:
Für kleine Unternehmen ist OSS lebenswichtig, um die Basisinfrastruktur abzudecken. Hier spielen die Kosten dann eine sehr große Rolle. Mit Basisinfrastruktur meine ich vor allem die Server: Mail, Webseite, Fileshare. Das gibt es alles tausendfach erprobt als OSS.
BSC: Wie kann man verhindern, dass ein Open Source-Code widerrechtlich in kommerziellen Anwendungen benutzt wird?
Florian Gnägi: Warum sollte man das? Als Entwickler von OSS kenne ich die Frage natürlich gut. Im Prinzip ist die Lösung einfach: es gibt ja eine Lizenz. Es ist nicht etwa so, dass OSS gleich ohne Lizenz ist. Ganz im Gegenteil, es gibt erhebliche Unterschiede in den verschiedenen OSS Lizenzen. Einige sind sehr restriktiv (GPL) und andere sind sehr frei (BSD/Apache). Wenn ein Code widerrechtlich verwendet wird, dann kann man theoretisch die Verwendung vor Gericht einklagen. Dies hat es in einigen Fällen auch schon gegeben und so wurden Firmen gezwungen, Codes herauszugeben. Das ist natürlich eine sehr schwierige und heikle Angelegenheit und es braucht viel Ausdauer, so einen Verstoß wirklich zu ahnden. Die Community hat hier aber schon ein Druckmittel - die Öffentlichkeit - in der Hand. Ich denke, wenn man Angst vor diesem Szenario hat, dann sollte man keinen Code unter OSS lizenzieren. Persönlich finde ich die GPL eine eher unbrauchbare Lizenz, ich bevorzuge Apache.
Entwickler: Welche Möglichkeiten gibt es für Entwickler, die Software anderen zugänglich zu machen? Auf speziellen Plattformen?
Florian Gnägi: Ja, es gibt diverse Plattformen, wenn man nicht selbst eine Projekthomepage aufbauen möchte. Es kommt aber auch auf die Art des Projektes an. Es gibt einerseits die Hobbyprojekte, und dies meine ich in keiner Weise abschätzig. Es geht hier darum, dass die Entwickler diese Software in ihrer Freizeit, aber durchaus sehr professionell entwickeln. Das sind typische Projekte, die auch für die Endkunden interessant sind. Solche Software wird oft auf den angesprochenen Plattformen entwickelt, zum Beispiel Sourceforge, Github und andere.
Dann gibt es die andere Kategorie der institutionellen Software, zu der auch OLAT gehört. So was programmiert niemand zu Hause als Freizeitbeschäftigung, das kann man zu Hause ja auch gar nicht einsetzten oder nur sehr begrenzt. Solche Software wird in der Regel von großen Institutionen oder von kommerziellen Firmen entwickelt. Dahinter steht ein professionelles Software Entwicklungsteam, deren Job es ist, die Software zu programmieren. Die Entwicklung läuft hier wie bei Closed Source, aber transparent und mit Einflussnahme der Community. Diese Art von Software findet man selber auf Communtiy-Plattformen.
Shaug: Inwiefern profitiert die OS Software auch von den kommerziellen Dienstleistern drum herum?
Florian Gnägi: Klar, ohne die kommerziellen Dienstleistungen wäre die Entwicklung der Software ja oft gar nicht möglich. Bei frentix zum Beispiel wird die ganze Softwareentwicklung über Dienstleistungen finanziert.
Shaug: Die Uni Zürich hat ja viel in die Software reingesteckt. Inwiefern hat sie davon auch direkt profitieren können?
Florian Gnägi: Die Uni Zürich hat in der Tat sehr viel in die Software investiert. Die erste Zeile Code habe ich in OLAT vor rund zwölf Jahren geschrieben. In den letzten Jahren hat die Uni Zürich diverse Mitarbeiter in Festanstellungen gehabt, die sich ausschließlich mit OLAT Entwicklung und Betrieb beschäftigt haben. Man rechne.
Die Frage ist, wie weit die Uni Zürich von der Open Source Idee profitiert hat. Und hier gehen die Meinungen sehr auseinander. Zurzeit findet gerade ein spannender Prozess statt, leider aus meiner Perspektive ein sehr tragischer. Denn die Uni Zürich hat im vergangenen Jahr eine Kehrtwende in Bezug zu Ihrer Open Source-Strategie gemacht. Das Projekt hat sich von einem Projekt mit aktiven Community-Mitgliedern, die auch essentiellen Code beigesteuert haben, wie zum Beispiel meine Firma frentix, gewandelt zu einem Projekt, das Open Source nur versteht im Sinne von: „Man kann den Code herunterladen“, aber ohne eine wirkliche Community haben zu wollen. Insofern glaube ich, dass die Uni Zürich in Zukunft wohl eher nicht mehr von der Communtiy profitieren wird oder eben will. Die Uni Zürich investiert aus Eigeninteresse einfach sehr viel in die Software. Es war nie Ziel, dies für die Community zu tun. Dies ist auch in Ordnung, es ist schließlich nicht die Aufgabe der Uni Zürich, ein Produkt für andere Nutznießer zu entwickeln.
Martin: Wäre es für OLAT nicht besser gewesen, eine breitere Entwicklergemeinde in den Hochschulen zu haben? So ähnlich wie OpenCast Matterhorn?
Florian Gnägi: Das wäre es zu Beginn der Entwicklung in der Tat gewesen. Es wäre eine politische Sache gewesen, dies anzustreben, da habe ich mich herausgehalten. In der Schweiz ist das nicht ganz so einfach durchzuführen, weil OLAT ja von der Uni Zürich kam und es teilweise undenkbar wäre, dass eine andere Uni dasselbe System verwenden würde, wie das der UZH.
Wie vorher erwähnt ist eine breitere Entwicklergemeinde aber nicht das, was bei OLAT im Moment im Vordergrund steht. Man darf bei einer großen Entwicklergemeinde auch nicht einer romantischen Vorstellung von Open Source verfallen. Viele Köche verderben den Brei. Von daher kann ich diese Strategie auch gut verstehen. Aber eine breitere Abstützung, ein konzentriertes Vorgehen innerhalb der Schweiz oder gar Europa wäre sicher eine sehr gute Sache gewesen. Zurzeit sehe ich dafür eher keine Möglichkeit, weil alle Institutionen schon ihre Strategien haben. Es wurde hier klar eine Chance vertan.
Moderator: Hier kommt noch eine Nachfrage zu dem Thema:
D34f: Heißt das im Klartext, dass die Entwicklung von OLAT erheblich verlangsamt oder stagnieren wird?
Florian Gnägi: Das kommt ganz auf den Standpunkt an. Die Uni Zürich forciert zurzeit ein massives Refactoring, wie lange dieses Projekt dauern wird, ist unklar. Während der Zeit wird das Projekt stagnieren, da keine neuen Features einfließen werden. Diese Entwicklung passiert auch komplett isoliert ausschließlich in der Uni Zürich. Wir von frentix beispielsweise haben keinerlei Zugang zu dem Code, der hinter verschlossener Türe in den letzten acht Monaten entwickelt wurde. Wir haben in den letzten Wochen sehr intensiv darüber diskutiert und uns nun entschlossen, diese Community, die eben keine wirkliche mehr ist, zu verlassen. Wir sind dabei, ein Fork von OLAT zu bilden und unter dem Namen OpenOLAT eine neue Entwicklung aufzugleisen. Es dauert aber noch etwas, bis wir alle lizenztechnischen Fragen geklärt haben und bis wir den ersten Release freigeben können. Hier sieht man eben den Vorteil von OSS: Wir, frentix, haben uns entschieden, die Exit-Strategie zu wählen. Dank OSS können wir das. Das ist der Grund, OSS zu wählen.
DZenker: Kann man aus den vorherigen Ausführungen folgern, dass sich nun zwei Entwicklungsstränge gebildet haben: Uni Zürich (OLAT) und frentix/BPS (OLAT Pro)?
Florian Gnägi: Wir hoffen, dass wir mit OpenOLAT, mit BPS und anderen ehemaligen OLAT Mitgliedern gemeinsame Sache machen können, ja. Wir haben OpenOLAT schon vor ein paar Monaten mit BPS zusammen aufgesetzt, mit dem Ziel, gemeinsam Bugfixing zu betreiben. Doch seither sind einige Sachen geschehen, die nun dazu führen, dass wir von frentix OpenOLAT als unsere neue Basis sehen und nicht mehr OLAT. Dies wird auch dazu führen, dass wir wesentliche Bestandteile von OLATpro in OpenOLAT portieren werden. Als kleines Zückerchen sei hier zum Beispiel das Browser-Back genannt.
Moderator: Hier kommt noch eine allgemeine Frage zu OSS:
Klein: OSS wird gern in sicherheitsrelevanten Modulen (z.B. Encoding) eingesetzt. Macht die Offenheit des Codes diese Module tatsächlich sicherer?
Florian Gnägi: Eine klassische Frage zum Thema OSS. Ja und Nein. OSS hat den großen Vorteil, dass Fehler gefunden werden können. Bei Closed Source bestehen dieselben Fehler, man kann sie aber nicht durch Lesen des Codes finden. Die Frage ist nun: Gibt es mehr böse oder gute Leute, die Code lesen? Die meisten Sicherheitsfehler werden durch automatisierte Tools gefunden, diese sind bei Open Source wie bei Closed Source gleich gut. Insofern glaube ich schon, dass das Open Source grundsätzliche eher zu sichererem Code führt. Die Ausnahme bestätigt hier die Regel. Der entscheidende Vorteil ist aber: bei Open Source kann ich mich selbst vergewissern, wie es um den Code bestellt ist, bei Closed Source bleiben mir nur die Hochglanzbroschüren.
Moderator: So, die Chat-Zeit ist auch schon fast um: Wollen sie noch ein kurzes Schlusswort an die User richten?
Florian Gnägi: Vielen Dank für die spannenden Fragen. Unsere aktuelle Situation mit OpenOLAT hat mir einige schlaflose Nächte beschert und ich musste mir einige grundsätzliche Gedanken zum Thema Open Source machen. Ihre Fragen haben mich nochmals bestärkt in unserem Vorgehen, OLAT als Fork weiterleben zu lassen. Vielen Dank auch an e-teaching.org für die Gelegenheit des Austauschs.
Moderator: Das waren 60 Minuten Expertenchat von e-teaching.org. Vielen Dank an die User für die vielen Fragen, die wir aus Zeitgründen leider nicht alle beantworten konnten. Vielen Dank auch an Florian Gnägi, dass Sie sich die Zeit für die User genommen haben.
- Worin unterscheiden sich Open Source Software, Freeware und Shareware im Detail?
- Auch bei Open Source Software entstehen in der Einrichtung, die solche Software einsetzt, Kosten, wie Personalausgaben für Installation, Pflege und Aktualisierung. Rechnet sich der Einsatz von Open Source Software?
- Wo liegen die Vorteile der Open Source Software?
- Wie kann man verhindern, dass ein Open Source-Code widerrechtlich in kommerziellen Anwendungen benutzt wird?
- Welche Möglichkeiten gibt es für Entwickler, die Software anderen zugänglich zu machen? Auf speziellen Plattformen?
- Inwiefern profitiert die OS Software auch von den kommerziellen Dienstleistern drum herum?
- Die Uni Zürich hat ja viel in die Software reingesteckt. Inwiefern hat sie davon auch direkt profitieren können?
- Wäre es für OLAT nicht besser gewesen, eine breitere Entwicklergemeinde in den Hochschulen zu haben?
- Heißt das im Klartext, dass die Entwicklung von OLAT erheblich verlangsamt oder stagnieren wird?
- Kann man aus den vorherigen Ausführungen folgern, dass sich nun zwei Entwicklungsstränge gebildet haben: Uni Zürich (OLAT) und frentix/BPS (OLAT Pro)?
- OSS wird gern in sicherheitsrelevanten Modulen (z.B. Encoding) eingesetzt. Macht die Offenheit des Codes diese Module tatsächlich sicherer?
Florian Gnägi: Guten, Tag, vielen Dank für die freundliche Einladung, ich freue mich sehr auf diese interessante Diskussion!
Mike: Worin unterscheiden sich Open Source Software, Freeware und Shareware im Detail?
Thoron: Freeware, Open Source, Freie Software. Oberflächlich gesehen, scheinen die Begriffe das gleiche zu bedeuten. Können Sie hier etwas konkreter werden und den Begriff Open Source Software besser zu ähnlichen Konzepten abgrenzen?
Florian Gnägi: Eine sehr gute Frage, denn vordergründig könnte man meinen, es sei dasselbe:
- Closed Source: kommerzieller Code auf Lizenzbasis, kein Zugang zum Quellcode
- Shareware: üblicherweise ein „Free Trial“ mit der Option, für die Vollversion zu bezahlen. Ohne Zugang zu Quellcode
- Freeware: üblicherweise kostenlos, aber mit Aufforderung, Geld zu spenden, oder Werbeeinblendungen. In der Regel ohne Quellcode
- Public Domain: Code kostenlos zum Herunterladen, kein Support, keine weitere Entwicklung, keine Lizenz. Nehmen und machen, was man will
- Open Source: Zugang zum Quellcode vorhanden, dies ist aber das Resultat einer wirtschaftlichen Überlegung. Es ist „praktisch“, den Code zu veröffentlichen, man erhofft sich etwas von der Community etc.
- Free Software: Im Zentrum steht ebenfalls der freie Quellcode, aber mehr aus einer philosophischen Überlegung heraus. Eine soziale Verantwortung wird postuliert, Code muss frei sein, so wie das Wort auch frei ist.
Markus Schmidt: Auch bei Open Source Software entstehen in der Einrichtung, die solche Software einsetzt, Kosten, wie Personalausgaben für Installation, Pflege und Aktualisierung. Rechnet sich der Einsatz von Open Source Software?
Florian Gnägi: Ja, das ist in der Tat eine sehr gute und wichtige Frage. Denn es geht hier um die Grundsatzfrage: Open Source oder Closed Source. Man darf das allerdings nicht verwechseln mit kommerziell versus nicht-kommerziell, denn auch für Open Source Lösungen braucht es kommerzielle Anbieter, die die entsprechenden Services anbieten und Kontinuität garantieren. Es gibt eine berühmte Aussage: „not free as in "free beer" but free as in "free speech"“. Das ist es, worum es bei Open Source Software geht. Es ist ein schlechter Grund OSS (Open Source Software) zu verwenden, um primär Kosten zu sparen. Auch bei kommerzieller Software entstehen Personalkosten, es braucht Geld für Lizenzen. Im Wesentlichen entsteht ein ähnlicher Aufwand wie bei OSS.
Gerade im Hochschulbereich ist es meiner Meinung nach aber absolut essentiell, OSS einzusetzen und das aus einem einfachen Grund: Die Lehre ist die Kernkompetenz der Hochschulen. Ein Learning Management-System ist eine Basisinfrastruktur, um die Lehre zu unterstützen. Aus diesem Grund sollte man sich in keine Abhängigkeit zu einem Closed Source-Angebot begeben. Bei Closed Source gibt es ein sehr großes Problem: Es gibt keine Exit-Strategie oder diese ist sehr teuer. Wenn eine Software nicht mehr unterstützt wird oder die Entwicklung in eine Richtung läuft, die man nicht mehr unterstützen möchte, dann hat man mit OSS immer die Möglichkeit, die Software selbständig weiter zu betreiben, jemanden anzustellen, der das tut oder einen Exportmechanismus zu programmieren etc. Das, die grundsätzlich offene Exit-Strategie, ist der Grund, warum OSS in Hochschulen eingesetzt werden sollte, nicht die Kostenreduktion. Oft können Kosten auch reduziert werden, aber es ist offensichtlich: Von Liebe allein kann niemand Software entwickeln. Gelder müssen zwingend fließen, sonst stirbt eine Software weg.
StfnKcke: Und wo liegen dann die Vorteile der Open Source Software?
Florian Gnägi: Ich denke, das Wichtigste habe ich schon erwähnt. Ein weiterer Vorteil ist die Anpassbarkeit an die lokalen Gegebenheiten, wobei das natürlich auch immer ein Risiko birgt, dass die Anpassungen bei einem Update problematisch sein könnten. Dadurch, dass der Code vorhanden ist, kann ich mir selbst ein Bild machen, ob die Software eine gute Qualität hat oder nicht. Durch die Community kann ein Austausch und ein Netzwerk entstehen, das sehr vorteilhaft ist, speziell, wenn verschiedene Anwender in einem ähnlichen Einsatzgebiet unterwegs sind.
OpenAccess: Für wen eignet sich aus Ihrer Sicht Open Source Software am besten? Und welche Art von Software? Was empfehlen Sie beispielsweise kleinen Unternehmen?
Florian Gnägi: Ich denke, OSS eignet sich in verschiedensten Bereichen:
- Privatanwender: hier ist der Kostenfaktor (z.B. OpenOffice versus MS Office) sicher etwas Entscheidendes
- Institutionelle Anwender: hier ist wie erwähnt eine schwächere Bindung zum Hersteller, im Gegensatz zu Closed Source, entscheidend
- Entwickler: OSS-Softwarebibliotheken sind extrem wichtig, ohne diese wäre es gar nicht möglich, dass heute derart viel Software und Dienstleistungen im Web angeboten werden
- Betreiber: Linux, Apache Webserver etc., diese Basissysteme sind nicht mehr wegzudenken.
Für kleine Unternehmen ist OSS lebenswichtig, um die Basisinfrastruktur abzudecken. Hier spielen die Kosten dann eine sehr große Rolle. Mit Basisinfrastruktur meine ich vor allem die Server: Mail, Webseite, Fileshare. Das gibt es alles tausendfach erprobt als OSS.
BSC: Wie kann man verhindern, dass ein Open Source-Code widerrechtlich in kommerziellen Anwendungen benutzt wird?
Florian Gnägi: Warum sollte man das? Als Entwickler von OSS kenne ich die Frage natürlich gut. Im Prinzip ist die Lösung einfach: es gibt ja eine Lizenz. Es ist nicht etwa so, dass OSS gleich ohne Lizenz ist. Ganz im Gegenteil, es gibt erhebliche Unterschiede in den verschiedenen OSS Lizenzen. Einige sind sehr restriktiv (GPL) und andere sind sehr frei (BSD/Apache). Wenn ein Code widerrechtlich verwendet wird, dann kann man theoretisch die Verwendung vor Gericht einklagen. Dies hat es in einigen Fällen auch schon gegeben und so wurden Firmen gezwungen, Codes herauszugeben. Das ist natürlich eine sehr schwierige und heikle Angelegenheit und es braucht viel Ausdauer, so einen Verstoß wirklich zu ahnden. Die Community hat hier aber schon ein Druckmittel - die Öffentlichkeit - in der Hand. Ich denke, wenn man Angst vor diesem Szenario hat, dann sollte man keinen Code unter OSS lizenzieren. Persönlich finde ich die GPL eine eher unbrauchbare Lizenz, ich bevorzuge Apache.
Entwickler: Welche Möglichkeiten gibt es für Entwickler, die Software anderen zugänglich zu machen? Auf speziellen Plattformen?
Florian Gnägi: Ja, es gibt diverse Plattformen, wenn man nicht selbst eine Projekthomepage aufbauen möchte. Es kommt aber auch auf die Art des Projektes an. Es gibt einerseits die Hobbyprojekte, und dies meine ich in keiner Weise abschätzig. Es geht hier darum, dass die Entwickler diese Software in ihrer Freizeit, aber durchaus sehr professionell entwickeln. Das sind typische Projekte, die auch für die Endkunden interessant sind. Solche Software wird oft auf den angesprochenen Plattformen entwickelt, zum Beispiel Sourceforge, Github und andere.
Dann gibt es die andere Kategorie der institutionellen Software, zu der auch OLAT gehört. So was programmiert niemand zu Hause als Freizeitbeschäftigung, das kann man zu Hause ja auch gar nicht einsetzten oder nur sehr begrenzt. Solche Software wird in der Regel von großen Institutionen oder von kommerziellen Firmen entwickelt. Dahinter steht ein professionelles Software Entwicklungsteam, deren Job es ist, die Software zu programmieren. Die Entwicklung läuft hier wie bei Closed Source, aber transparent und mit Einflussnahme der Community. Diese Art von Software findet man selber auf Communtiy-Plattformen.
Shaug: Inwiefern profitiert die OS Software auch von den kommerziellen Dienstleistern drum herum?
Florian Gnägi: Klar, ohne die kommerziellen Dienstleistungen wäre die Entwicklung der Software ja oft gar nicht möglich. Bei frentix zum Beispiel wird die ganze Softwareentwicklung über Dienstleistungen finanziert.
Shaug: Die Uni Zürich hat ja viel in die Software reingesteckt. Inwiefern hat sie davon auch direkt profitieren können?
Florian Gnägi: Die Uni Zürich hat in der Tat sehr viel in die Software investiert. Die erste Zeile Code habe ich in OLAT vor rund zwölf Jahren geschrieben. In den letzten Jahren hat die Uni Zürich diverse Mitarbeiter in Festanstellungen gehabt, die sich ausschließlich mit OLAT Entwicklung und Betrieb beschäftigt haben. Man rechne.
Die Frage ist, wie weit die Uni Zürich von der Open Source Idee profitiert hat. Und hier gehen die Meinungen sehr auseinander. Zurzeit findet gerade ein spannender Prozess statt, leider aus meiner Perspektive ein sehr tragischer. Denn die Uni Zürich hat im vergangenen Jahr eine Kehrtwende in Bezug zu Ihrer Open Source-Strategie gemacht. Das Projekt hat sich von einem Projekt mit aktiven Community-Mitgliedern, die auch essentiellen Code beigesteuert haben, wie zum Beispiel meine Firma frentix, gewandelt zu einem Projekt, das Open Source nur versteht im Sinne von: „Man kann den Code herunterladen“, aber ohne eine wirkliche Community haben zu wollen. Insofern glaube ich, dass die Uni Zürich in Zukunft wohl eher nicht mehr von der Communtiy profitieren wird oder eben will. Die Uni Zürich investiert aus Eigeninteresse einfach sehr viel in die Software. Es war nie Ziel, dies für die Community zu tun. Dies ist auch in Ordnung, es ist schließlich nicht die Aufgabe der Uni Zürich, ein Produkt für andere Nutznießer zu entwickeln.
Martin: Wäre es für OLAT nicht besser gewesen, eine breitere Entwicklergemeinde in den Hochschulen zu haben? So ähnlich wie OpenCast Matterhorn?
Florian Gnägi: Das wäre es zu Beginn der Entwicklung in der Tat gewesen. Es wäre eine politische Sache gewesen, dies anzustreben, da habe ich mich herausgehalten. In der Schweiz ist das nicht ganz so einfach durchzuführen, weil OLAT ja von der Uni Zürich kam und es teilweise undenkbar wäre, dass eine andere Uni dasselbe System verwenden würde, wie das der UZH.
Wie vorher erwähnt ist eine breitere Entwicklergemeinde aber nicht das, was bei OLAT im Moment im Vordergrund steht. Man darf bei einer großen Entwicklergemeinde auch nicht einer romantischen Vorstellung von Open Source verfallen. Viele Köche verderben den Brei. Von daher kann ich diese Strategie auch gut verstehen. Aber eine breitere Abstützung, ein konzentriertes Vorgehen innerhalb der Schweiz oder gar Europa wäre sicher eine sehr gute Sache gewesen. Zurzeit sehe ich dafür eher keine Möglichkeit, weil alle Institutionen schon ihre Strategien haben. Es wurde hier klar eine Chance vertan.
Moderator: Hier kommt noch eine Nachfrage zu dem Thema:
D34f: Heißt das im Klartext, dass die Entwicklung von OLAT erheblich verlangsamt oder stagnieren wird?
Florian Gnägi: Das kommt ganz auf den Standpunkt an. Die Uni Zürich forciert zurzeit ein massives Refactoring, wie lange dieses Projekt dauern wird, ist unklar. Während der Zeit wird das Projekt stagnieren, da keine neuen Features einfließen werden. Diese Entwicklung passiert auch komplett isoliert ausschließlich in der Uni Zürich. Wir von frentix beispielsweise haben keinerlei Zugang zu dem Code, der hinter verschlossener Türe in den letzten acht Monaten entwickelt wurde. Wir haben in den letzten Wochen sehr intensiv darüber diskutiert und uns nun entschlossen, diese Community, die eben keine wirkliche mehr ist, zu verlassen. Wir sind dabei, ein Fork von OLAT zu bilden und unter dem Namen OpenOLAT eine neue Entwicklung aufzugleisen. Es dauert aber noch etwas, bis wir alle lizenztechnischen Fragen geklärt haben und bis wir den ersten Release freigeben können. Hier sieht man eben den Vorteil von OSS: Wir, frentix, haben uns entschieden, die Exit-Strategie zu wählen. Dank OSS können wir das. Das ist der Grund, OSS zu wählen.
DZenker: Kann man aus den vorherigen Ausführungen folgern, dass sich nun zwei Entwicklungsstränge gebildet haben: Uni Zürich (OLAT) und frentix/BPS (OLAT Pro)?
Florian Gnägi: Wir hoffen, dass wir mit OpenOLAT, mit BPS und anderen ehemaligen OLAT Mitgliedern gemeinsame Sache machen können, ja. Wir haben OpenOLAT schon vor ein paar Monaten mit BPS zusammen aufgesetzt, mit dem Ziel, gemeinsam Bugfixing zu betreiben. Doch seither sind einige Sachen geschehen, die nun dazu führen, dass wir von frentix OpenOLAT als unsere neue Basis sehen und nicht mehr OLAT. Dies wird auch dazu führen, dass wir wesentliche Bestandteile von OLATpro in OpenOLAT portieren werden. Als kleines Zückerchen sei hier zum Beispiel das Browser-Back genannt.
Moderator: Hier kommt noch eine allgemeine Frage zu OSS:
Klein: OSS wird gern in sicherheitsrelevanten Modulen (z.B. Encoding) eingesetzt. Macht die Offenheit des Codes diese Module tatsächlich sicherer?
Florian Gnägi: Eine klassische Frage zum Thema OSS. Ja und Nein. OSS hat den großen Vorteil, dass Fehler gefunden werden können. Bei Closed Source bestehen dieselben Fehler, man kann sie aber nicht durch Lesen des Codes finden. Die Frage ist nun: Gibt es mehr böse oder gute Leute, die Code lesen? Die meisten Sicherheitsfehler werden durch automatisierte Tools gefunden, diese sind bei Open Source wie bei Closed Source gleich gut. Insofern glaube ich schon, dass das Open Source grundsätzliche eher zu sichererem Code führt. Die Ausnahme bestätigt hier die Regel. Der entscheidende Vorteil ist aber: bei Open Source kann ich mich selbst vergewissern, wie es um den Code bestellt ist, bei Closed Source bleiben mir nur die Hochglanzbroschüren.
Moderator: So, die Chat-Zeit ist auch schon fast um: Wollen sie noch ein kurzes Schlusswort an die User richten?
Florian Gnägi: Vielen Dank für die spannenden Fragen. Unsere aktuelle Situation mit OpenOLAT hat mir einige schlaflose Nächte beschert und ich musste mir einige grundsätzliche Gedanken zum Thema Open Source machen. Ihre Fragen haben mich nochmals bestärkt in unserem Vorgehen, OLAT als Fork weiterleben zu lassen. Vielen Dank auch an e-teaching.org für die Gelegenheit des Austauschs.
Moderator: Das waren 60 Minuten Expertenchat von e-teaching.org. Vielen Dank an die User für die vielen Fragen, die wir aus Zeitgründen leider nicht alle beantworten konnten. Vielen Dank auch an Florian Gnägi, dass Sie sich die Zeit für die User genommen haben.
Letzte Änderung: 08.04.2015