Offene Standards: Lösungen gemeinsam finden

Standards sind überall: vom HTML, mit dem dieser Text formatiert wurde, bis hin zum Layout von Tastaturen. Für beinahe alles gibt es einen Standard. Sie entstehen aus gesetzlichen Vorschriften (wie der Gurtpflicht), von Normungsgremien wie der IETF oder der ISO, durch Marktbeherrschung (z. B. die S3-API) oder aus der Zusammenarbeit der beteiligten Parteien.

Ich verwende den Begriff „offener Standard“ im Sinne von Open Source: Ein offener Standard ist frei zugänglich und kann von jedem übernommen, umgesetzt und erweitert werden. Offene Standards sind freiwillige Vereinbarungen zwischen Akteuren, die eine gemeinsame Lösung für ein gemeinsames Problem finden wollen.

Man kann ein Protokoll entwickeln, aber keinen Standard.

Ein Standard entsteht erst dann, wenn sich die betroffenen Akteure darauf einigen, wie ein gemeinsames Problem gelöst werden soll. Das Gleiche gilt für Erweiterungen. Wenn Ihre Erweiterung von anderen Entwickler*innen nicht übernommen wird, ist sie nur ein weiteres Protokoll und trägt wahrscheinlich eher zur Zersplitterung bei.

Die Etablierung und Weiterentwicklung von Standards ist daher ebenso eine soziale wie eine technische Frage. Dazu muss ein Konsens zwischen verschiedenen Parteien gefunden und kontinuierlich angepasst werden.

Andernfalls könnte es zu einem Szenario wie in dem folgenden XKCD-Comic von Randall Munroe kommen:

Wozu das Ganze?

Warum sollte man diesen Aufwand betreiben, anstatt einfach ein eigenes Protokoll zu entwickeln? Ist es nicht auch einfacher und schneller, eine eigene Lösung zu entwickeln?

Das Schwierigste bei der Entwicklung von etwas Neuem ist oft nicht, wie etwas funktionieren soll, sondern zu verstehen, was tatsächlich gebraucht wird. Die Zusammenarbeit an einer gemeinsamen Lösung eröffnet einem viel mehr Perspektiven auf das Problem. Das hilft dabei, sich nicht in eine Sackgasse zu manövrieren, die später in einer kostspielige Neuentwicklung münden könnte.

In vielen Fällen ist es aber auch erst ein gemeinsamer Standard, der eine bestimmte Funktion überhaupt möglich macht. Wenn ein Service mit Dritten kommunizieren muss, ist es weitaus einfacher, ein gemeinsames Protokoll zu implementieren, als für jeden einzelnen Dienst, auf den Nutzer*innen stoßen könnten, eigene Integrationen zu entwickeln und zu warten.

Die Vorteile eines Standards wachsen mit zunehmender Verbreitung. Je mehr Services ihn integrieren, desto größer wird der Vorteil für die Nutzer*innen, ohne dass sich der eigene Implementierungsaufwand erhöht. Ein wachsendes Ökosystem ermöglicht es zudem, auf bestehenden Open-Source-Implementierungen aufzubauen, anstatt bei Null anzufangen.

Wie fängt man damit an?

Das Ziel von OpenGeoMesh ist es beispielsweise, die Zusammenarbeit zwischen möglichst vielen Organisationen und Softwaretools zu ermöglichen. Die Entwicklung eines Protokolls reicht daher nicht aus; es muss ein allgemein anerkannter Standard etabliert werden.

Bevor eine Vereinbarung ausgehandelt werden kann, müssen potenzielle Nutzer*innen und Anwender*innen identifiziert werden. Sie sind auch die Expert*innen für ihre jeweiligen Arbeitsabläufe, Einschränkungen und Infrastruktur. Es lohnt sich außerdem, bestehende Lösungen zu recherchieren, um sicherzustellen, dass man das Rad nicht neu erfindet.

Standards profitieren selbst von Standards. Eine Einigung ist deshalb einfacher, wenn sie auf etwas bereits Etabliertem und Weitverbreitetem aufbaut. Bestehende Standards zu nutzen, verbessert die Kompatibilität mit der vorhandenen Infrastruktur, macht die Lösung für Nutzer*innen und Entwickler*innen intuitiver und reduziert den Implementierungsaufwand dank gegebenenfalls bereits verfügbarer Open-Source-Bibliotheken.

Mit den Beteiligten zu besprechen, was sie bereits nutzen, hat sich auch als wertvoll erwiesen, um potenzielle Optionen zu identifizieren. Diese unterscheiden sich in Beliebtheit, Komplexität, Implementierungsaufwand und langfristiger Wartbarkeit.

Ein wichtiger Schritt ist die Klärung des Geltungsbereichs des neuen Standards. Welche Aspekte sollte der neue Standard abdecken? Welche sollten an bestehende Standards delegiert werden? Was sollte für zukünftige Iterationen offen gelassen oder explizit weggelassen werden? Dies ist ein schwieriger Balanceakt zwischen Komplexität, Benutzerfreundlichkeit und Interoperabilität. Eine Sache gut zu machen, reduziert die Komplexität, aber das Weglassen wichtiger Funktionen kann zu miteinander inkompatiblen Implementierungen führen.

Anforderungen entwickeln sich weiter. Um zu verhindern, dass ein Standard stagniert, muss definiert werden, wie Änderungen und Erweiterungen vorgeschlagen und übernommen werden. Man kann Anwender*innen nicht vorschreiben, Aktualisierungen zu befolgen, also müssen sie von deren Wert überzeugt sein. Und ohne Weiterentwicklung verschlechtert sich die Interoperabilität oder der Standard wird schließlich ersetzt.

