Kapitel zu offenen Schnittstellen

[DirkGern]

@xdoo, Du hast schon Recht, dass Schnittstellendefinition und FOSS grundsätzlich nicht dasselbe sind. Aber auch das Thema offene Schnittstellen ist uns wichtig und würde ich gerne im Konzept verankern, wenn auch mit einer anderen Begründung. Vielleicht kann man das noch bissl schärfer abgrenzen?

Hier werden sehr viele Dinge vermischt :)

1. Die Technologie spielt eine eher untergeordnete Rolle. Aber man kann sie natürlich hier in so einem Papier erwähnen. Ich würde hier aber eher von einem standardisierten Protokoll sprechen. Das kann REST sein, aber auch so etwas wie SOAP oder JMS. Wobei REST das am wenigsten standardisierte Protokol ist.
2. Fachliche Austauschformate (z.B. XÖV) spielen vor allem im Austausch mit anderen Behörden eine Rolle. Da sind die auch schon ganz stark vertreten und zumeist auch vom Gesetzgeber vorgeschrieben (z.B. im Meldegesetzt). Diese Formate sind eigentlich vom Protokoll unabhängig, es haben sich aber einige Protokolle eingebürgert, bzw. werden vom Gesetzgeber vorgeschrieben (z.B. OSCI).
3. Für die interne Integration einer Fachanwendung (z.B. in ein Portal, aber auch von Fachanwendung zu Fachanwendung) wird einfach nur eine Schnittstelle benötigt, die fachlich das abildet, was benötigt wird. Es fällt mir ehrlich gesagt schwer, das in einer OSS Strategie zu sehen. Das ist eher eine Frage der speziellen fachlichen Anforderungen.

_Originally posted by @xdoo in https://github.com/missgreenwood/foss-concept/pull/9#discussion_r500512443_

[klml]

Es fällt mir ehrlich gesagt schwer, das in einer OSS Strategie zu sehen.

Im strengen Sinne von Open Sourcecode natürlich nicht. Aber OpenSource bedeutet ja auch "Schreibe Programme so, dass sie zusammenarbeiten." (aus der Unix-Philosophie)

Die Koalitionsvereinbarung spricht von offene Standards. Laut fsfe ist ein offener Standard ein Format oder Protokoll. Daher würde ich den Begriff offene Schnittstellen gar nicht verwenden, sondern nur offene Standards im Sinne von Format oder Protokoll. Also würde man da ableiten: wir nutzen das offene Format html mit dem offenen Protokoll https. Und nicht mehr Adobe Flash;)

Auch würde ich das nicht zwingend auf die fachlichen Austauschformate XÖV und OSCI etc. einschränken. Dort ist es wie von @xdoo schon erwähnt, vom Gesetzgeber vorgeschrieben. Sondern auf alle IT Kommunikation anwenden, eben schon auf jede "interne Integration einer (Fach)anwendung". So sind dann in ganz allgemein auch bei nicht-fachlichen und nicht hoheitlichen Anwendungen immer offene Standards zu nutzen. Bei z.B. Identity Broker eben OpenID Connect, OAuth oder SAML.

[atdotde]

Das entscheidende ist, dass die Formate offen zugänglich dokumentiert sind und ohne Patentbeschränkungen etc nutzbar sind. Und wenn man etwas schon vorhandenes benutzt und sich das nicht selber aus den Fingern saugt, steigt auch die Chance, dass andere Produkte damit interagieren können.

[klml]

Und wenn man etwas schon vorhandenes benutzt und sich das nicht selber aus den Fingern saugt

Offene Standards sollten nicht nur für Eigenentwicklungen, sondern auch für Beschaffungen gelten.

Bei Eigenentwicklungen sollten offene Standards schon Stand der Technik sein. Bei Beschaffungen ist das imho schwieriger, weil Lieferanten proprietärer Software geschlossene Standards manchmal als Geschäftsmodell nutzen. Auch wenn man grundsätzlich sowieso nur FLOSS beschaffen sollte, wenn es keine funktionale FLOSS Alternative gibt, ist das manchmal nicht möglich. Aber dann kann man immer noch offene Formate und Protokolle fordern, auch bei der Beschaffung von closed source.

[hacklschorsch]

Offene Schnittstellen insbesondere auch für nicht offene Software ist IMHO eine gute Forderung, die wir an geeigneter Stelle aufnehmen sollten.

[klml]

Offene Standards als Basis ist doch schon aus #14 gepicked worden.

[missgreenwood]

Danke für die Klarstellung, Ihr Lieben! Ich denke, damit können wir das Issue schließen.