FOSS-Report: Valueflows

Der Keimform-Blog steht ist in seiner Tradition verbunden mit Freier Software und den sich daraus ergebenden Potentialen. Im Projekt ,Global Commoning System’ haben wir in den letzten Jahren nach Entwicklungen der (Freien) Informationstechnik Ausschau gehalten, mit denen Commoning als Lebensweise gefördert werden könnte. Das Projekt ValueFlows hat dabei für uns besondere Bedeutung erhalten. Da es über ValueFlows möglich wird, größere Infrastruktur aus voneinander unabhängigen Software-Projekten aufzubauen (ein Gegenmodell also zu zentralen Plattformen), möchte ich an dieser Stelle einen kurzen Einblick geben: Zu dem, was ValueFlows ist, zur Entstehungsgeschichte des Projektes, zu zwei Projekten mit ValueFlows-Implementierung (Bonfire & HoloREA) und zu einer wesentlichen, damit einhergehenden Problematik.

Was ist ValueFlows?

Im Projekt ‚Global Commoning System’ sind wir mit ValueFlows ziemlich früh in Kontakt gekommen, haben aber (zu) lange nicht wirklich begriffen, worum es geht. Erst einmal die Projektbeschreibung in den eigenen Worten von ValueFlows:

The vocabulary will work for any kind of economic activity, but the focus is to facilitate groups experimenting with solidarity / cooperative / collaborative / small business ecosystem / commons based peer production / any transitional economies. We want to enable internetworking among many different software projects for resource planning and accounting within fractal networks of people and groups. Specifically, we want to support resource flows connecting many software applications.

ValueFlows ist also ein Vokabular (bzw. eine ‘Ontologie’) im Kontext des semantischen Webs, durch welches sich die Bewegung von Ressourcen beschreiben lässt. Das gesetzte Ziel ist, dass durch dieses Vokabular verschiedenste Projekte/Entwicklungen auf maschineller (aber auch menschlicher) Sprache miteinander interagieren, sprich: gemeinsam Ziele erreichen können. Es wird sich damit entfernt von einer Idee namens “Wir starten ein Software-Projekt und wenn alle unsere Software benutzen, dann kann (x) erreicht werden” und sich angenähert an “Wir entwickeln ein Software-Werkzeug, mit dem Zweck (x) erfüllt werden kann und gliedern diese in eine bestehende Infrastruktur ein”.

Kurz angemerkt: Warum könnte uns das Projekt ValueFlows als Commoner:innen interessieren? Unabhängig davon, wie ‘Commons’ und ‘Commoning’ definiert werden, geht es im Commoning auch darum, wie mit den Dingen der Welt (Wälder, Wohnraum, Zahnbürsten, etc.) umgegangen wird. Ein Aspekt dieses Umgangs mit Dingen der Welt ist deren Bewegung: Einerseits natürlich deren Ortsveränderung (der Spargel vom Acker der Solidarischen Landwirtschaft muss die Ernte-Teilhaber erreichen), anderseits Bewegung in der Verfügung über diese Dinge (einer Person wird Zugang zu einer gemeinsame Werkstatt gewährt). Die Information über solche Bewegungen, bzw. der Informationsaustausch zur Ermöglichung solcher Bewegungen, kann unbedingt mit Informationstechnik unterstützt werden; und ab einer bestimmten Komplexität des Commonings muss es das vielleicht auch. ValueFlows hilft dabei, dass relevante Informationen zwischen der Software-Anwendung einer Solidarischen Landwirtschaft und der Software-Anwendung einer ‘Küche für alle’ ausgetauscht werden können, auch wenn diese unabhängig voneinander entwickelt wurden und verschiedene Technologien (Programmiersprachen oder Protokolle) verwenden.

Relevante Links an dieser Stelle: Website, Einführung, UML-Diagram.

Entstehung von ValueFlows

Zum besseren Verständnis des Projektes, finde ich es äußerst hilfreich, die Entstehungsgeschichte von ValueFlows anzusehen: ValueFlows entstand aus dem Projekt Mikorizal, einem so bezeichneten Network-Ressource-Planer (NRP) als Abgrenzung zu Enterprise-Ressource-Planer (ERP)-Software. Mikorizal sollte alternativ-ökonomischen Projekten die Möglichkeit der gemeinsamen Vernetzung bieten. Die Software allerdings war als Monolith aufgebaut, der irgendwann so groß und so komplex war, dass Änderungen schwer vorgenommen werden konnten und potentiell neue Entwickler:innen die Software-Architektur kaum noch verstehen konnten. Aus dieser Krise sind Jahre der Diskussion in einem dafür aufgebauten Forum entstanden. Die wichtigste Erkenntnis für die beiden Projekt-Verantwortlichen Bob Haugen und Lynn Foster war dabei, dass es keine bestimmte Software braucht, die alles können muss, sondern eine Sprache, mit der sich alles verbinden lässt. Auf Basis des ‘Resource-Event-Agent’-Modells entstand so das Projekt ValueFlows.

