Changes between Version 2 and Version 3 of DeveloperBounties


Ignore:
Timestamp:
07/16/10 09:27:08 (14 years ago)
Author:
Samuli Seppänen
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • DeveloperBounties

    v2 v3  
    77 * Funambol
    88
    9 Here are a few links to bounty discussions elsewhere:
     9A well-executed bounty system would allow users to prioritize feature additions through compensation. It would help achieve greater interest of developers in users' requests and needs. That said, implementing the system correct is not trivial. He are a few links for background information:
    1010
    1111 * http://live.gnome.org/BountiesDiscussion lists some interesting thoughts.
    … …  
    2323Here is a summary of the ideas formed in the IRC meeting and the email exchange that followed.
    2424
     25== Claiming tasks ==
     26
     27 * Developers setup up accounts and 'claim' tasks
     28 * After a specific timeout a task becomes available to another user, unless progress can be shown
     29 * Non-OpenVPN developers should not be intentionally excluded from claiming the bounties. However:
     30  * Bounty developers need to be able to prove that they can get the job done (technically)
     31  * Bounty developers need to work closely with OpenVPN developers
     32  * Patches written in a hole and then sent to -devel mailinglist will be rejected
    2533
    2634
     35== Payments ==
    2736
    28  * '''Rationale'''
    29   * Would allow users to prioritize feature additions through compensation.
    30   * Would help achieve greater interest of developers in users' requests and needs.
     37 * Bounty funds would be setup and maintained by a non-developer (ecrist?) and held.  This assures payment upon completion and assures feature is completed before bounty is paid.
     38 * Multiple users could fund a bounty for intensive feature additions which may warrant higher payouts.
     39 * Payment should be divided into multiple phases to motivate developers to maintain the code they've written. For example:
     40  * 50% payout for a commit to main tree
     41  * 25% upon release in production (provided bugs are fixed/etc)
     42  * 25% 6 months after release (provided bugs are fixed/etc)
     43  * This would also in part guarantee the quality of the code
     44 * Handling monetary transactions
     45  * Could be handled through an external foundation / organization (e.g. http://www.spi-inc.org/projects)
     46  * We could establish our own foundation for the purpose
    3147
    32  * '''Implementation ideas'''
    33   * Bounty funds would be setup and maintained by a non-developer (ecrist?) and held.  This assures payment upon completion and assures feature is completed before bounty is paid.
    34   * Multiple users could fund a bounty for intensive feature additions which may warrant higher payouts.
    35   * Developers setup up accounts and 'claim' tasks
    36   * After a specific timeout a task becomes available to another user, unless progress can be shown
    37   * Payment could be divided into multiple phases to motivate developers to maintain the code they've written. For example:
    38    * 50% payout for a commit to main tree
    39    * 25% upon release in production (provided bugs are fixed/etc)
    40    * 25% 6 months after release (provided bugs are fixed/etc)
    41   * The above would also guarantee the quality of the code
    42   * Handling monetary transactions
    43    * Could be handled through an external foundation / organization (e.g. http://www.spi-inc.org/projects)
    44    * We could establish our own foundation for the purpose
    45   * Licensing and copyright
     48== Licensing and copyright ==
     49
     50 * Developers should be able to choose between GPLv2 and BSD license