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

Comments

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 you have a project with 25 people contributing, 5 of whom did very little, 15 of whom contributed a moderate amount of work, 10 who contributed a signifigant amount, and 5 who were above and beyond, then you could say for example, 10% of the profit will be divided among the bottom 5, 25% will be divided among the lower middle 15, 15% will be divided among the upper middle 10, and the last 50% to be divided among the top 5. keep in mind these percentages are completely arbitrary.
alternately you could pay per line of code, so if there was x lines of code, and $y profit, and a person contributed n lines of code, they would get n(y/x) dollars.

Re:It Depends

[jakobk]

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

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]

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

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

And note that as soon as you introduce a mechanism for determining level of effort, you are creating incentives that may not match what you want. As one person pointed out, paying by line of code leads to bloat. Paying based on self-evaluation rewards the arrogant. Paying based on some sort of voting about who did the most rewards those who announce their contributions most boldly.

Unless we're talking about a lot of money here, I'd encourage people to use the dough for non-cash rewards. E.g., that you get everybody together for a face-to-face meeting and party. Or you buy hardware and bandwidth that everybody gets to use. Or you give the money to a basket of charities that everybody helps pick. Or you sponsor somebody to go and present the project at a conference. Or you buy advertising space to promote the project. Or you buy CDs for a central streaming server for project members. And so on.

And if it is a lot of money, you probably have a chance at a much larger market, so it's worth starting a company and hiring a marketroid who can get enough sales that you can afford to hire people full time.

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 troubled times, or be leaving the team, a cash bonus is acceptable.

Just my $0.02...

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 originator wants more than you're willing to offer.

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

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

I love hypothetical questions

[Anonymous Coward]

This is a great one! An open source program with profits! Haha!

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)

Easy!

[Anonymous Coward]

Gimmee money!