Das ValueFlows-Vokabular ist bereits in verschiedenen Entwicklungen implementiert, wobei zwei derzeit von größerer Bedeutung zu sein scheinen: Das Projekt Bonfire und das Projekt HoloREA.

Bonfire (und Activity Pub)

Das Freie Software-Projekt Bonfire baut auf dem Activity-Pub-Protokoll auf und implementiert ValueFlows zur Organisation von Ressourcen. Bevor sich aber Bonfire angenommen wird, was ist Activity-Pub und was ist das damit einhergehende Fediverse?

Das Fediverse: Es gibt dezentrale Alternativen sowohl zu Twitter als auch zu youtube, Instagram, facebook-events, facebook selbst und vielen mehr. Diese dezentralen Alternativen bilden das sogenannte Fediverse (federated universe) und heißen z.B. Mastodon, Peertube, Pixelfed, Mobilizon und friendica. Aber was ist deren Domain? Ganz knapp: Sie haben keine bzw. sie haben sehr viele verschiedene. Die Software-Anwendung werden auf jeweils eigenen Servern aufgesetzt und User:innen können sich dort anmelden. Diese User:innen bilden somit ein kleines lokales Netzwerk. Durch das Activity-Pub-Protokoll können diese Server allerdings Informationen untereinander austauschen und so können die User:innen der lokale Server mit potentiell allen User:innen von sämtlichen Servern in Beziehung treten. Dass es keine allgemeine Domain a lá “mastodon.de” gibt, kann für viele Neulinge verwirrend sein, ermöglicht aber, dass sich die lokalen Server ihre eigenen Regeln setzen und so etwa Kraftausdrücke oder kommerzielle Angebote in den eigenen Timelimes erlauben oder verbieten (siehe etwa ‘Server Rules’ auf graz.social). Besonders elegant am Fediverse ist dabei, dass auch zwischen Anwendungen verschiedener Art interagiert werden kann – so kann ich etwa als User:in von Mastodon (“Open-Source-Twitter”) einem Kanal von Peertube (“Open-Source-Youtube”) folgen.

Bonfire ist eine dieser dezentral aufsetzbaren Anwendungen des Fediverse und sieht auf dem ersten Blick aus wie ein gewöhnlicher Kurznachrichtendienst. Was Bonfire aber von gewöhnlichen Kurznachrichtendiensten unterscheidet, ist der Versuch ein Werkzeug aufzubauen, mit welchem die Organisation von Communities unterstützt werden kann. Das heißt, im Kern ist Bonfire ein soziales Netzwerk, dann allerdings lässt es sich mit einer Vielzahl verschiedener Modulen erweitern. Durch diese Module können etwa Aufgaben (Task-Modul) erstellt und mit bestimmten Personenkreisen geteilt werden. Oder es werden Ressourcen angegeben, die andere Personen der Community mitverwenden dürfen (Inventory Managment-Modul). Einige dieser Module nutzen dabei – insofern es sinnvoll erscheint – die ValueFlows Ontologie.

Das Projekt Bonfire ist derzeit im Beta-Status und kann auch schon ausprobiert werden. Das Projekt ist außerdem auf der stetigen Suche nach neuen Entwickler:innen. Da Bonfire das Potential hat einen wichtigen Beitrag zur Unterstützung einer auf Commoning basierten Lebensweise zu bieten, würde ich Freien Entwickler:innen auf der Suche nach emanzipativen Projekten auf jeden Fall empfehlen, sich Bonfire näher anzusehen.

HoloREA (und Holochain)

HoloREA ist der Versuch, ValueFlows in das Holochain-Protokoll zu implementieren. Wer Silke Helfrich und David Bolliers Werk “Fair, Frei und Lebendig” gelesen hat, wird vielleicht schon von dem Holochain-Protokoll gehört haben (siehe FFL S.298-306). Helfrich und Bollier sind regelrecht begeistert von den Potentialen dieser Technologie und beziehen sich dabei besonders auf den ‘akteurszentrierten’ Ansatz der Holochain. Was also ist die Holochain? Ich trage nur gefährliches Halbwissen in mir und möchte auch nach zahlreichen Erklärungsvideos und -texten gar nicht versuchen, die Technologie hinter Holochain zu erklären. Was ich soweit verstehe ist, dass es ein Framework ist, um tatsächlich serverfreie Web-Anwendungen zu ermöglichen, in welchen persönliche Daten rein auf den Endgeräten der Nutzenden vorhanden sind und diese Nutzenden die alleinige Kontrolle darüber haben, wie mit diesen Daten umgegangen wird.

