Warum die Welt mehr Standardisierung braucht: Ergebnisse der systems.camp Session zu Offenheit im SE

Vom diesjährigen Systems Barcamp in Berlin berichtete ich bereits letzte Woche. Bei der Veranstaltung moderierte ich unter anderem eine Session zum Thema „Offenheit im SE“, deren Ergebnisse ich hier vorstellen möchte.

Warum Offenheit?

Ich bin an vielen Stellen damit in Berührung gekommen: Ich habe aktiv am offenen ReqIF-Standard mitgearbeitet und zu dessen Verbreitung beigetragen, unter anderem über die von mir mitentwickelte Software, dem Eclipse Requirements Modeling Framework (RMF). Ich habe Community Building betrieben, indem ich die sehr aktive rheinjug aufgebaut habe, was dem offenen Wissensaustausch dient. Und über meine diversen Veröffentlichungen und Vorträge lege ich ebenfalls mein Wissen offen.

Ich habe viele Geschichten gehört die berichten, was bei Nicht-Offenheit geschieht. Zwei große Themen sind Vendor-Lock-In und Insellösungen: Man muss sich bei einer Lösung auf die Ergebnisse eines einzigen Unternehmens verlassen. Das offensichtliche Beispiel ist Software, von der man abhängig wird. Das kann jedoch relativiert werden, wenn die Formate der Software offen sind, also die Artefakte von anderen Werkzeugen verarbeitet werden können. Wenn diese auch proprietär sind, dann ist man wirklich abhängig.

Anwendungsbereiche für Offenheit

Mit den Teilnehmern zusammen erarbeiteten wir eine Liste von Bereichen, in denen Offenheit zur Anwendung kommt. Das war insofern wichtig, da wir hier klarstellen dass es nicht nur um Open Source, sondern alle Aspekte der Offenheit ging. Aber so viele Bereiche haben wir gar nicht gefunden:

Offenheit im SE tritt primär in vier Bereichen auf: Open Source, Standards, Wissen und Architekturen.

Open Source: Daran denken die meisten bei Offenheit im Systems Engineering. Zu beachten ist hier, dass offen nicht das selbe ist wie kostenlos. Es gibt durchaus kommerzielle kostenpflichtige Software, bei der der Quellcode mitgeliefert wird.

Offene Standards: Standards können an vielen Stellen ansetzen, von Format (bspw. Programmiersprachen), Vorgehen und vielem mehr. Auch hier gibt es Abstufungen, manche Organisationen stellen Ihre Standards nicht kostenlos zur Verfügung.

Offenes Wissen: Dies kann viele Formen annehmen, wie Konferenzen, Veröffentlichungen, etc. Hier sollte ein Augenmerk auf die Lizenzen gelegt werden, wie die Creative Commons-Lizenzen.

Offene Architekturen: Hier wurde insbesondere AUTOSAR diskutiert (wobei auch AUTOSAR nicht komplett offen ist). Architekturen ermöglichen eine Kollaboration und Skalierbarkeit auf einer anderen Abstraktionsebene.

Mehrwert von Offenheit

Die Einsatzbereiche waren nun geklärt. Jetzt kam die für mich interessanteste Frage: Wo wird der größte Mehrwert von Offenheit gesehen? Dazu erstellten wir zunächst gemeinsam eine Liste von Mehrwerten. Im folgenden durfte dann jeder Teilnehmer zwei Punkte vergeben.

Mit fünf Stimmen bekam Transparenz mit Abstand die meisten Stimmen. Das macht auch Sinn, denn Transparenz ist die Grundlage für viele der anderen Mehrwerte, wie Security oder Langzeitwartung.

Ich kenne genug Geschichten, wo die Abhängigkeit von einem Anbieter Probleme bereitet hat. Unabhängigkeit – in der Form von Software und Standards – kann hier einen wichtigen Schutz darstellen.

Das Thema Wissensgewinn ist im Bereich Software eher marginal, aber in den anderen Bereichen (Standards, Wissen, Architekturen) signifikant. Insbesondere schlägt sich Wissen oft in Standards und Architekturen nieder, wodurch der technische Fortschritt beschleunigt werden kann.

