Why not value flows? :-)

Hey there,

maybe I should write in german, because that’s the language people seem to be using here.

Laut erstem git commit wurde https://www.valueflo.ws/ in 2013/2014 gestartet.
Laut allem was ich finden kann gibt es issmit seit ca. 2020.

Die Idee die auf der Webseite im Video praesentiert wird ist wunderbar.
Die dahinterliegende Software koennte jedoch das “value flows” Vokabular benutzen um offener und besseren Austausch mit anderen Projekten jetzt und in der Zukunft zu ermoeglichen.

Im Beitrag “Technologien die zu uns passen”

wird unter anderem Holochain erwaehnt, welches hREA ebenfalls bereits deren Software auf valueflows basieren.
Ich selber bin aktiv in SSB und DAT, welche p2p software system ermoeglichen, aber keine Meinung zu oekonomischem Austausch haben. Ich selbst arbeite an einem Projekt das auf dat basiert und ebenfalls versuchen wird “valueflows” zu adaptieren.

Ich glaube fuer den Erfolg eine offenen Oekosystems als Alternative zum traditionellen Web 2.0 ist es sehr wichtig sich auf offene Standards zu einigen und einen neuen Kandidaten fuer einen Standard vorzuschlagen sollte gut begruendet werden.

Falls issmit neue Konzepte entwickelt die mit dem relativ minimalistischen Konzept von valueflows nicht abgebildet werden koennen waere ich sehr daran interessiert zu sehen wie “issmit” effizienter oder “minimalistischer” oder bessere" Nutzerfreundlichkeit"

Hier kann man mit der valueflows community leicht interagieren:

https://gitter.im/valueflows/welcome

oder

Uebersicht gibts hier
https://www.valueflo.ws/introduction/concepts/

Ein Umfassendes Diagram das “etwas” komplizierter ausschaut gibt es hier
https://www.valueflo.ws/specification/uml/

Man muss bei letzterem jedoch bedenken, dass dies wirklich ALLES beinhaltet das value flows ausmacht und daher auch jede moegliche Aktivitaet, Planung, Realitaet, etc… im gesamten potentiell globalen Versorgungsnetzwerk bzw. Lieferketten/Liefernetzwerken bzw. jedwede kooperation innerhalb und zwischen Unternehmen abbilden kann.

Und in diesem Kontext ist vielleicht sogar das etwas komplizierter anmutende UML diagram doch relativ simpel.

Darueber hinaus ist es seit 9 Jahren im Einsatz und wird in der Praxis ueberall getested und das Feedback fliest direkt in die weiterentwicklung der auf minimalismus ausgerichteten valueflows konzepte ein :slight_smile:

Nur so ein Gedanke.
Ich wuerde eine App wie ISSMIT definitiv benutzen, aber es waere wirklich wunderbar und machte Kooperation viel einfacher wenn vielleicht valueflows wenigstens erwaegt werden koennte :slight_smile:

1 Like

Hi Serapah! Welcome to the forum!

There was an attempt once, to communicate in english here, but it wasn’t good for our conservation flow, so we dropped it. Now we have a rule, that anything can either communicated in english or in german. Even when a a thread is in english, it could be answered in german and vice versa.

Vielen Dank erst einmal für den Beitrag! Ja, ValueFlows ist der Hammer und ein Projekt dem ich sehr dankbar bin. Tatsächlich haben wir uns auch entschieden, im Projekt das ValueFlows-Vokabular anzuwenden - wir haben daher gar keinen Widerspruch :slight_smile:

Unsere Kommunikation dazu ist leider noch verbesserungswürdig, aber schau mal in eine aktuelle Version der Konzeption:

Das zweite Kapitel (ab Seite 10) ist schon komplett so geschrieben, dass am Ende jeden Kapitels alle verwendeten Begriffe auf entsprechende ValueFlow-Vokabeln verweisen. Als wir auf das Vokabular umgestiegen sind, musste die Textereihe auch stark angepasst werden - was jetzt zum Beispiel “verteilter Planungsprozess” heißt, hieß zuvor “Konfigurationsprozess” und was damals “Konfiguration” genannt wurde, musste valueflows-gemäß in “Szenarien” und “Pläne” umgemodelt werden. Bei manchen Begriffen habe ich einen Widerstand sie einfach zu übernehmen (“Tätigkeitsmuster” sind bei VF “recipts” - und “Rezepte” finde ich in der Anwendung einfach schwierig), aber zumindest versuche ich in der Konzeption - in diesen grauen Kästen - entsprechend die Verbindungen zum VF-Modell herzustellen. In der Issmit-App ist es uns auch wichtig, dass in den Datenstrukturen die entsprechenden VF-Begriffe Verwendung finden. Die Umsetzung ist weniger mein Verantwortungsbereich, aber ich glaube, das ist da auf dem Schirm.