Um hier noch mehr Fragen als Antworten hinzuzufügen: Ein anknüpfendes Projekt an Holochain ist die ‘Commons Engine’, doch um was es in diesem Projekt konkret geht, konnten wir als Team des ‘Global Commoning Systems’ nie wirklich begreifen. Da vor zwei Jahren im Projekt ‘Commons Engine’ auf ein Video mit Silke Helfrich verwiesen wurde, haben wir damals Silke selbst angefragt, ob sie uns beim Verständnis weiterhelfen kann. Tatsächlich hatte sie von der ‘Commons Engine’ selbst noch nie gehört, aber war mit manchen der Verantwortlichen bekannt und hat uns besonders ihr Vertrauen gegenüber Ferananda Ibarra beteuert. Wer hier eine nähere Idee hat, was das alles ist: Schreibt es bitte in die Kommentare!

Eines lässt sich zumindest an dieser Stelle sagen: In dieser Holochain-Welt geht etwas vor sich, das für Laien wie mich schwer verständlich ist, aber zumindest einiges verspricht. Und wenn aus dieser Holochain/HoloREA-Sache etwas wird, dann ist ValueFlows das Kitt zwischen dieser Technologie und der übrigen Welt des, grob gesagt, alternativ-ökonomischen IT-Bereiches. Das mag alles etwas abstrakt klingen, aber in diesem Text gilt immer noch die Vorannahme, dass Commoning als Lebensweise Komplexität mit sich bringt und es Informationstechnik braucht, um damit umzugehen. Wird die Vorstellung von zentralen Plattformen, mit denen quasi alles organisiert wird, abgelehnt (und persönlich mache ich das unbedingt), dann braucht es einerseits Protokolle wie Activity-Pub und Holochain, aber eben auch Möglichkeiten der Verbindung solcher Technologien wie ValueFlows.

Geteilte Sprache als Herausforderung

ValueFlows ermöglicht ein Zusammenspiel verschiedenster Software-Projekt, erzwingt aber auch die Verwendung der eigenen Ontologie. So sind etwa sämtliche Dinge der Welt klar als ‘Ressourcen’ bezeichnet; ein Begriff, den Helfrich und Bollier klar ablehnen (“Der Begriff Ressource lädt ein, gemeinsame Vermögenswerte als etwas zu betrachten, das gefördert, ausgebeutet, genutzt und in ein Objekt wirtschaftlicher Berechnung verwandelt werden soll.”, FFL S.75).

Ich sehe vier Möglichkeiten, wie auf diese Problematik reagiert werden kann:

  1. Eigensinnigkeit: Auch in diesen informationstechnischen Kontexten nur Begriffe verwenden, hinter denen gestanden wird und somit auf eine gemeinsame Ontologie (hier: ValueFlows) verzichten.
  2. Übersetzung: In informationstechnischen Kontexten eigene Begriffe verwenden, aber ein Glossar anbieten, in welchem auf die Begriffe einer gemeinsamen Ontologie verwiesen wird
  3. Einmischung: Sich in das Ontologie-Projekt einbringen und versuchen problematische Begriffe ersetzen zu lassen.
  4. Unterordnung: Die vorgegebene Begriffe einer verbreiteten Ontologie in informationstechnischen Kontexten übernehmen, wenn diese Begriffe auch problematisch sein mögen.

Auch wenn es sich in vielen Fällen nicht gut anfühlt, habe ich mich (nach längerer innerer Auseinandersetzung) persönlich für die vierte Möglichkeit, die Unterordnung, entschieden. Auch wenn es bei manchen Begriffen schmerzt, sehe ich mittlerweile das gemeinsame Ziel als wichtiger an, als den richtigen (womöglich emanzipativeren) Ausdruck. Ob das allerdings der richtige Weg ist, weiß ich nicht.

Unterkomplexität in der Regelsetzung

Eine auf Commmoning basierte Lebensweise unterscheidet sich von den meisten anderen post-kapitalistischen Gesellschaftsentwürfen, indem sich besonders deutlich von der willkürlichen Verfügung über die Dinge der Welt abgegrenzt wird. Der gemeinsame Umgang mit den Dingen der Welt, sowie weitere Formen der polyzentrischen Governance, bringen die Notwendigkeit von Absprache und Regelsetzung mit sich. Regeln in all ihrer möglichen Komplexität standardisiert erfassen zu können, ist dabei alles andere als ein einfaches Anliegen. Es wundert daher nicht, dass es in der ValueFlows-Ontologie keine entsprechenden Begriffe gibt, um sämtliche auf Ressourcen bezogene Regeln beschreiben zu können.

ValueFlows muss dabei auch nicht alles leisten können, wenn es einen anderen Offenen Standard hierfür gibt. Als Projekt ‘Global Commoning System’ haben wir einen solchen Standard für Regeln allerdings noch nicht gefunden. Die ‘Institutional Grammer 2.0’ (IG2.0) der ‘Institutional Grammer Research Initiative’ geht hier in eine sehr spannende Richtung – aber was dieses Projekt macht, wäre noch einmal ein ganz eigenes Thema.

3 Kommentare

Entdecke mehr von keimform.de

Jetzt abonnieren, um weiterzulesen und auf das gesamte Archiv zuzugreifen.

Weiterlesen