Für mich bedeutet dies mehrere Dinge:
Die Anwendung
- ist nach den zwölf Faktoren - 12factor.net - gegliedert und lässt sich in immutable infrastructure deployen
- ist in einer leicht zugänglichen Sprache mit lebendigem Ökosystem geschrieben - JavaScript, Python, Rust, Go, Ruby
- lässt sich auf einem Raspberry Pi oder lokal auf dem Laptop/Desktop betreiben
- produziert Daten in einem leicht austauschbaren Format mit menschen- und maschienenlesbarem Schema - small data, CSV, JSON, RDF
- präferiert lose gekoppelte, generische Storage Interfaces - LDP/Solid¹, Remotestorage² - gegenüber enger Kopplung an anwendungsspezifische APIs
- verwendet gängige Authentifizierungsmechanismen
¹ https://solidproject.org/, https://ruben.verborgh.org/blog/2013/11/29/the-lie-of-the-api/, https://ruben.verborgh.org/blog/2016/08/05/use-the-web-instead/
² https://remotestorage.io, http://unhosted.org/
Weitere Anregungen kommen von https://www.inkandswitch.com/local-first.html und https://runyourown.social, welche die idealisierten Welten von P2P/Mesh-Netzwerken und der ActivityPub-Föderation in den Blick nehmen.
Bezüglich deiner Frage nach Service Systems Design können wir auch mit David Ing von https://coevolving.com/ sprechen. Er arbeitet mit Mustersprachen (sic!) und bedient sich dafür auch des #verbundwiki s. Anfragen könnten wir über die Communitytools der Open Learning Commons des Digital Life Collectives stellen, aus welchem ich auch unregelmäßigen Kontakt zu Robert Best habe.