Die Angst Ergebnisse öffentlicher Projekte unter freie Lizenzen zu stellen
 |
| CC 3.0 by Trebol6, basierend auf Free Softwaremap (GFDL) |
Beispiel Deutsche Digitale Bibliothek
Ziemlich tief versteckt in den öffentlichen Dokumenten findet man auf Seite 15 des Grobkonzeptes http://www.iais.fraunhofer.de/uploads/media/DDBGrobkonzeptFinal.pdf folgende Erklärung:
Die Projektartefakte dieses Projekts werden Open Source sein. Damit ergibt sich auf natürliche Weise eine Präferenz zur Verwendung von frei verfügbaren Open Source Produkten. Kommerzielle resp. Closed Source Produkte sind immer dann eine Alternative, wenn Open Source Produkte nicht in hinreichender Qualität und Zuverlässigkeit zur Verfügung stehen. Dessen ungeachtet ist die DDB gut beraten, kommerziellen Support / Wartung für die verwendeten OpenLeider findet sich heute auf den Webseiten der Deutschen Digitalen Bibliothek kein Hinweis auf Open Source mehr.
Source Produkte zu kaufen. Für die kritischen Komponenten (Portal, CMS) ist das eine unverzichtbare Anforderung.
Auch andere öffentlich geförderte¹ Projekte, wie das vom BMAS geförderte Projekt "Leibniz" der Deutschen Zentralbücherei für Blinde setzen massiv freie Werkzeuge und APIs ein, ohne selbst den Quellcode öffentlich zu machen, obwohl die Öffentlichkeit, aber auch die öffentlichen Einrichtungen von einer Freigabe der Projektartifakte lernen könnte.
¹ Wer weitere Projekte kennt, schreibe dies unten in den Kommentar oder schreibe per Twitter an @art1pirat.
Die Vorteile der Freigabe von Projektartifakten
Feedback
Es gibt eine Reihe von Vorteilen, alle Projektartifakte frei zugänglich zu machen. Zum einen ergibt sich bei der Offenlegung von Softwarequellen und der Dokumentation von Schnittstellen der positive Effekt, daß da draußen in der Welt all die verrückten Entwickler angesprochen werden, hier und da kleine Verbesserungen beizusteuern. Das können kleine und größere Fehlerkorrekturen sein, Fragen, die vielleicht Aspekte beleuchten, die man bisher nicht beachtet hatte, oder einfach der Hinweis auf ähnliche Projekte, mit denen man Synergien eingehen könnte.
Lehre
Aber auch wenn man nur die Entwicklung des Projektes, die getroffenen Entscheidungen und auch die Fehler offen dokumentiert ist das nützlich. Denn in der praktischen Projektmanagmentarbeit und auch in der Projektmanagmentlehre fehlt es an genügend Beispielen, von erfolgreichen und auch erfolglosen oder schwierigen Projekten.
Bewußtsein schaffen
Durch die Offenlegung von Projektartifakten kann man Diskussionen anstoßen, Standards setzen, sich einen Namen machen und auch das Bewußtsein für bestimmte Aspekte einer Entwicklung stärken.
Nicht zuletzt hilft die Offenlegung auch, durch Ausnutzung des long-tail-Effektes, daß man auch in Nischenprojekten genügend Mitstreiter findet.
Die Ängste
Leider kursieren in den öffentlichen Einrichtungen viele Ängste, die einer Veröffentlichung von Projektergebnissen im Wege stehen.Angst vor Konkurrenz
Die größte Angst ist wohl die Angst, daß eine andere Einrichtung, oder gar ein Unternehmen die Projektergebnisse für ihre eigenen Zwecke verwendet und in direkte Konkurrenz tritt.
Eigentlich ist die Angst irrational, da öffentliche Enrichtungen normalerweise nicht in Konkurrenz stehen und eigentlich miteinander an einer gemeinsamen Entwicklung arbeiten sollten. Und Konkurrenz zu Unternehmen sollte nach BVerwGE39, 329, 333 f. vermieden werden.
Als ich zur Braille21mit etlichen deutschen Einrichtungen zur Blindenförderung gesprochen habe, war diese Angst förmlich greifbar. Jede Einrichtung hat versucht, die Ergebnisse der anderen zu inkludieren, aber gleichzeitig versucht möglichst nichts ihrer Eigenentwicklungen nach außen zu geben. Wenn sich die deutschen Einrichtungen dazu hätten durchringen können, ihre Erweiterungen, wie die Schweizer in die Daisy-Pipeline zu geben und sich mal auf das gemeinsame Erarbeiten von Standards für die Brailleschrift-Regeln für Buchdrucke konzentriert hätten, wäre den blinden und sehbehinderten Menschen da draußen schon wirksamer geholfen.
Auch die Angst davor, daß ja jemand anderes "unseren Code" in eine andere Richtung entwickeln könnte, existiert.
Auch hier muß man mühsam stetig wiederholen: Wenn ihr den Code herausgebt, habt ihr immer noch den Code und das Know-How. Wenn ihr die richtige Lizenz wählt, zB. GPL oder Affero, dann seid ihr immer mit dem Code verknüpft.
Und damit wären wir bei Kontrollverlust.
Kontrollverlust
Das ist das nächste, oft gehörte Argument. Wenn man zum Beispiel Quellcode herausgibt, daß man dann ja keine Kontrolle mehr darüber hat, wer was mit dem Quellcode macht. Und wenn der vielleicht noch geforkt wird, dann entwickelt er sich in eine andere Richtung.Auch hier gilt das oben gesagte, wenn ihr den Code herausgebt, habt ihr immer noch den Code und das Know-How.
Und wenn jemand euren Code übernimmt, dann wißt ihr, hey, unser Code war so wichtig, daß jemand sich damit beschäftigt!
Aber auch, wenn ihr Dokumentaion herausgebt, gilt das Gesagte. Ihr behaltet die Kontrolle und könnt nur gewinnen.
Aufwand
Oft kommt als Argument, daß wenn man Projektartifakte nach außen gibt, daß man ja einen Mitarbeiter allein für den Kontakt zur Community, für anfragen etc. abstellen muß. Und Pflege des Repositories, Eingehen auf die Wünsche der Auswärtigen, der Aufwand!
Nein. Der Aufwand hält sich in Grenzen. Sicher, man muß mit Interessierten kommunizieren. Aber das will man ja in der Regel auch, weil von dort oft wertvolles Feedback kommt.
Ein eigenes Repository muß man soundso pflegen, wenn man die Projektergebnisse warten will. Das ist unabhängig von der Freigabe nach außen. Die heutige Infrastruktur rund um Freie Software macht es leicht, Werkzeuge und Repositorien ohne großen Aufwand zu nutzen. Und ob man wirklich den Weg gehen will, auch weiterhin den Hut aufzuhaben und auch die Entwicklung der Externen zu koordinieren, ist eine Option. Die andere wäre, einfach regelmäßig mit dem dann externen Projekt zu kommunizieren und seine Anpassungen wieder in dieses einfliessen zu lassen. auch hier hält sich der Aufwand in Grenzen.
Ab und an wird mal angeführt, daß man ja vor der Herausgabe das Projekt in einen lesbaren Zustand bringen muß. Ja, mei, das Projekt sollte immer in einem Zustand sein, der lesbar und wartbar ist! Unabhängig ob intern oder extern.
Gesichtsverlust
Das kann eigentlich nur passieren, wenn Dilettanten am Werke waren. Auch da wäre die Leitung der Einrichtung gut beraten, diese Angst nicht zuzulassen. Denn wenn jemand Gesichtsverlust befürchtet, dann oft nur, weil das Projekt so grottig lief, daß man sich für schämen müßte. Für die Einrichtung wäre das aber der Gradmesser sich mal an die Nase zu fassen und zu überlegen, warum die Qualitätssicherungsprozesse im Projekt nicht gegriffen haben.
Und nur weil ein Projektergebnis nicht 100% perfekt ist, sollte man sich vor Veröffentlichung nicht fürchten, im Gegenteil! Je früher desto besser, denn die oben genannten Vorteile, wie zeitiges Feedback, Aufbau eines Austauschnetzwerkes, etc. sind mit Gold nicht aufzuwiegen.
Rechtliches
Jep, dies kann ein echtes Problem sein. Hat man alle Lizenzen beachtet? Können wir als Einrichtung verklagt werden? Haben wir gegen Patente verstoßen?
All diese Fragen und mehr werden bei der angedachten Veröffentlichung auf den Tisch kommen.
Aber ich bin mir sicher, wenn man an den richtigen Stellen um Hilfe bittet, zB. bei unabhängigen Organisationen, wie zB. der FSFE, beim Datenschutzbeauftragten, bei den Ministerien, usw. usf. können alle diese Fragen ohne große Probleme beantwortet werden.
Und, hey, was soll einer öffentlichen Einrichtung da schon groß passieren?
TL;DR
Warum viele öffentliche Einrichtungen ihre Projektergebnisse dann doch nicht öffentlich zugänglich machen und warum ihnen und uns dadurch Vorteile verlorengehen.