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
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--
The "lines of code" method sucks because it will lead to bloat. It also discourages optimizations.
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 tricky. If comeone changes one word and fixes a bug that's been bothering all users, is that worth more or less than a fully-implemented feature that few people use? "Shares" is a great way to assign value to code -- you're really distributing ownership rights. You need to think about this up front, because you need to include ownership rights in the process of deciding what goes in and what stays out, or someone who contributes a bunch of code will be upset when their pet feature is left out, and they may fork the project. Of course, if the originator keeps controlling interest and pisses everyone else off, it may fork anyway, which leads to
Community. You're really building a community here, with it's own rules. What sort of community do you want, and what sort of people do you want in it? Do you know that sort of person already? If not, how do you find them? I suggest you start a private mailing list discussion among the existing developers, and get their ideas.
Oh, and I lost my train of thought earlier, but once you have a system for deciding what code is in and what is out, you can use that system to decide how to distribute (spend) any income. As mentioned by others, you should re-invest and grow the business before you start distributing dividends to the shareholders. Take some small-business management classes.
If all this should have a reason, we would be the last to know.
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-