Klare Governance-Prozesse sind daher unerlässlich. Wie können Änderungen zur Diskussion gestellt werden? Wie wird eine Entscheidung über eine Änderung getroffen? Sollte sich der Standard an einer etablierten Normungsorganisation wie der IETF orientieren oder sollte er von der Community gesteuert werden?

Die Ergebnisse dieser Diskussionen müssen in einer prägnanten Spezifikation zusammengefasst werden, die alle notwendigen Details für die Erstellung interoperabler Implementierungen enthält. Dieses Dokument dient auch als gemeinsamer Bezugspunkt und hilft dabei, ungelöste Fragen und Meinungsverschiedenheiten aufzudecken.

Eine formelle Abstimmung kann eine Einigung bestätigen, doch der wahre Test für einen Standard ist seine Akzeptanz bei Entwickler*innen und Nutzer*innen.

Erfahrungen aus der Arbeit an OpenGeoMesh

Die Idee zu OpenGeoMesh entstand während eines Waldbrands in den Bergen. Feuerwehrleute und Bergrettungsteams mussten in schwierigem Gelände zusammenarbeiten, um den Brand unter Kontrolle zu bringen und die Sicherheit der Einsatzkräfte zu gewährleisten. Da es keine Schnittstellen zwischen ihren Lageverwaltungssystemen gab, mussten Lagepläne auf Papier gezeichnet oder über Screenshots und Fotos per WhatsApp ausgetauscht werden.

Ich bin Teil eines Teams von ehrenamtlichen Softwareentwickler*innen innerhalb der bayerischen Bergrettung, also fing ich an, mit anderen Entwickler*innen über mögliche Lösungen zu diskutieren. Diese Gespräche weiteten sich schnell auf andere Rettungsdienste und Anbieter*innen von Lageverwaltungssoftware aus. Bald erzählte ich jedem, der zuhören wollte, von OpenGeoMesh, was zu unerwartetem Interesse führte, beispielsweise von kommunalen Dienststellen, die nach sicheren Wegen suchten, Karten sensibler Infrastruktur mit Auftragnehmer*innen auf Baustellen zu teilen.

Im Nachhinein hätte die frühzeitige Einrichtung gemeinsamer Diskussionskanäle die Koordination vereinfachen können, anstatt die Beteiligten einzeln anzusprechen. Zwei zentrale Anforderungen kristallisierten sich heraus: strenge Zugriffskontrollen aufgrund der Sensibilität der ausgetauschten Daten und Dezentralisierung, um den fortlaufenden Betrieb bei Internetausfällen zu gewährleisten.

Wir evaluierten föderierte Protokolle wie ActivityPub und OpenCloudMesh. Auch P2P-Protokolle wurden in Betracht gezogen, doch ihre Integration in bestehende Systeme, insbesondere hinsichtlich der Authentifizierung, wurde als zu komplex erachtet.

Wir haben uns schließlich entschieden, unsere Arbeit auf OpenCloudMesh zu stützen. Sein Zweck deckt sich eng mit dem von OpenGeoMesh ab, und es unterstützt ausdrücklich die Kombination mit anderen Transportprotokollen. Seine Spezifikation konzentriert sich ausschließlich auf die Erkennung von Sharing-Servern und den Austausch von Zugriffsmetadaten, was es uns ermöglichte, schnell einen funktionierenden Prototyp zu implementieren. Einige Unklarheiten im Spezifikationsentwurf wurden durch die direkte Teilnahme an der IETF-Arbeitsgruppe geklärt.

Für den Austausch von Geodaten ist eine strukturierte und flexible API erforderlich. Der etablierteste Standard in diesem Bereich ist WFS des Open Geospatial Consortium. Während dieser Standard bereits von einigen Anbietern von Situationsmanagement-Software verwendet wird, wird OpenGeoMesh auf dessen Nachfolger OGC API - Features basieren. Da dieser von den meisten Open-Source-GIS-Servern unterstützt wird, ist der zusätzliche Wartungsaufwand akzeptabel. Es wird erwartet, dass OGC API - Features langfristig WFS ablösen wird und moderne API-Praktiken ermöglicht, ohne XML- und JSON-Payloads zu vermischen.

Der Standard ist in modulare Bausteine gegliedert. Durch die Auswahl einer kleinen zwingenden Untergruppe konnten wir den anfänglichen Implementierungsaufwand begrenzen und gleichzeitig Raum für zukünftige Erweiterungen lassen.

Zur Unterstützung von Rettungsdiensten müssen Lagekarten den aktuellen Stand der Rettungsmaßnahmen klar darstellen. In Deutschland gibt es strenge Richtlinien, wie bestimmte Ereignisse unter Verwendung eines festen Satzes von Symbolen und anderen Kartenobjekten dargestellt werden müssen. Um diese in GeoJSON darzustellen, haben wir das Situation Data Exchange Format (SDXF) übernommen, das sich nahtlos in OGC API - Features integrieren lässt.

Während des gesamten Prozesses wurden die Diskussionen kontinuierlich durch Prototyp-Implementierungen unterstützt, um die verschiedenen Optionen zu erkunden und ihre technische Machbarkeit zu validieren. Dies führte zu einer Reihe von wiederverwendbaren Bibliotheken, die die Einführung von OpenGeoMesh vereinfachen. Inzwischen arbeiten bereits die ersten Anbieter an eigenständigen Implementierungen – ein vielversprechendes Zeichen dafür, dass OpenGeoMesh an Fahrt gewinnt.