Matthias Andrasch

Menschen vernetzen, Handlungsoptionen eröffnen.

OER braucht mehr Möglichkeiten zum Gabeln?

Meine These: Die Bewegung rund um Open Educational Resources braucht mehr Möglichkeiten, um zu Gabeln. Was meine ich damit? Und welche Gabeln braucht es hierfür genau? Heu- oder Mistgabeln? Das alltägliche Ess-Besteck oder spezielle Gabeln? 😉

Disclaimer: Dieser Artikel beinhaltet einige sehr technische Aspekte – wer daran nicht interessiert ist, kann direkt zum Abschnitt „OER-Forks und Best Practise“ springen.

Die Bestärkung der These kam mir in Stuttgart auf der Open! 2015 Konferenz (Nachbericht). In Stuttgart trafen – zu meiner großen Freunde – Personen aus dem Bereich der Open Source Programmierung auf OER-Akteure. Da die Konferenz-Tracks jedoch getrennt waren, blieb der Austausch allerdings räumlich mitunter begrenzt. Betrachtet man jedoch beide Themenfelder, so tauchen durchaus viele Parallelen auf. Unter anderem die großen Frage: Wie können Inhalte für alle einseh- und bearbeitbar im Netz bereitgestellt und verwaltet werden? Wie kann Kontrolle durch die Projekt-Betreiber*innen gewährleistet werden?
In der Open Source Programmierung wurden diese Fragestellungen schon viele Jahren bearbeitet und es wurden Antworten in Form von technische Lösungen gefunden:

Was sind Gabel-Möglichkeiten?

Mit Gabeln meine ich in diesem Artikel die technische Möglichkeit einen Fork (Gabelung, Verzweigung) eines Projekts zu erstellen. Diese Möglichkeit wurde in der Open Source Programmierung entwickelt, um Änderungen für Open Source Projekte in einer Projektkopie zu entwickeln. So können externe Entwickler*innen in dieser Kopie am Projekt gefahrlos experimentieren, Änderungen testen, Fehler beheben oder neue Features hinzufügen. Versionsverwaltungs-Plattformen wie GitHub oder Bitbucket setzten diese technische Möglichkeit schon seit Jahren mit Erfolg ein:

Der Clou: Die Projektkopie bleibt mit dem Ursprungsprojekt verbunden. Wenn Entwickler*innen ihre Änderungen für gut befinden, können sie einen Antrag (pull request) an die Entwickler*innen des Ursprungsprojekts stellen. In diesem Antrag werden ihre Quelltext-Änderungen oder Ergänzungen übermittelt und es kann entschieden werden, ob die Änderungen übernommen werden sollen. Die Entwickler*innen des Originalprojekts haben also weiterhin die volle inhaltliche Kontrolle über ihr eigenes Projekt. Externe Entwickler*innen müssen aber nicht auf die Zustimmung des Ursprungsprojektteams bauen, sondern können mit ihrem Fork auch eigene Wege gehen.

Auch auf einer niedrigschwelligeren Ebene wird die Fork-Möglichkeit ebenso für Web-Designer*innen und Entwickler*innen angeboten. Codepen.io oder JSFiddle sind Online-Dienste, in denen Webdesign-Experimente veröffentlicht, selber in einer Kopie bearbeitet und unter einer URL wiederveröffentlicht werden können. Gerne selber ausprobieren!

Was machen diese Beispiele aus? Genau – die 5Rs von David Wiley werden technisch ermöglicht.

Wie setzt man Forks in Bezug auf OER ein?

Nun bedeutet Inhalte in der Open Source Programmierung vor allem Quelltext-Dateien. Im Bereich OER sieht dies aber schon ganz anders aus. Hier werden vielfältige Formate (Open Office, HTML, EPUB, etc.) und Online-Dienste (Wikis, Google Drive, Etherpad, etc.) zur Erstellung und Publikation von Inhalten eingesetzt. Ich möchte im folgenden einige Aspekte diskutieren, zu denen ich mir schon öfter in Bezug auf OER und Forks Gedanken gemacht habe.

Die Suche nach dem OER-Inhaltsformat (und Editor)

Versionsverwaltungssysteme haben für Entwickler*innen grundsätzlich das Problem gelöst, wie Quelltext gemeinsam in Projekten organisiert werden kann. Ein wichtiger Aspekt ist hierbei, dass jede*r Entwickler*innen jeweils ein Quelltext-Editorprogramm der eigenen Wahl einsetzen. Dies ist möglich, weil Quelltext in reinen Textdateien gespeichert wird. In den Software-Projekten werden weiterhin vorrangig Programmierabläufe gespeichert und keine Formatierungen oder Inhalte (Ausnahmen bestätigen die Regel).
In Bezug auf OER sieht das schon wieder ganz anders aus – hier geht es vorrangig um Inhalte, die auch möglichst ansprechend gestaltet werden sollen. Dies erhöht den Komplexitätsgrad deutlich und sollte mitbedacht werden, beispielsweise wenn visuelle HTML-Editoren (WYSIWYG) eingesetzt werden, die HTML-Quelltexte unterschiedlich formatieren. Sobald eine reine Quelltext-Ebene verlassen wird, kann es also zu Problemen kommen. Damit würde sich die grundsätzliche Frage stellen: Müssen OER-Editor*innen programmieren können und/oder einen Quelltext-Editor bedienen können?
Programme, die nicht auf leicht für Menschen nachvollziehbare Quelltextdateien setzen, wie bspw. Open Office eignen sich nämlich nicht für Versionverwaltung.

