Revenue Sharing

If content is created 'at the edges' by multiple authors, and if the participatory platforms are living of the content created by all, it makes sense to develop revenue sharing shemes that benefit the individuals, communities and corporate organizers of the platform.

Discussion

Is it fair to profit from Peer Production?

The following is a reaction, which appeared on the Oekonux mailing list, to my query of whether the buyout of core open source leaders could not be seen as an unfair profiting, and if the creation of cooperative ventures would not be a solution. According to Mako, it is in fact not a problem at all.

My question was: "Well, imagine the following two situations, I hope that makes thedistinction clear. So there is a given open source project, with a core of lead programmers and a multitude of small contributors. Some venture capitalist is interested. Two options are open:

- some of the leading individuals "sell" their leadership and expertise of the project, and become rich in the process

- a cooperative is created so that all contributors may more fairly share in the possible proceeds"

Reply: "What do you mean by "sell"? People are usually paid to either work on another project that is based off of the original project (i.e., a fork) or to continue doing what they doing but to do it more frequently.It's perhaps also worth noting that becoming rich is hardly the rule. Part of the problem is that the voluntary nature of the work makes the contributions incredibly difficult to quantify. Things are just too ad-hoc and quantification schemes (e.g., lines of code) don't work andqualification schemes don't scale. Let's take Debian for example. Few developers seem happy with the idea of breaking up the spoils down the middle when some people are doing orders of magnitude more than others. Of course, quantifying and ranking that work is also incredibly problematic. We can also add to this the complication that many people who are contributing are already doing so as part of paid labor that is tangentially related. Things get messy fast and I've never seen a free software project introduce paid labor successfully. As far as I'm concerned, large projects are better off not paying *anyone* and by letting outside organizations and individuals handle this.

I've documented a bit of this in an essay I wrote on financing voluntary free software projects: http://mako.cc/writing/funding_volunteers/funding_volunteers.html

The problem is to find ways to avoid that a few benefit from the work of the many. I think one issue is that situations are not always read this way by the participants. When another Debian developer gets a job based on his work on Debian, I feel happy -- not like I'm getting ripped off. When I cut code, I don't do it with the idea that I'll get stock options out of it in the future. If that were my interests, there would be other ways for me to spend my time." (http://mako.cc/writing/funding_volunteers/funding_volunteers.html)

More Information

Such schemes are monitored by Pete Cashmore at http://mashable.com/category/revenue-sharing/

Examples of some 'peer reward' schemes implemented by legal musical filesharing systems:

Peer Cash, http://www.peerimpact.com/peercash.html

Peer Reward, http://www.gridnetworks.com/?section=solutions-ol-rewards