Deine Projekte sehen übrigens super spannend aus! Mir fehlt das technische Verständnis wirklich durchzublicken, was da gemacht wird, aber es fühlt sich richtig an. Falls du zum Beispiel mal Lust und Zeit hast, deine Gedanken teilen, wie die Issmit-App in Infrastrukturen eingebettet werden kann, dann würde ich mich sehr freuen, sie zu hören.

Super, klingt fantastisch dass Valueflows Vokabeln bereits uebernommen werden.
Naja, und was Rezept und Taetigkeitsmuster anbelangt, kann man zumindest objektiv sagen dass “Rezept” das kuerzere Wort ist und man das schneller aussprechen und tippen kann.

Und fuer alles andere ist es ja am ende eh blos Konvention bzw. wenn alle wissen was mit einem Wort gemeint ist ist das ja eigentlich gut genug.

Wo sich mir die Haare straeuben ist das PDF mit ~70 Seiten und kleiner Schriftgroesse.
Puh, das ist ne Menge zum lesen.

Was mit bei Valueflows geafaellt ist der Minimalismus.
Ich kann mich durch alle Seiten der Webseite inklusive dem UML Diagram innerhalb absehbarer Zeit durchlesen und verstehen. Ich glaube das traegt auch stark zur Motivation bei.

Es waere wunderbar wenn das ganze wesentlich modularer gestaltet werden koennte.

Also Beispiele sind gut, aber vielleicht koennen die Seperate sein und verlinkt werden.

Ansonsten, coole Sache und gut zu wissen dass es Valueflows-Kompatibel ist :slight_smile:

Ja, keine Frage - 70 Seiten als Zwischenstand machen keinen Spaß und ich zweifle daran, dass es viele Menschen lesen werden. Irgendwann gedruckt in Buchform wahrscheinlich eher, aber als pdf - no way. Aber wenn irgendwann der Konzeptionsprozess abgeschlossen ist, ist es mir auch wichtig, dass wir Texte und Videos haben, die sehr kurz und eben auch modular sind. Und ja: ValueFlows machen das richtig cool! Aber am UML-Diagramm habe ich persönlich mir schon auch manchmal die Zähne ausgebissen :smiley:

Ich versuch über diese Vorträge/Einführungen Interessierten zu ersparen, die Texte zu lesen. Zum Beispiel hier in der englischen Sprint-Version in 25 Minuten (die dt. Version ist z.B. noch ohne VF auf youtube):

So bei der Vermittlung ist halt vieles auch eine Zeit- und Aufwandsfrage. Super krass wichtig, aber im Prozess der Konzeption verändert sich dann alles wieder und alles was gemacht wurde, ist quasi umsonst. Hier zum Beispiel auf der project.-Seite, habe ich alles mit Unterkapiteln und verlinkbar in Markdown übertragen, inkl. verschiedene Bilder für Tag- und Nacht-Modus, und kaum ein halbes Jahr später kam das VF-Vokabular und ein paar konzeptuelle Änderungen, die damals schwer vorhersehbar waren, und alles ist wieder für die Katz bzw. müsste ewig nachgearbeitet werden (und ein Jahr später wieder und wieder). Dass die Konzeption noch läuft und die Umsetzung schon beginnt, ist mega cool, aber auch mit Problemen besetzt.

Stimme zu bzgl. UML Diagram.
Es braucht wenigstens ein Glossary dass die Begriffe im UML Diagram erklaert und in Beziehung setzt.

Ich persoenlich mag es so simpel wie moeglich.
Das UML Diagram ist mir persoenlich noch zu komplex und die Unterteilung in “Plan”, “Knowledge” und “Observation” auch nicht so super und wie ich gehoert habe ist das auch nicht fester Bestandteil von ValueFlows. Speziell die Unterteilung in “Knowledge” und “Economic Resources” ist fuer mich zwar verstaendlich aber ich stimme dem nicht zu.

