= Introduction = Many OSS projects have developer bounty systems: * freeswitch * pfSense * Funambol A 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 correctly is not trivial. He are a few links for background information: * http://live.gnome.org/BountiesDiscussion lists some interesting thoughts. * http://nextsprocket.com/ looks like a relatively active site for opensource bounties in general. * https://www.bountysource.com/ = Origin of the idea = This idea originated from ecrist and was discussed first in an IRC meeting. It was discussed on the -devel mailinglist soon afterwards: * http://thread.gmane.org/gmane.network.openvpn.devel/3707 = Summary = Here is a summary of the ideas formed in the IRC meeting and the email exchange that followed. == Claiming tasks == * Developers setup up accounts and 'claim' tasks * After a specific timeout a task becomes available to another user, unless progress can be shown * Non-OpenVPN developers should not be intentionally excluded from claiming the bounties. However: * Bounty developers need to be able to prove that they can get the job done (technically) * Bounty developers need to work closely with OpenVPN developers * Patches written in a hole and then sent to -devel mailinglist will be rejected == Payments == * 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. * Multiple users could fund a bounty for intensive feature additions which may warrant higher payouts. * Payment should be divided into multiple phases to motivate developers to maintain the code they've written. For example: * 50% payout for a commit to main tree * 25% upon release in production (provided bugs are fixed/etc) * 25% 6 months after release (provided bugs are fixed/etc) * This would also in part guarantee the quality of the code * Handling monetary transactions * Could be handled through an external foundation / organization (e.g. http://www.spi-inc.org/projects) * We could establish our own foundation for the purpose == Licensing and copyright == * Developers should be able to choose between GPLv2 and BSD license