Cascading Revenue Sharing Protocol (CRSP)

[ktorn]

I have been thinking about a way to reward contributions to open source software/hardware.

The idea is that anyone making a profit from any activity that somehow relies on an open source stack would be able to attribute a small percentage of the profit towards the stack developers. That small percentage is herein called 'revenue'.

Since a stack is potentially made of many independent projects, with many contributors who have contributed in different ways, the challenge is to come up with a system that fairly shares the revenue amongst all the stakeholders. Library dependency would have to be accounted for, and the actual usage of each project should be factored in, so that if a particular library is only marginally used by the stack, then it would be attributed a relatively small share of the overall revenue.

This division of revenue should go all the way down to individual contributors, whose contributions should be calculated in some way, either automatically, or agreed in advance by the maintainer(s) of each project.

As a concrete example of how this might work, from the perspective of a software developer, you create a patch and submit it to a project, including in the comment a reference to your cryptocurrency address. The project maintainer accepts the patch, which automatically grants you a (small) fraction of the overall project's revenue-share agreement. As that project is adopted, directly or indirectly, by profit-making products and/or services (and assuming a regular donation is made towards the stack), a series of micro-transactions start trickling down your wallet. For example, for every shopping cart sale in a website, you would receive a (very small) amount, simply because you contributed to one of the projects within the stack used by that website.

I think this idea is related to ABIS because it would require low-level protocols built into monetary transaction software so that relative revenue-share can be calculated on-the-fly. You could think how it can be expanded from software/hardware into other scenarios where people contribute time and other forms of useful work. It's all about automatically rewarding effort.

[ABISprotocol]

@ktorn Thanks for these excellent thoughts. That is certainly related. Question - related to what you have mentioned, is there a way for these software patches to occur that would not result in a revenue share being given to me if I were a code / patch contributor? Or if someone wanted to obtain a small donation as a result of their code work, they could receive that through this patch system, but is there a way to time limit that or phase it out such that contributions to project(s) would be distributed throughout the system and enable any participant (after a certain amount of time has passed and funds have grown) to claim an equal share? Actually, that's more than one question.... I am excited to see what will come of this. The idea of rewarding people for effort that actually leads to benefits for all of society resulting from project-related work and microdonations fine-tuned at the transaction level is very interesting to me. Cheers!

[ktorn]

@ABISprotocol I thought long and hard about how to keep the share-attribution as objective as possible, but it's not a trivial problem. Even in the case of software it's a hard problem. LOC is not a solution, since an inexperienced developer will normally write more LOC of a lower quality than more experienced devs. I thought about run-time analysis so that code that runs more often gets a higher reward, but that would would create more problems than solutions. So far I don't see a purely technological solution to that problem, therefore it probably has to involve social and subjective components, such as code reviews and manual attribution of "relative value" of such contributions. This would also include contributions that are not code-related, such as documentation, graphics/UI work, support provided on forums/IRC, etc. The net result is that everyone involved in the project should become 'shareholders' with their relative shares being somehow proportional to their involvement/work in that project.

So, to answer your question, given that a human element is involved in attributing merit for the contribution, it's obviously possible for a patch to be accepted without giving any reward in return. It's something to be agreed/discussed between the contributor and the project's maintainers.

Regarding diminishing shares over time, I don't think it should be the case unless the particular work originally performed is no longer contributing to the overall project's value. For example, that might happen if a particular patch was later re-written and/or replaced, or a documentation superseded. However if your code is still playing an active part and is running well, it should not matter if you wrote it yesterday or 10 years ago. Think of it as royalties that you can even pass on to your descendants (unlikely as it may be in the case of fast changing software). Again, it's down to the community of the project to discuss and decide upon.

However it's funny you should mention diminishing value over time. I had a fairly crazy cryptocurrency idea that involved the concept of ageing coins ;)

[ABISprotocol]

@ktorn -- Would you like to be a collaborator on this project? thank you for your insights, btw.

[ktorn]

@ABISprotocol Sure! Happy to contribute.

[ABISprotocol]

@ktorn Done - thank you, looking forward to this

[ktorn]

:+1:

[ktorn]

See https://whispersystems.org/blog/bithub/ for a related idea already in action.

[ABISprotocol]

Excellent news. I will need to touch base with @moxie0 soon.

Ref.: https://github.com/WhisperSystems/BitHub see also: https://whispersystems.org/blog/bithub/#comment-1170276241

[ABISprotocol]

This open issue is now also mentioned in Gist at https://gist.github.com/ABISprotocol/8515891

[ktorn]

Also see: http://tip4commit.com/

[ktorn]

A bit older, but great read: http://www.donationcoder.com/Articles/One/index.html

[ABISprotocol]

I would like to add @drwasho and @genjix as collaborators on this repository also. cc: @ktorn Please let me know your thoughts of all else who might be good to add.

[ktorn]

It's been a year and I'm going to pick this issue up again. I'm preparing a spec which I'll put up on it's own repo.

I'm also renaming it: Value Chain Distribution Protocol (VCDP)

[ABISprotocol]

@ktorn As the newly renamed VCDP / VDP proceeds which emanated from this issue, it would be excellent if you could please open a new issue (in this ABISprotocol / ABIS repository) re. how it be implemented into or tie into the "microdonation" or wallet feature. For example, how the subsatoshi payment "processor" could be embedded in an existing wallet and how this relates to both the VDP and the "microdonation" concept of intended by ABIS. Opening this as a new issue in this repository would be good. Thanks in advance.

[ABISprotocol]

@ktorn I should have been a bit more specific above ~ I was obliquely referring to the bitwisebank repository Multibit ABIS fork. Could you open a new issue within this ABIS repository that would describe the VDP and subsatoshi payment processor but would also open discussion on the microdonation feature of ABIS, which is distinct from VDP and subsatoshi, and include a reference to that Multibit ABIS fork? In so doing please reference this issue so that the discussions are linked. Thanks.