Ich arbeite viel mit Open Source und Github Repositories und ein Document (z.b. eine Blaupause/Rezept/Code/Arbeitsanleitung) ist genau so ein “Output” an dem gearbeitet wird oder wurde und der auch verbessert werden kann wie jede andere “Economic Resource”.

Meine persoenliche Lieblingsunterteilung sind wahrscheinlich:

  1. Economic Events" als etwas dass beobachtet und aufgeschrieben wird und das beinhaltet ein Vertrauen und Bewertung in dem Sinne dass etwas das vermeintlich in der Realitaet passiert nun in einem System als “Fakt” festgehalten wird und dadurch dann bestimmte Veraenderungen “triggeren” kann

  2. “Resources” was alles beinhaltet inkl. Rezepte oder wie man auch immer Blaupausen fuer alles moegliche nennen will und technisch beinhaltet das sogar Plaene.

  3. “Plans” ist wie grade erwaehnt ja vielleicht auch eine Resource an der gearbeitet wird, aber im Unterschied zu allem anderen bezieht sich dies auf die Zukunft und ist daher schwebend und in gewisser Weise macht es viel Sinn fuer mich das besonders zu behandeln.


Im Video wird in der Einleitung

  • Basics
  • Structure
  • Activity Patterns
  • Means
  • Distributed Planning Process
  • Consideration

beschrieben, aber keines davon ist wirklich intuitiv fuer mich in dem SInne dass es sich direkt in programmcode uebersetzen laesst.


Watching the video, I still have many open questions.
The main issue is the free riders. The selfish people who genuinely don’t give a fuck.
There needs to be mechanisms for communities to protect themselves and the commons from them.
Only if the peeople engaging in selfish reckless free riding or greedy activities learn that they can’t get through with their behavior anymore and it costs them more than they gain, they will essentially consider joining the global commoning system as a fair system that works for everyone.

But as long as they can abuse it, they will continue that pattern.

need (n-) → mediation → activity → satisfaction (n+)
demand of means (m-) availability of means (m+)
means in problematic condition (c-) means in defined condition (c+)

I like the “acitivity pattern” (but prefer “recipe”) and that it captures “(negative) side effects” like dirty ovens :stuck_out_tongue: Also I prefer (resource over means) :stuck_out_tongue:
I personally prefer vocabulary that doesn’t sound as if it talks about people and how people organize, kinda top down as if it was a central planner planning for everyone, but rather language that promotes an interactive peer to peer process to come up and refine those in practice to work together and empowers everyone. Vocabulary to communicate those things between each other in the context of life and work rather than language that sounds as if people are put into a giant machinery planned from above.

I think the value flows vocabulary does a better job in that regard when i watch the video.

-------------__

also the technical diagram looks fancy and as if it was all rock solid facts, like a machine.
But still my question above remains, because it is all about people, so therefore it needs some sort of game theoretic considerations, which concern themselves with “schelling points” and overcoming “prisoner dilemmas” a.k.a. “nash equilibriums”, “pareto optimal” etc…

By the way.
I understand everyone could maybe express their needs and what they offer or rather the means and then the software could automatically propose activities to all participants or rather match needs to means and activities, etc… but that is an NP complete problem to find an optimal solution.

So I really wonder if there are more details about this?
In the blockchain world, the GNOSIS project for example has some systems where in every “tick” or rather “time period” anyone can just propose a set of activities that maximize utility or rather use the resources best to satisfy most needs and whoever proposes the most optimal solution in that round gets a little reward and then the next time period starts.

That way it’s more like anyone can try to come up with the best heuristics or whatever to propose the best solutions. This is kinda a thing that is based on all the globally available options.

If you have some materials that go further into that, that would be cool. I really wonder how to solve that in practice :slight_smile:

“local first” sounds of course great - but again, if all systems are connected and networked, where are the boundaries? :stuck_out_tongue:

Vielen Dank erst einmal für dein tieferes Interesse!