Ich hatte in diesem Blogbeitrag bereits über HTML5 als OER-Format nachgedacht: Dateiformatfrage für OER: x(+PDF) oder HTML5(+x). HTML5-Dateien wäre grundsätzlich geeignet verwaltet zu werden, wenn die zuvor angesprochenen Probleme beachtet werden.)

Hürde: Zeitgleiche Kollaboration an Inhalten

Die größte Hürde für OER in Bezug auf Versionsverwaltungsplattformen sehe ich in dem Mangel an zeitgleicher Online-Kollaboration. Google Drive Dokumente machen die gemeinsame Bearbeitung, Kommentierung und des Peer-Review deutlich effizienter als die derzeitige Möglichkeiten, die Plattformen wie GitHub oder Bitbucket bieten. Dafür wurden Versionsverwaltungs-Systeme nicht entwickelt. Insofern sollte nicht die Hoffnung erweckt werden, dass hier ein Allround-Tool für die OER-Erstellung existiert (Wie GitBook mit dieser Hürde umgeht, habe ich noch nicht ausprobiert – gerne Erfahrungen in den Kommentaren anfügen).

Die Frage nach der Reputation (auch in Bezug auf Wikis)

Einen interessanten Gedanken, teilte mir eine Dozentin im Nachgang zu meinem Grumpy Cat Hochschul Vortrag mit. Sie habe länger über die Möglichkeiten nachgedacht, die Wikis für die Wissensproduktion bieten. Der Knackpunkt war aber für sie, dass Reputation in der Wissenschaft anders funktioniert und Wissenschaftler*innen davon abgeschreckt sind, dass eigene Beiträge zu Wiki-Artikeln mit der Zeit in der Versionsgeschichte nach unten wandern. Der oder die Autorin wird somit unsichtbar. Der Beitrag zu einem Wiki-Artikel oder das Schreiben eines Wiki-Artikels ist somit für sie nicht gleichzusetzen mit der Veröffentlichung eines wissenschaftlichen Artikels, weil die Reputationsmöglichkeiten stark begrenzt sind.
Die Fork-Möglichkeit könnte meiner Ansicht nach hier Abhilfe schaffen, weil das Hochladen eines Projekts schon eher mit einer Publikation vergleichbar ist und sich Professor*innen als eindeutige Autor*innen von OER verorten können.
(2013 habe ich als Bachelor-Student mit Maike Neugebauer versucht das Konzept Versionsverwaltung-Plattform auf das wissenschaftliche Publikationssystem und Open Access zu übertragen – damals mit Markdown als Inhaltsformat: Open Access und Social Coding. Versuch einer Prototyp-Beschreibung. In meiner später folgenden Abschlussarbeit habe ich Versionverwaltung versucht mit offenen Online-Kursen zu verbinden).

Die Frage, die bei mir bisher immer hängen blieb war, ob eine so umfangreiche Versionierung wie in der Open Source Programmierung für OER wirklich nötig ist, d.h. dass jede Satzumstellung oder Änderung einer Überschrift erfasst werden muss – oder ob es ausreicht nur die jeweils fertigen Versionen eines Inhalts auf Plattformen für die Weiternutzung bereitzustellen und die Kollaboration an Inhalten mit anderen Diensten zu bewerkstelligen.
Somit könnte man den Begriff „Fork“ im Kontext von OER vorerst auf den Aspekt der Kopie-Erstellung, welche bearbeitet werden kann, beschränken.

OER-Forks und Best Practise

Wenn es um die OER-Erstellung und Nutzung einer breiten Masse geht, dann kann es nicht das Hauptziel sein, dass alle Autor*innen zu Programmier*innen werden. Ich sehe vor allem drei Punkte als enorm wichtig an, wenn man das Fork-Konzept auf OER übertragen und möglichst massenkompatibel machen möchte:

  1. Vorhandensein eines Tools zum Erstellen/Editieren
  2. Vorhandensein einer Fork- oder Download-Möglichkeit
  3. Vorhandensein einer konkreten (Online-)Einsatzmöglichkeit im Bildungskontext
  4. Vorhandensein einer einfachen Online-Publikationsmöglichkeit

