Prof. Dr. Detlef Stern

Free/Open-Source Software: Projekt- / Produktmanagement

Im ersten Teil über freie, quelltextoffene Software habe ich Notwendigkeiten beim Einsatz dieser Software in Bezug auf die Softwaretechnik im engeren Sinne beschrieben. Im Kern ging es darum, die bei Verwendung dieser Software entstehenden technischen Abhängigkeiten zu betrachten. Zu viele nutzen freie, quelltextoffene Software als „Black box“. Dabei erzeugen so transitive Abhängigkeiten ungünstige Effekte. Statt dessen sollte man diese Software als das betrachten, was sie wirklich ist: „frei“ verfügbarer Quelltext, dessen Effekte man verstehen muss. Da hilft kein Geld, dass man den Entwicklern dieser Software spendet.

Damit bin ich zugleich beim nächsten zu betrachtenden Aspekt: der Bezug auf ein Produkt- / Projektmanagement. Meist setzt man freie, quelltextoffene Software aus einem bestimmten Grund ein, etwa um diese in ein Produkt, einen Service zu integrieren. Auch aus einer eher nicht-technischen Sicht gibt es hierbei Herausforderungen (nicht euphemistisch für „Problem“, sondern wirklich so gemeint).

Das fängt schon damit an, freie, quelltextoffene Software nicht als Teil eines Beschaffungsmanagements zu betrachten. Selbst wenn man für diese Software Geld bezahlt, was nicht zwingend ist, gibt es trotzdem einiges zu bedenken.

Wie sieht es mit der Qualität aus, wie mit Fehlerbehebungen oder Aktualisierungen? Wie steht es um die Lebendauer der Software, wie weit ist dieser zu trauen? Muss meine Lösung zertifiziert sein? Alle Aspekte der Lieferantenauswahl bleiben bedeutsam, auch wenn der Quelltext unmittelbar verfügbar ist. Und auch das, wofür meist bei der Beschaffung von Software Geld fließt, bleibt wichtig: wie steht es um Nutzungs- und Verbreitungslizenzen? All das ändert sich nicht, wenn man den Entwicklern der Software Geld spendet.

Dies ist der Grund, weshalb ich oben das Wort „frei“ in Anführungszeichen schrieb: wie frei ist diese freie Software? Was muss man bei der Verwendung juristisch beachten? Bei mancher Software reicht es, die Autoren in einem Handbuch zu nennen. Andere Software fordert, dass man auf die Urheber auch in seiner eigenen Software verweisen muss. Wiederum andere Software fordert, dass man bei seinen eigenen Produkten die gleiche Lizenz verwenden muss, manchmal unterschieden nach Produkt- oder Serviceauslieferung. Bei rein intern verwendeter Software muss juristisch weniger beachtet werden. Manchmal besitzt freie, quelltextoffene Software auch mehrere Lizenzen, wobei dann je nach Lizenz dann doch Geld fließen muss, als Preis für eine freie Wahl des eigenen Businessmodells. Eher selten schränken Lizenzen den Nutzungszweck ein, etwa dass kein Geld damit verdient werden darf oder dass man mit der Software keine Waffen konstruieren darf.

Dabei wäre ich gleich beim dritten Post zum Thema: warum haben die Entwickler nicht so ein Businessmodell mit dualen Lizenzen gewählt?

Aber auch aus Sicht eines Inhalts- und Umfangmanagements, eines Risikomanagements, eines Kosten- und eines Terminmanagements ist freie, quelltextoffene Software zu betrachten und zu bewerten.

Wie gut passt die freie, quelltextoffene Software in mein Produkt, meinen Service? Wenn sich die Ausrichtung der Software ändern sollte, so dass es dann doch in Zukunft nicht mehr passen sollte, bin ich dann wirklich in der Lage auf Basis des Quelltextes mein eigenes Produkt weiter zu entwickeln? Was passiert, wenn jemand anderes die Software weiter entwickelt und dabei für mein Produkt schädliche Elemente einbaut?

De facto wird man häufig nicht umhinkommen, selbst Kompetenzen für die verwendete freie, quelltextoffene Software aufzubauen, oder diese an jemand anders zu delegieren. Das ist ein übliches Businessmodell für solche Software. Das wiederum hat Auswirkungen auf Geld- und Arbeitsaufwände. Auch hier: es gibt vermutlich einen Grund, weshalb die Entwickler der Software dieses Modell nicht gewählt haben. Mutmaßlich spielt Geld nicht die Rolle.

Auch nach all diesen Punkten sieht man, dass „frei“ nicht kostenlos bedeutet, sondern sich auf Freiheiten bezieht. Man hat die Freiheit, solche Software zu studieren (nicht nur an einer Hochschule ist das übrigens ein gutes Mittel, um sich zu verbessern), an eigene Bedürfnisse anzupassen, diese an Dritte weiter zu geben, und vieles mehr.

Auch aus einer Produkt- / Projektmanagementsicht ist es kurzsichtig, freie, quelltextoffene Software als „Black box“ zu betrachten. Man verschenkt damit viele Möglichkeiten, die quelltextlose Software in Binärform nicht besitzt, bei allen unverändert gebliebenen Verpflichtungen.

In sehr vielen Szenarien kann man sich Frage, wie sehr Geld helfen würde. Wenn es ein wichtiger Aspekt wäre, dann gäbe es für die Entwickler freier, quelltextoffener Software genügend einfach Möglichkeiten, dies auch umzusetzen. Womit wir bei der Motivation für solche Software sind.