Spannend, ja. Ich erinnere mich an frühere Diskussionen, in denen ich meine, dass @balkansalat ähnliches geäußert hat. Also konkret, dass Tätigkeitsmuster (recipes) ja auch Mittel sind, mit denen gearbeitet wird. Aber vielleicht ist das insofern passend in der “Knowledge”-Kategorie, dass sie “Wissensspeicher” sind bzw. der “Wissensvermittlung” dienen? Genauso eben wie eine Dokumentation oder Arbeitsanleitung, aber – um deinem Beispiel zu folgen – nicht unbedingt wie ‘Code’ im Allgemeinen, insofern er eben nicht nur Wissen abbildet. Aber ich sehe hier natürlich auch die Grenzen verschwimmen und dass es im sehr konkreten Fall schwierig wird, den tatsächlich passenden (und für Infrastrukturen kompatiblen) Begriff zu finden.

Spannend, dass sowohl Wissen als auch Plan in Ressourcen aufgehen können und es trotzdem sinnvoll ist / sein kann, sie getrennt zu behandeln. So wie du bei Plan die Unterscheidung erlaubst, würde ich dem Wissen auch diese Eigenständigkeit geben. Vielleicht, weil Wissen – als Gegensatz zum Plan – ja seinen Ursprung in der Vergangenheit als Erfahrung hat? Aber dieser Gegensatz scheint mir gerade zu einfach und vermutlich könnte ich das nicht zu Ende argumentieren.

Danke, ja! Das soll es aber auch nicht. Die Konzeption soll frei von jeglichem Gedanken der technischen Umsetzung sein. Es wird eine Infrastruktur beschrieben, mit deren Hilfe Commoning als gesellschaftliche Alternative zum Kapitalismus funktionieren könnte. Es ist dann ein zweiter Schritt, diese Infrastruktur in Werkzeuge aufzubrechen und ein dritter Schritt, diese Werkzeuge so in den Umlauf zu bringen, dass sie gerne zur Lösung bestimmter Probleme benutzt werden, wodurch hoffentlich 4. diese nicht-kapitalistische Gesellschaftlichkeit entsteht.

Ich habe mal einen Anlauf unternommen, die Infrastruktur in Werkzeuge und deren gegenseitige Abhängigkeiten zu teilen, wie es sich für mich sinnvoll angefühlt hat. Aber ich habe die Arbeit daran zeitnah eingestellt, da 1. eben die Konzeption noch nicht abgeschlossen ist und 2. es niemanden gab, für den/die das gerade relevant war. Aber das mal sinnvoll zu unterteilen steht spätestens nach Abschluss der Konzeption ganz oben auf der To-Do-Liste.

Yes, thank you! The video, but also most of the conception, deals inside an “open-access-scenario” and the free-riding-problems has its roots in open-access. This scenario is not a realistic one. The resources are ‘ruled’ in anyway, mostly with the rules of ‘private property’ beneath some state-settled constitutional rules etc. At the moment I mainly work on an introduction to Elinor Ostroms work, with the focus on a practical approach and how software-tools have to function to deal with commons-dilemma. I think, most questions of borders, protections, openness, fairness etc. of resource-systems and communities are questions of self-organized rules. As a software project we cannot (and should not) shape this rules, but we can support the process of people creating rules to deal with (their) commons.

I’m not quite sure if I understand it right. Did you have the feeling, the video sounds like people are “put into a giant machinery” or did you not have this feeling?

But I also think, that it’s not always about language. The strenght of ValueFlows, in my opinion, is, that it can be used to descripe very different economic models. So you can use the vocabulary to describe a dictatorship, but you can also describe the opposite. But of course, it is not that simple – Silke Helfrich for example, had huge problems with the word ‘resource’, as it gives for example ‘nature’ the purpose to be used.

There is a common misunderstanding (I try hard to avoid it in newer versions of this presentation), that the ‘Global Commoning System’ is a model. Like a model for society and persons have to act in a specific way. It is neither such a model nor it shall be “the way people have to do commoning”. We are aiming to build tools, that support commoning, that people can use to solve specific problems, but if they don’t need them, they should not use them. We cannot “prove” that it will be used and I don’t think, it is necessary. Building tools is independent from this. Hopefully it will be good tools and if they won’t be used, we have to question ourselfes why, but we don’t need calculations before - in my opinion.

Wenn es dich wirklich näher interessiert: in der Konzeption ab Seite 27 :slight_smile:

This is interesting, I like the idea. broken_pipe (I think he is only on our Matrix-Channel right now and not in the forum), also mentioned once, that there are more solutions for the same problems then the ones we are working with. And that’s definitly true. I will have a deeper look.

