Method for Distributing Earnings from an Open Source Project? 21
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."
Translation (Score:2, Funny)
Step 2: ???
Step 3: Distribute profit!!
Voting (Score:5, Insightful)
Anything else is heuristic balooney.
No matter what the algorythm, your input is allways going to be subjective.
Re:Voting (Score:2)
It Depends (Score:2, Interesting)
I would say divide it up based on how much each person contributed, and give divide a percent of the earnings equally among the people in that group. for example if
Re:It Depends (Score:2, Insightful)
Re:It Depends (Score:1)
Re:It Depends (Score:1)
Re:It Depends (Score:1)
I used to work for financial traders, and company bonuses were based upon how much each person contributed to the total profit. If you went around and asked each person what percentage of profits they were responsible, the total would have been at least 200%, and probably more like 500%. So payment by effort is likely to make everybody feel like they got gypp
Give it away (Score:3, Funny)
my advice (Score:4, Insightful)
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)
Monies from open source projects... (Score:2, Redundant)
We need more information (Score:4, Funny)
1. Recruit developers
2. Develop OSS program(s)
3. Distribute software
4. ????
5. Profit!
6. ????
Before we answer 6, give us 4.
Contracts (Score:2)
The question here is of rating the relative value of different contributions; that can only be done by mutual agreement -- ie, negotiation. Obviously if the question is of distributing unknown future earnings, this means allocating shares.
Ultimately when someone offers a patch, you have to be prepared to say how many shares it is worth, and to refuse to accept the patch if its ori
Re:Contracts (Score:3, Insightful)
First of all, you need a well-documented, repeatable process for who decides what code is in and what code is out. I'm not trying to shove CMM down your throat, but if it's not documented and repeatable, it's not fair and nobody will want to play with you.
Then, you need to expand that process to put a value on each unit of code. You need to decide what a "unit" is. This is where it gets
charitable foundation - grants (Score:3, Interesting)
Re:charitable foundation - grants (Score:1, Redundant)
he be usin his noodle
*Anything* automated is gamable. (Score:4, Insightful)
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;)
Maybe think in a different way (Score:2, Interesting)
This is just a thought experiment rather than a serious proposal, but it does mean that you are effectively reinvesting in the project, and those who feel it is unfair have a means of retaliation (refusing to work on the sequel)