Benefits distribution algorithm
Published on April 29, 2011, edited by Tibi, Kurt, Ishan, Ian, Francois, and Steve. See original doc, last modified on Oct 14, 2012 before content was moved here. If you contribute to this doc make sure you respect Content rules.
Work on the benefit redistribution algorithm (previously called Value Equation) is hosted on github, with the rest of the NRP-CAS. We are using REA (for Resources, Events and Agents) designed by Bill McCarthy of Michigan State University (See more on Bill McCarthy’s website). See a prototype HERE.
- 1 Definition
- 2 Types of benefit redistribution algorithms
- 3 Epistemological considerations
- 4 Background
- 5 Schools of thought
- 5.1 The long tail benefit redistribution algorithm
- 5.1.1 Formal aspects
- 188.8.131.52 List of important parameters to consider
- 5.1.1 Formal aspects
- 5.2 Small cluster benefit redistribution algorithm
- 5.1 The long tail benefit redistribution algorithm
- 6 Remix and fork
- 7 Different functions of the benefit redistribution algorithm
- 8 Log of ideas
- 9 Implementation in SENSORICA's NRP-CAS
- 10 benefit redistribution algorithm prototyping
- 11 External links
A form of Access to benefits equation.
The benefit redistribution algorithm is part of the Contribution Accounting System, or CAS, which has 3 main components
- contributions log - recording contributions to economic processes.
- evaluation of contributions - turn any type of contribution into a single unit (that could also be project specific)
- benefit redistribution algorithm - describes how benefits are distributed to all the participants.
The benefit redistribution algorithm prescribes how benefits (including revenue, access to governance, etc.) are distributed to all participants (active affiliates) in a collaborative process. In the case of revenue, it is used to compute a % of total revenue (fluid equity) for every participant/contributor, taking into consideration different forms of contributions and different modulators, and perhaps taking into consideration different cultures of constituent communities formed by participants.
The benefit redistribution algorithm describes how different types of contributions are amalgamated into a single dimension. The output can be a fluid equity piechart, a revenue redistribution piechart, a list of participants that have gained rights to make decisions, etc. It is a dimension reduction operator, taking all the complexity of contributions and customs of participants to project them onto the [0,1] real number domain.
The benefit redistribution algorithm can also be seen as a dimensional weighted sum of indices/parameters that are believed to increase the probability of creation of something perceived as valuable. If we think in the context of revenue redistribution, it is not about the post facto priced exchange value of whatever is produced. It is more than the individual subjective evaluation. Exchange is a special event that triggers distribution of whatever exchange value is offered (which is either an abstract value like money or something of subjective value to the recipient such as reputation).
See also The governance equation.
Why do we need a contribution accounting system?
Types of benefit redistribution algorithms
Peer production experience within SENSORICA has lead to at least 2 major types of benefit redistribution algorithms. If we reduce the problem to revenue distribution, we have:
- Past looking applies to economic processes (ventures) that originate within the OVN, for which the deliverable is not clearly defined, that consume resources to create exchange value (market value) to be later exchanged on the market (as a product or service) for revenue. The % of total revenue for every contributor is calculated based on past contributions. The revenue is unknown at the beginning or during the process. Past looking contribution accounting schemes can be fluid equity-based or debt-based. See the page: Examples of Past looking value equation.
- Forward looking applies best to economic processes (ventures) for which the revenue is already known beforehand or at least approximated, for which the deliverable is known or at least predictable, have a budget and a planning for their execution. One example is a service requested by another entity. Another example is a donation or a grant to realize something. In this case, the % of total revenue for every contributor is calculated based on a projection of contributions, evaluated against a plan. Examples of Forward looking value equation.
The benefit redistribution algorithm doesn't represent a law of nature that links efforts, commitment, contributions to benefits. It is not like Newton's equations in Physics. It does NOT describe a physical phenomena. Most importantly, it does not quantify or objectify value. It is a social contract with a purpose: increase the probability of creation or production. It sets the rules of a repetitive economic game played by agents in the context of a project. It is designed to sustain economic activity. Since it embodies incentives to participation, it affects human behavior and social dynamics. The empirical validation of such algorithm that links efforts to benefits is a measure of its effects in terms of innovation, creation, production, well-being of affiliates, good management of resources, etc.
The previous term "value equation" was criticized, because it suggests that it is based on a metric that tries to quantify value or render it objective. This lead to the use of the new term benefit redistribution algorithm. Tibi likes to say that the benefit redistribution algorithm is in fact a formal method of redistribution that renders redistribution process explicit. One role of the benefit redistribution algorithm is to create a sense of fairness by applying it systematically to all the agents. Another role is to increase the probability of en economic process to take place, to incentivize some types of behavior and disincentivize others.
An open enterprise can be forked and remixed. Since the benefit redistribution algorithm applies at the open enterprise level, and since it represents the social contract between all the participants, remix and fork events requires negotiation. See below.
The concept of benefit redistribution algorithm (previously called value equation) for OVNs was refined within the SENSORICA community/network between 2011 and 2015. Others might have thought about a similar concept in different contexts. Here we only provide an overview of what we know happened in the context of development of the OVN model.
The precursor of the OVN model is the "Discovery Network" model proposed in September 2010. The main idea was to design a collaborative venture in which revenue would be distributed to participants based on their contributions and merit. The concept of benefit redistribution algorithm, or value equation as it was called, was not formed yet, as the allocation of equity in the venture was governed by a set of rules through a mechanism of negotiation.
The OVN model was first described in the Value System document, created in April 2011. The expression valuation mechanism was used to name the section that mentioned a mathematical formula for calculating fluid equity. Kurt, who contributed substantially to the concept, was independently thinking about a mathematical equation to capture a % from transactions made by contributors on the *net (from powernet) platform, since early 2000. The initial discussions within the context of SENSORICA about this concept were carried out by Tibi, Steve, Kurt, Bayle and Ian.
The expression "value accounting system" was introduced in the Value System document on March 02, 2012. On March 13, 2012 the expression "value equation" appears in this same document for the first time, in conjunction with a comment made by Kurt on SENSORICA's main mailing list. The earliest occurrence of the expression "value equation" in SENSORICA's mailing list is in early September 2011, used by Kurt again. Instead of value accounting Sensorica uses now contribution accounting
Schools of thought
Two different schools of thought have emerged from SENSORICA experience, leading to two different approaches to the benefit redistribution algorithm. One of them is focused on long tail innovation and production processes and considers projects as swarms. Let's call it for now long tail benefit redistribution algorithm. Tibi is a big advocate of this model. The other one is more focused on small clusters of individuals networked into a larger OVN. Let's call it for now small cluster benefit redistribution algorithm.
The long tail benefit redistribution algorithm
Designed for large scale collaboration, swarm-like projects. Applicable in high-tech open ventures or in knowledge intensive areas that require a lot of innovation, where innovation is very dynamic.
List of important parameters to consider
The benefit redistribution algorithm embodies tangible incentives. Its structure is designed to enhance economic activity, to incentivize certain type of behavior.
Under development... This need came out of SENSORICA's experience with the PV project and the Sensor Network project. We need to move past deliverable-only reward, to rewards that treat directly the performance of a group engaging in co-creation.
Incentivizing overall effort
Effort (E) is a quantity, a measure of total efforts. For now we split efforts in 2 dimensions:
- time-based contributions (applying one's skills to solve a problem, to produce something, etc.),
- financial contributions (using cash to purchase something needed for the project).
Incentivising early involvement
Earliness (Ea) is related to risk taking. This parameter encourages contributors to invest in projects in their early stages. Contributions made earlier are more risky and should be rewarded more than later ones.
- From Kurt: plain time (measured as time with presence if presence is available) is functionally attention, time with a tangible output is participation, then time with a tangible output considered valuable by the community (ie used by the community) is contribution, and contributions may become or lead to a deliverable (something that attracts revenue, i.e. you get revenue for deliverables).
Attention is described by temporal aspects of contributions (of all sorts, time-based or others). Dimensions of attention are frequency (F) and periodicity (P). Periodicity is also related to the predictability of someone's involvement, i.e. other affiliates can rely on someone and plan ahead. There is value in knowing that someone will be there every Monday on a regular basis.
Allocation of talent and skills
There are different ideas to deal with this problem.
The first one proposed early on in SENSORICA
In order to attract the proper skills to a project we need a parameter into the benefit redistribution algorithm that differentiates between types of work. If a needed skill becomes rare, the group can increase the weight (resulting in a higher % of fluid equity) for certain roles. We'll call this parameter role (Ro). See more on the Role system. The classical job market can serve as reference for ratios between roles. Egalitarian groups might prefer to keep roles weighted the same.
Bob says: The value accounting [contribution accounting] software provides work resource types which people select when they log time contributions. Each of those work resource types is intended to represent different skills or work requirements. And each of them has a rate, which is intended to be used for value equations [benefit redistribution algorithm]. Those work resource types can also be used for planning and stigmergic signals to network members, as well as explicit email notifications to people who have logged those types of work before. (See also discussion page).
A second idea advocated by Yasir.
The contribution accounting system records contributions. Time-based contributions can be seen as accomplished tasks. Instead of defining roles, which are complex of activities required to accomplish tasks, the system simply assigns a quantity (a number of tokens) to tasks. Since tasks and roles are related, evaluating tasks comes down to assigning relative weights to roles.
Optimization of economic processes
- Importance or priority
- Execution quality
Table of parameters
|Name||Symbol||Description||Type of incentive||Data source|
|effort||E||dimensions of time spent on a project (see problem)||time, money and material resources spent on projects||contribution accounting system|
|role||Ro(t)||Type of work done, also related to level of complexity. The role parameter can be modified over time if the benefit redistribution algorithm is modified, that is if a skillset becomes scarce or more abundant.||attract/keep/reward talent a)||Role system|
|importance (or priority)||I(t)||Importance of contribution or its priority, peer-evaluated. Is a function of time,as some things can be more important at some times.||sensitize active members to what’s deemed important||Project management system|
|quality (or execution)||Q||quality, set by peer evaluation (see also discussion page)||incentivize care, quality of execution||project management system, or Bayle’s reputation system|
|accountability||Ac||respecting temporal and other type of constraints, commitments are made by members to projects/tasks listed, with deadlines, budget limitations and other type of constraints||incentivize active members to keep their promises b), to make processes deterministic||project management system|
|periodicity||P||representing predictability of contributions||reward predictable behaviour, which makes it easier to predict the evolution of projects||contribution accounting system|
|reputation||Rep(t)||Set by peer-evaluation and having many dimensions, qualities of active members. It is a function of time, as the reputation of a member changes over time.||maintain ethical behavior, the respect of the internal culture||Reputation system|
|risk||Ri(t)||is related to the project, its technical complexity, how difficult it is to reach maturity - produced by a peer-evaluation process, dimensions: time and... This parameter is a function of time, it changes over time as the project gets closer to maturity.||reward risk takers more than riders, maintain usable resources instead of cashing everything in||project management system See discussion|
|frequency||F||a measure of frequency of contributions||incite active members to contribute more often||contribution accounting system|
|earliness||Ea(t)||related to loyalty, total amount of time of involvement in the OVN. It is a contineous function of time, as early contributions are rewarded more than later ones.||reward loyalty, this is not an indication of value or quality||contribution accounting system See discussion|
|damage||D||a form of penalty||recover losses that are deemed avoidable, due to negligence, incite to diligence||damage log|
a) Role is NOT related to a diploma or other symbols of status. Role is an emergent property of active members related to past activities successfully carried out.
b) No one is obliged to do anything within an open value network BUT if a member takes on a task he/she must deliver within the set boundaries, because others might depend on it. Interdependence makes reliability an important factor.
Small cluster benefit redistribution algorithm
Ask Ivan (from SENSORICA) to provide info and insert here...
Remix and fork
An open enterprise can be forked and remixed. Since the benefit redistribution algorithm applies at the open enterprise level, and since it represents the social contract between all the participants, remix and fork events requires negotiation.
The remix happens when two ventures merge (entirely), or when a venture incorporates elements of another venture (partially). In the first case, A and B produce products a and b respectively. A new venture is created C to market both products, a and b. In this case, two value streams with different benefit redistribution algorithm merge into one, which requires its own benefit redistribution algorithm. The contributors also need to relatively evaluate a and b as contributions, regardless of the benefit redistribution algorithm used. Another example is Project D produces dx and project E produces product e. Project E incorporates x from D to create a single product, ex. In this case, the benefit redistribution algorithm of E can remain unchanged, but the contributors to E need to evaluate x as a contribution to ex. If no value is found in maintaining a relation with D the evaluation can also be zero, if the decision is not influenced by contributors that play a role in both projects E and D at the same time.
Problems with remix and fork
See debate between Yasir, Tibi, Kurt and Bob, email named Value Equation - I entered your name on the wiki. Someone needs to currate that and insert here!!!
Different functions of the benefit redistribution algorithm
[NOTE: the following text is taken directly from an email exchange between Kurt, Tibi, Yasir and Bob named Value Equation - I entered your name on the wiki. These are in particular extracted from Kurt's reply. Someone needs to refine this...]
a.) The benefit redistribution algorithm is required to obtain funding (IS)
<kdl> the VE will need to explicitly deal with how investment in the form of dollars is treated, a discussion on this issue sooner rather than later is needed. My personal approach, funding should be directed to individuals or assets and the individual or asset should be compensated by the value equation [benefit redistribution algorithm], fiat currency has no intrinsic value in an OVN. Money is what money does. Money ONLY has 'value in use'. </kdl>
b.) The VE is required to attract resources and participants (IS, SHOULD)
<kdl> I agree with Lynn that my first reaction to the VE being used as the minimum reward required to coerce participation is exploitative at its core and disingenuous. My personal basis is that all people are valuable, and that differential effort and results should be incentivized while keeping inequality of reward in check. Ultimately though the value equation [benefit redistribution algorithm] needs to be 'values neutral' - in other words, you should be able to model everything from dictatorship to democracy and from oligarchy to cooperative. I am searching for the foundational dimensions of Value and their relationship to one another, while leaving relative emphasis of dimensions to the user. People's motives for using the VE are immaterial to its design. </kdl>
c.) The VE is required to explicitly state shared valuation methods
<kdl> this is the crux of the matter for me, shared understanding of what is valuable and what is valued in a given context established in advance as a sort of "smart social contract" algorithm </kdl>
d.) The VE is required to remove uncertainty around ROI as an obstacle to participation - provides predictable rewards
<kdl> I see this as a secondary effect, but an important design principle, to me the VE must be posted on the wall and defined IN ADVANCE. It can and should be iterated forward as it proves acceptable or unacceptable to participants. Governance comes in here, as well as anti-governance (the right to fork) </kdl>
Log of ideas
To be integrated within the text...
Infrastructure development and maintenance and the benefit redistribution algorithm
The act of logging contributions and the contribution accounting
Should we add a somewhat arbitrary value from SENSORICA to all products? We discussed with Tibi about taking a small percentage from all revenues to cover the overhead expenses of sensorica.
In essence, SENSORICA adds actual value to everything just by providing the means to connect and exchange information. Shouldn't that be added to the benefit redistribution algorithm?
Tibi - this has resulted in the 5% rule (all commercial activity transfers 5% of revenues to a network Custodian)
The system gets paid for what value it creates.
The system actually does add value on a number of dimensions - it supports *capture (recording of value) which is done with a human partner (perhaps the person who did the work, perhaps someone else who is taking a percentage for doing it for someone else who might not otherwise record their own contributions. System features (such as alerts) may serve to increase *attention and should take a percentage of *attention value as a result. The system will support *identity as a foundation for everything else. As the system matures it may support *surfacing (recontextualizing information) *connection (making it more likely that two parties will interact or form relationships, introduction services, the people analog of *surfacing).
For now a percentage may be the simplest approach, but I would like to see the system being rewarded for the capabilities it provides, providing a natural funding model for expanding those capabilities by allowing developers to project the value that a new capability might support and understand the 'return on investment' implied. A straight percentage does not have this level of granularity for incenting the highest value development. Also as systems do things that people used to (curate, surface, connect) this value should transfer to the creators of such systems, who have afforded increased efficiency in the system.
See mindmaster for further candidates to accrue to the system, expand the tree for a full appreciation of dimVals.
Documentation and making it available [entered by Tibi, supported? by Bob?]
Documentation (of all sorts) is very important for an OVN to insure a good coordination, continuity of processes, and even to stimulate network growth. It is also important that the information documented is made readily accessible to all affiliates. Accessibility meas easy to find, to understand, to relate with other pieces of information, etc.
The experience with SENSORICA tells us that a lot of people are not diligent enough to document and to make that documentation available. We recommend that this issue should be linked to the benefit redistribution algorithm as positive and negative incentive. In other words, documentation work should be considered as a contribution to the contribution accounting system. This is the positive incentive. Moreover, a contribution that is not well documented should be penalized if it is not accompanied by the proper documentation and if this documentation is not rendered readily available. For example, if someone logs a design or a prototype without proper documentation a % should be subtracted from the value estimated for this contribution. This is the negative incentive. We also recommend that this negative % should be erased if the affiliate remedies the problem. Furthermore, the same affiliate is also allowed to log the work done for documentation.
Logging contributions [entered by Tibi, proposed by Kurt and supported by Bob]
Logging contributions is crucial for redistribution of revenue, but the data logged is also used to streamline almost all processes within an OVN. The aggregated logged data gives information about how projects advance, how resources are used, how value is flowing through the network, etc. which can be used for coordination, analysis and planning. The entire community can benefit from the data logged, therefore we should incentivize logging.
OVN points This idea has been brought up many times in discussions. How should contributions be evaluated? Points makes easy to solve a big problem, which is to reconcile contributions through deliverable and continuous contributions like office work for example. The first one can be evaluated in one step within the context of a project or open enterprise. The second is better suited for a time-based estimation, taking into consideration the nature of the task. OVN points can deal with both. Points can be allocated for deliverables as well as for continuous contributions like office work for example. Points can also solve the problem of remixing, when one project, or a part of it is included into another project, and a negotiation process is used to estimate the value of the part newly integrated.