Langzeitwartung ist eines der zentralen Themen von PolarSys, und aus diesem Grunde hat die Eclipse-Foundation eine eigene LTS-Initiative. In dieser Gruppe wurde das Thema zwar wahrgenommen, aber nicht mit der selben Dringlichkeit wie bei PolarSys. Das selbe gilt für Security, welche in der Öffentlichkeit oft als Grund für Open Source  aufgeführt wird.

Produktfokus wurde hier als Gegenteil zu Umsatz-, bzw. Profitfokus aufgeführt. Da schwang ein bisschen der Idealismus mit, der in der Open Source-Community oft zu finden ist. Ich finde diesen Mehrwert nicht ganz so überzeugend, denn langfristiger Erfolg kann (meiner Meinung nach) nur erreicht werden, wenn der Kunde einen klaren Mehrwert hat.

Weitere Bereiche

Die folgenden gesammelten Themen bekamen nur einen Punkt:

Safety: Diesen Bereich haben wir mit Haftung und Risiko kombiniert. Es war aus der Diskussion herauszuhören, dass Safety auch mit nicht-offenen Mitteln gut in den Griff zu bekommen ist.

Tool-Integration: Hier fiel auch der Begriff Hackability, also die Möglichkeit, selbst anzulegen. Dieses Thema ist sehr softwarelastig. Aber auch geschlossene Software kann dies ermöglichen, zum Beispiel über Skriptsprachen.

Gar keinen Punkt bekamen Kontrolle, Verbreitung, Marketing und Innovation.

Und Kosten?

Es mag überraschen, dass niedrige Kosten nicht explizit aufgeführt wurden. Allerdings wurde das Thema angesprochen. Es gab keine Illusionen, dass im Bereich Software die Lizenzkosten nur ein Teil der Investitionen darstellen – Total Cost of Ownership (TCO) war hier das Stichwort. Damit soll nicht gesagt werden, dass über Open Source die Kosten nicht gedrückt werden können – das ist durchaus möglich. Aber das war nicht die Erwartungshaltung – jedenfalls nicht in dieser Gruppe.

Konkrete Ideen

Mein Ziel der Session war, konkrete Treiber für Offenheit zu identifizieren. Natürlich schwingt hier das durchaus eigennützige Interesse mit, darauf aufbauende Geschäftsfelder zu identifizieren.

Hier äußerten die Teilnehmer viele Wünsche und Frustrationen. Aber letzten Endes lassen sich fast alle genannten Treiber auf eine konkrete Idee reduzieren:

Der wichtigste Treiber für Offenheit: Standardisierung

Standardisierung bedeutet, einen Standard zu haben, der weit verbreitet und damit akzeptiert ist. Das ist der eigentliche Zweck eines Standards, aber leider ist Standardisierung selbst keine Selbstverständlichkeit.

Um den Grad der Standardisierung zu erhöhen, wurden eine Reihe von Maßnahmen identifiziert:

Bei Standards gibt es drastische Unterschiede in der Qualität, eine Erfahrung die ich teilen kann. Der ReqIF-Standard zum Beispiel ist nicht nur gut geschrieben und strukturiert, das zugrunde liegende Datenmodell wird sogar gleich mitgeliefert.

Ein spannender Vorschlag war, Standards mit einer Open Source Referenzimplementierung zu kombinieren, was wir beim ReqIF-Standard übrigens mit Eclipse RMF auch gemacht haben.

Auch wurde der Wunsch geäußert, durch systematisches Social Networking sicherzustellen, dass die Stakeholder eines Standards auch von diesem erfahren würden.

Nächste Schritte

Damit haben wir zwar einen Maßnahmenkatalog, wie es weitergeht ist aber noch unklar. Für mich ist dies eine Bestätigung, dass wir bei ReqIF vieles richtig gemacht haben, und ich werde diese Aktivitäten weiter vorantreiben.

Falls Sie Vorschläge haben, wie wir diese Ergebnisse verwerten können, hinterlassen Sie einen Kommentar, um die Diskussion hier im Forum fortzuführen.