On 6/8/07, YKY (Yan King Yin) <[EMAIL PROTECTED]> wrote:
I noticed a serious problem with "credit attribution" and allowing members
to "branch outside" of the mother project.
For example, there may be a collection of contributions, from many
members, that is worth $C in the consortium. Suppose someone decides to start an external project, then adding $c of new contributions to it, but where $c is unknown because it's outside the consortium's attributing system. Then, suppose the new project sells a million copies and earns $NetProfit. $NetProfit may be a very big amount because of leverage / nonlineae effects.
The *fair* amount to pay back the consortium should be $PayBack =
$NetProfit * ($C / ($C + $c)). Unfortunately, $c occurs outside the consortium and cannot be measured easily or consistently. Not being to estimate the $PayBack, the whole scheme is thrown into question. Also, using an approximate formula for $PayBack may not work since people will try to exploit the approximation to their advantage.
It seems that allowing members to "check out" is very difficult, if not
impossible, to manage. The only alternative that's left is to restrict members to participate and develop projects within the consortium *exclusively*... but this will turn off many people as they don't see why the consortium will win instead of other projects... and this is the problem faced by all AGI founders trying to recruit... After some thinking, there may be a solution to this problem, which is to let members estimate $c as well. In other words, let them estimate how much of a particular branch is completed as a percentage. So if someone wants to "check out", he'll agree to pay with shares of his new project equal to that percentage. Being optimistic again, there're reasons to believe that most members will try to give fair and accurate estimations. (Think: if you have contributed something, it'd be in your best interest to give accurate estimates rather than exaggerate or depreciate them). Notice that this scheme is more likely to work with a high number of participants, but may fail when there are very few contributors to a particular branch -- but this is OK because *any* serious AGI project has to be large-scale anyway. YKY ----- This list is sponsored by AGIRI: http://www.agiri.org/email To unsubscribe or change your options, please go to: http://v2.listbox.com/member/?member_id=231415&user_secret=e9e40a7e