Es gibt bereits Tools bzw. Plattformen, die dies meiner Ansicht nach sehr gut umsetzen:

h5p.org – Create, share and reuse interactive HTML5 content in your browser

h5p ist eines der vielversprechensten Projekte meiner Ansicht nach. Bisher bekam das Projekt noch wenig Aufmerksamkeit im deutschprachigen Raum. Dabei bietet h5p eben genau die oben beschrieben Anforderungen.

Screenshot der verschiedenen Inhaltselemente, die mit h5p erstellt werden können (z.B. Video, Quiz uvm.)

Mit h5p können interaktive HTML5-Elemente nach einem bestimmten Standard erstellt werden. Dies können Quizzes, interaktive Video-Animationen, Collagen, Diagramme oder viele weitere Elemente sein. Die Erstellung funktioniert über ein Plugin für Content Management Systeme (Bisher verfügbar sind WordPress und Drupal, ein Plugin für moodle ist in der Entwicklung). Die entstanden Lern-Elemente können somit direkt auf der Webseite oder im Lernmanagement System eingebunden werden. Weiterhin ist es möglich die Elemente auf anderen Seite mit einem iframe/embed-Code (wie bei Youtube) einzubinden:

Das wichtigste Feature ist aber, dass die interaktiven Elemente einen Download-Button besitzen. h5p-Elemente können somit von anderen Webseiten heruntergeladen, auf der eigene Webseite hochgeladen und verändert(!) werden. Somit können interaktive Elemente genauso einfach wie Youtube-Videos in verschiedenen Kontexten genutzt werden.

h5p steht unter Open Source Lizenz und Entwickler*innen können neue interaktive Elemente programmieren bzw. ein Plugin für LMS oder CMS entwickeln.

slidescarnival.com: Schöne Google Drive/Powerpoint-Folien

SlidesCarnival LogoDie Umsetzung der Anforderungen muss nicht immer so technisch komplex wie bei h5p.org sein. Ein gelungenes Beispiel ist für die Webseite slidescarnival.com, auf welcher die Designerin Jimena Catalina Vortragsfolien-Vorlagen bereitstellt. Diese sind Google Drive Präsentationen und können ganz einfach über den Befehl „Datei –> Eine Kopie erstellen“ benutzt werden. Die technische Fork-Möglichkeit wurde also bereits von Google Drive bereit gestellt. Mit der Webseite wurde hierfür nur ein Überbau geschaffen, auf welcher die Vorlagen durchsucht werden können.

Dieses Beispiel könnte man sicher auch auf andere Kontexte übertragen.

Interaktives Textadventure-Tool: Twine

Screenshot der Story-Ansicht des Twine Desktop-Programms

Twine-Desktopeditor

Das Open Source Tool Twine ist für mich ein sehr anschlussfähiges Tool für OER. Mit Twine können interaktive Geschichten erstellt werden – es existiert sowohl ein Online-Editor als auch ein Desktop-Editorprogramm für Mac, Linux und Windows.

Die mit Twine erstellten Stories werden als einfache HTML-Datei exportiert. Somit wird nur ein Webspace benötigt, um die erstellten Produkte zu veröffentlichen. Es gibt auch den Dienst http://www.philome.la/, welcher kostenfreies Twine-Hosting anbietet. Außerdem wurde Datenbanken wie die Interactive Fiction Database geschaffen, um die verstreuten Geschichten im Netz zu sammeln.

Das wichtigste Feature an Twine ist aber, dass die exportieren HTML-Dateien wieder im Editorprogramm geöffnet und bearbeitet werden können.

Perspektiven für OER und Forks in 2016

Zusammenfassend betrachtet könnte ich folgende Thesen aufstellen:

  1. Erfahrungen, Workflows und technische Lösungen aus der Open Source Programmierung sollten für die Verwendung im OER-Kontext geprüft und ggf. weiterentwickelt/angepasst werden
  2. Neue OER-Portale bitte nur, wenn Fork-Möglichkeiten existieren
  3. Open Office Dateien im Netz teilen ist auch schön, aber nicht der beste Weg für die Verbreitung von OER

Erst wenn das Forken von Inhalten möglichst einfach ist, ist auch der Weg frei für 5R-Projekte – zumindest besteht meiner Ansicht nach eine höhere Chance.

In dem Sinne: Frohes Gabeln! 😉

Weitere Gedanken zum Thema GitHub finden sich auf Guido Brombachs Blog (Remixen erwünscht! OER mit Github) und in der dazugehörigen Facebook-Diskussion.

Creative Commons Lizenzvertrag
Dieser Text ist lizenziert unter einer Creative Commons Namensnennung 4.0 International Lizenz (Ausgenommen sind Bilder und eingebundene Videos). Beitragstitelbild „Fork“ von Ozzy Delaney (CC-BY 2.0)
« »

© 2016 Matthias Andrasch. Theme by Anders Norén.