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."

Translation

[Anonymous Coward]

Step 1: Start successful open source project.
Step 2: ???
Step 3: Distribute profit!!

Voting

[Muhammar]

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.

Re:Voting

[grammar nazi]

I agree with this method. Devise some fair plan and stick too it. If somebody doesn't agree with the way funds are distributed, then they can start there own project and not contribute to this one.

It Depends

[miyako]

I think it depends alot on the size of the project. If you are talking 5 or 6 people on a project, then it is pretty easy to decide who should get what, and/or divide it up equally. On the other hand, if you have a project with >20 or so people, contributing various amounts of code, documentation, etc, then it becomes a bit more difficult.
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

[jakobk]

The "lines of code" method sucks because it will lead to bloat. It also discourages optimizations.

Re:It Depends

[dubl-u]

Amen! If I rewrite a section of code to make it shorter and clearer, I'd have to pay money.

Re:It Depends

[isn't my name]

For code, give extra weight to easy to maintain code. i.e. good internal documentation, coded in such a way that making changes are very easy

Re:It Depends

[dubl-u]

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.

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

[sanctimonius hypocrt]

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 :)

my advice

[hswerdfe]

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)

Monies from open source projects...

[HaloZero]

...should be re-invested into the project, or, used to start new projects with the same team. With a few people, and a good amount of money, it would be possible to allow for upgrades to development machines, and maybe celebrate and take the team out to lunch. Any left over money could/should be placed into a bank account for future team use. E.G. development supplies such as replacing suddenly blown machines, buying books, the occasional 'Hey! Let's get a pizza.'. However, for developers who may be in trou

We need more information

[infernalC]

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.

Contracts

[cperciva]

How much is a piece of code worth? How much is the design behind that piece of code worth? What if I don't like your design?

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

[Rick the Red]

You'd best set up a framework for this before you begin, or at least before you include anyone else's code in your project.

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

[ikeleib]

You make a charitable foundation that "owns" the software by either copyright or just trademark. Developers submit grants to be funded. This can include grants to develop new features. This can also be grants to aquire new equipment to work on the project. The charitable foundation's money allows them to hire programmers to make certain features happen, even if no volunteer can/wants to code it.

Re:charitable foundation - grants

[hswerdfe]

Mod parent up...up...and away...
he be usin his noodle

*Anything* automated is gamable.

[aminorex]

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;)

Maybe think in a different way

[91degrees]

rather than paying for the work that they have already done, what happens if you pay them for work that you may expect from them in the future?

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)