Open Allerlei statt Open Source? (Teil 3)

„Offen genug“ ist nicht genug

Seite: 2/2

Firmen zum Thema

Anforderungen an echte Open-Projekte

Schon bei diesem letzten Aspekt wird sich bei manchem Open-Projekt Open Source aufdrängen. „Bei Open Data ist es fast schon zwingend, auch Open-Source-Software einzusetzen“, meint Ganten. „Denn welchen Sinn macht es, wenn etwa Daten zwar offen sind, aber die Werkzeuge, um diese zu lesen, geschlossen, proprietär und lizenzpflichtig sind?“ Es liegt zumindest nahe, Dienstleister zu beauftragen, die sich mit dem offenen Umgang mit geistigem Eigentum auskennen.

Wichtig ist nicht, dass irgendwelche offene Standards einschließlich der Schnittstellen und Dokumentenformate das Endergebnis sind. Vielmehr ist als offen nur akzeptabel, was internationalisiert, nicht herstellereigen und kostenfrei ist. Was mit „fair, reasonable and non-discriminatory“ (FRAND) für seinen Preis wirbt, reicht nicht.

Schon gar nicht sollte ein Open-Projekt in die nächste Herstellerabhängigkeit führen. Dagegen wäre Open-Source-Software ein probates Mittel. Aber auch bei Softwarepflege, Updates, Support und Schulungen lässt sich noch Abhängigkeiten entgegenwirken, indem man die meist aus verschiedenen Teilprojekten bestehenden Aufgaben auf mehrere Anbieter verteilt. Das verlangt kooperative Software-Entwicklung, nichts für Anbieter mit der Erblast „Not invented here“, für Open-Source-Anbieter hingegen eine Gepflogenheit.

Im Übrigen haben diese noch ein Faible: Release often, release early. In Open-Projekten ist das ziemlich wichtig, denn auf schnell vorzeigbare Erfolge und laufenden Ausbau kommt es hier an. Öffnung ist immer ein Prozess.

Der Autor

* Ludger Schmitz ist freiberuflicher Journalist in München.

Artikelfiles und Artikellinks

(ID:37794130)