Contribution treatments

Here are some design notes copied from an email, with some additions and corrections:

In general, a contribution is an Economic Event. When Sensorica gets a contribution, a reciprocal claim occurs for something in return, which we would model as a Commitment. Could be a commitment to pay back over time with interest, could be a commitment to share income forever according to a value equation, could be just reputation points, etc. We could model those as Commitment Types. Those all would live in Exchanges.

We have now a variable on an input economic event that says whether it is a contribution or not. I did that because Sensorica was not ready to think about agents and exchanges. Tagging the contribution is sort-of a cheat. The right way to do it is to specify how the reciprocal compensation will work. One field is too weak a hook for logic.

I am also thinking that for projects, some of this stuff is related to their value equations: as in, do contributions earn equity of some form, or are they like loans? And we are thinking of carving value equation into a separate app, so each network can plug in a different value equation app if necessary. Then you could have more degrees of freedom in designing this stuff than if we are trying to figure out what generally applies to all the networks currently using the software. Not many, I know, but Bosserman's stuff will work very differently from Sensorica.

So the rules for projects would not be a field on the project itself, but related to their value equation, which will live in their Value Equation app. Also in that app will be a relationship between a value equation and a project. Details of the value equation app are yet to be designed, and might want to be a separate design conversation. But we could start with these rules for contribution treatments.

Some links to help this discussion.

Value Equation
http://valuenetwork.referata.com/wiki/The_Value_Equation

Contributions - page on wiki
http://valuenetwork.referata.com/wiki/Contributions

Concrete example of value accounting, the FabMobile project
http://www.sensorica.co/home/what-we-do/working-space/labonline-network/mobile-fab-lab/mobile-lab-vas

I tend to be not so keen on the 'income distributions forever' model as I see it as one of the fundamental injustices of our financial system which transition from being a fair exchange of value early in the investment lifecycle and an unjustified theft from society in the latter part.

So pretty much all the value exchanges I structure are capped and eventually transition to a model where stewards govern any ongoing revenue stream for the benefit of the wider commons.

This is very similar to how we've been thinking about this in Enspiral with 'equity-like' contributions and 'debt-like' contributions.

'Debt-like' contributions seem to make the lawyers more nervous.

This may be specific to social enterprises but
@joshuavial and I have advocated combining the two in that ongoing income is capped at, say, 5x the 'raw' value of the contribution. This way the organisation transitions to being financial obligation-free but under the control of its contributors.

BetterMeans lawyers got a lot more nervous about the equity-like contributions. As did the venture capitalists that they sought for financing.

@lynnfoster and I did our morning walk-and-talk about this set of topics and others related to this part of @tiberiusbrastavice 's Contributions wiki page:
http://valuenetwork.referata.com/wiki/Contributions#Contributions_with_respect_to_project_cycle

We think these are policy decisions, and people who are logging contributions should not need to make those decisions on the fly. So one of our design goals would be to specify these differences either at a Type or at least Plan level.

We'll work out the details and make a starting proposal (or at least vague handwavy idea) after Tibi walks us through this spreadsheet:
https://docs.google.com/spreadsheets/d/1SBJxdEtJ-m_g74ctcy_KYxxVNDeYI_U_blbBvfTYdok/edit?usp=sharing

We expect that walkthru will happen later today.

I hope the discussion was helpful to understand how we're setting up things for the 3D Course project. We'll continue to clarify things here.

The discussion was very helpful, thanks.

I'll try to summarize.
I think contributions can be turned into equity or debt, or paid right a way.
* Equity can be used for resource intensive and high risk projects, for example those that require R&D. Initial (startup contributions) are turned into equity and paid at every exchange cycle (every time product is sold). This can be done in many ways, for example a % is subtracted from sales to be distributed to everyone who has equity.
* Rolling contributions (those involved in maintaining exchange cycles, like manufacturing and sales) don't give equity. Manufacturing and sales are paid / piece, immediately after the exchange. There are also contributions as Support role, which are not specific to one exchange, but sustain the exchange cycle. Examples are outreach/marketing and service. I suppose that these cannot be paid / piece, but need to be paid somehow from revenue. Can they be turned into equity? Some will like this idea, others will probably not like it.
* Debt can be used for
** projects that can be set up more easily and rapidly. Initial (startup contributions) are turned into debt (market value + % for risk) and paid back little by little at every exchange cycle until balance goes to 0.

** infrastructure maintenance and development, i.e. contributions for the community, not for projects, like cleaning the lab, paying the rent for the lab, buying materials for general use in the lab, etc.

Considering contributions to infrastructure maintenance and development as debt is starting to be accepted in SENSORICA, or at least no one is opposing this idea for the moment.

Here's another angle on contribution treatments: how does the exchange for work contributions between the contributor and the network happen? What is the network "paying" for? Time or deliverables? And when do they "pay" for time?

We would like the NRP software to be able to handle all of these cases.

• Case 1: typical employment contract, but could also be used by a value network (I suspect that is how Wikispeed works, but do not know for sure): The exchange between the contributor and the network takes place "at the door": in other words, from when the contributors start work until the time they stop, regardless of what they are doing, their time is a contribution to the network. So all work going into deliverables has already been covered by that exchange: the network has already promised to compensate it according to the terms we have been discussing (debt-like, equity-like, immediate payment, or whatever). The time contribution does not say what the contributor was doing, it could be anything.

(Afterthought: this is sorta how Sensorica's non-production time logs work, although Sensoricans are expected to break their time up into separate timespans by the kind of work they were doing (although not by what they were creating)).

• Case 2: Sensorica now. Contributors log their time into a process or project. The contribution event says what type of work they were doing, and for what process or project.

• Case 3: "pay" for deliverables. The contributors to a process "own" their contributions until the outputs are delivered to the network. The network "pays" for the deliverable according to the terms we have been discussing, and the contributors to the process share the income either equally or according to whatever split they agree on. In this case, the contributors would not need to log time at all.

This is how I imagine a software development value network would work. Your contributions would be github commits or pulls or maybe closed issues. Nobody cares how long it took you. The network would need to figure out some way to value those contributions. Maybe issues could be valued up front.

(P.S. do not get hung up on the words in quotes, e.g. "pay" and "own". They do not necessarily mean the conventional definition, I just could not think of substitutes that would get the idea across as clearly.)