Revision as of 08:01, 5 March 2007

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)

Examples

Video-sharing services

Revver

URL = http://www.revver.com/

Citation from Revver video-sharing network:

“We believe in your talent and your right to share it with the world on your terms. We connect makers, sharers and sponsors of internet video in a free and open marketplace that rewards them for doing what they do best. Revver is a completely free service. We want everyone to post his or her video. We make our money by partnering with video makers and sharing in the advertising revenue.” (http://www.revver.com/)

How it works: members upload their video to Revver, who then attach a brief ad to the video, as well as tracking software. Every time an ad gets clicked, Revver shares the ad revenue on a 50/50 basis. The video's performance can be tracked through a Revver account - showing how many times a video is watched, and how much money has been earned. Since ads are attached to the video itself, there's no restriction on how videos are distributed.

Break.com

URL = http://www.break.com/

"the company announced that it is nearly doubling the amount of money paid for original user-generated content. Prices are up to USD 400 for regular videos and up to USD 2,000 for short film productions, animated films and games. Users can upload as many original videos as they want. If the material is published on Break.com's homepage, they can rake in the cash." (http://trendwatching.com/trends/gen-cash.htm)

Metacafe

URL = http://www.metacafe.com/producer_rewards

"5 USD for every thousand views their video gets on Metacafe. Payment starts when a video reaches 20,000 views and has a rating of 3.00 or higher. Licensing is non-exclusive: makers retain ownership of their video." (http://trendwatching.com/trends/gen-cash.htm)

More Examples

The article in Trendwatching on Generation Cash] gives a list of examples in Citizen Journalism

Innertee, at http://innertee.com/

The Bumper sticker cooperative at http://www.bumperactive.com/custom_bumper_stickers.jsp. See its explanation

Commentary on the two examples above here at http://www.weblogsky.com/archives/001066.html

More Information

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

Trendwatching has an overview (December 2006) at http://trendwatching.com/trends/gen-cash.htm

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

Revenue Sharing: Difference between revisions