Slashdot Mirror
Method for Distributing Earnings from an Open Source Project?
mindlace23 asks: "Assuming you had some mechanism by which an open source project generated revenue, how would you fairly distribute those earnings amongst the contributors to the software? Rules that most clearly avoid bias would be preferable; Some sort of automated heuristic would be ideal if it's not gameable."
Ask the person who is likely receive most of the money to make a proposal about his revard and distribution amongst others. Publish the proposal and take poll about it. Have an authoritative person of good reputation (not financialy involved) to make the final decision.
Anything else is heuristic balooney.
No matter what the algorythm, your input is allways going to be subjective.
I doubt that we will ever figure out - and I suspect that even if we did figure out we couldn't do much about it
Trying to fairly distribute the money is going to be more trouble than it's worth. Unless it's a lot of money; Then you should grab it and run :)
don't... distribute the money ....at least not in any way the resembles a pay check...
it will change the power relationship in what is obviously a successful OS project.
never make your volunteer an employee unless you actually have enough money to pay them.
you could do other things with the money.
1. of your best developers find the ones that are still working on a 500Mhz Shit box and buy them a new one.
2. sent a few of your developers to a confrence, (obviously in the field that project is in)
3. spend the money on bandwidth.
4. spend the money on promotions of your product. (see #2)
--meh--
Okay, so here is what we know:
1. Recruit developers
2. Develop OSS program(s)
3. Distribute software
4. ????
5. Profit!
6. ????
Before we answer 6, give us 4.
Given that the contributors all have direct
input into the metric algorithm, it's clearly
a game in the game-theoretical sense. Don't
try to avoid "gamability", work *with* it.
Make the cost-effective methods of gaming the
system represent actual contributions.
Here are some useful metrics:
Tokens of uncommented code.
Decision points.
Words of comment.
Bugs resolved.
Words of documentation.
Peer review metrics.
Tokens of code subsequently revised.
Bugs reopened.
Number of distinct patches.
Messages on a mailing list, in count, in word count.
Megabytes hosted.
Dollars spent.
I think estimating the cost of the contribution
is the way to go. Dollar values represent a
compression of social values from many otherwise
largely incommensurable dimensions of value into
a single number, so they will simplify any such
computation enormously. The more complex it is,
the more complaints it will generate, so
simplification seems very worthwhile.
Most of the cost of contribution will be time*rate.
So an easy way to estimate it is to generate
estimated time spent -- a quantity metric, and a
quality metric to determine the rate.
To the degree that these observations are non-
controversial they may seem obvious;)
-I like my women like I like my tea: green-