Good question! I struggle with the complexity of basic interactions since years, but the solutions are not scalable. Elinor Ostrom often speaks about polycentric structures - I have some hope, they could be an answer, but I cannot say more right now, because I don’t understand it further.

Sorry for the long text. Feel free to skip some topics.

Klar, Wissen hat seinen Ursprung in der Vergangenheit als Erfahrung (oder sollte zumindest).
Aber jede andere Resource hat ihren Ursprung auch ihn der Vergangenheit und die Herstellung war eine Erfahrung und die Nutzung der Resources vermittelt Erfahrung/Wissen …
Je besser die “Benutzeroberflaeche” einer Resource ist, desto weniger Dokumentation braucht es, denn die Resource vermittelt ihre Wissen automatisch.

Ich persoenlich sehe keinen grossen Mehrgewinn in der Unterscheidungvon Informationsresourcen und anderen Resourcen, wie z.b. Werkzeugen oder Maschinen, auch wenn natuerlich da ein Unterschied besteht - nur praktisch macht die Unterscheidung im System das System komplexer und die Frage fuer mich ist ob da irgendein Vorteil entsteht diese Unterscheidung zu taetigen und ob nicht die Unterscheidung dort wo die Grenzen verschwimmen noch mehr Komplexitaet im System oder unsaubere Kompromisse erzeugt.

Ansonsten scheint mir die Unterscheidung in Zukunft und schwebend vs. Aufzeichnen von Vergangenheit durch faktische Events schon wichtig.


Fue mich ist Programmcode keine Gedankeneinschraenkung und nichts technisches.
Fuer mich ist Programmcode einfach eine Weise sehr praezise eine Spezifikation aufzuschreiben die in erster Linie fuer Menschen die die Programmiersprache verstehen leserlich ist, aber gleichzeitig auch von der Maschine verstanden wird, so dass die Spezifikation ausfuehrbar wird und daher auch kein Detail uebergangen werden kann.

Dort wo Input von Menschen bzw. Usern erforderlich ist kann antuerlich Programm Kommentar ok sein und das ganze kann ja super simpel ueber Kommandozeilenausgabe und KommandozeilenEingabe passieren um das wesentliche fuer die Spezifikation zu erfassen, waehrend der Rest (fancy UI/UX) da unwichtig ist.

Meine Lieblingssprache hierfuer ist Javascript, weil die Sprache am weitesten verbreitet ist und von den meisten Menschen gelesen werden kann und weil es auch spaeter einfach erlaubt in Web Browsern die UI/UX zu verbessern.


Dein Link zu Werkzeugen der Emanzipation.
Klingt fuer mich gut.
Klingt fuer mich wie Software/Apps oder Komponenten um bestimmte Funktionen innerhalb des Systems “Global Commoning Systems” zu erfuellen.

Die Namen sind sehr Abstrakt bzw. akademisch in der Beschreibung.
Das ganze laesst viel Luecken im Detail ueber das konkrete Wie und Wo.
Aber klar, man muss irgendwo anfangen.
Hoffe jedoch dass das ganze irgendwann moeglichst bald in Praxis ueberfuehrbar ist.
Also wenn das Mapping nach Valueflows funktioniert und Valueflows nicht alle funktionien hat die das Global Commoning System im Sinn hat, dann kann vielleicht eine Erweiterung zu Valueflows beschrieben werden und der Teil der bereits in Valueflows beschreiben wird, wird einfach uebernommen.

Das wuerde die Geschwindigkeit der Umsetzung in die Praxis beschleunigen, dennn mehrere Parteien arbeiten dann an dem riesenprojekt :slight_smile:

1 Like

Nur hier noch als Anhang: Ich habe mich geschlagen gegeben und bin dabei die bestehenden Texte noch konsequenter in die ValueFlow-Ontologie zu überführen. Tätigkeitsmuster werden Rezepte, Mittel werden Ressourcen und Tätigkeiten (aber da muss ich nochmal wirklich nachdenken) werden Prozesse. Damit klingt manches wohl technischer/abstrakter als zuvor, aber die Zielgruppe sind ja voranging Personen, die ein Interesse haben, sich an einer Umsetzung zu beteiligen. Ich glaube, durch die damit entstehenden Interaktionsmöglichkeiten, lohnt sich das auf jeden Fall.

Danke nochmal für deinen Input, @serapath