1. Discussion about bounties

Open source software is commonly known for seeking alternative funding models than selling licenses of software. That's why the idea of bounties are supposedly to be a very interesting factor in the way developers should be remunerated for their work in the FLOSS world.

However, for some reason, this methodology has not indeed really taken off and it's not very usual. Furthermore, the best success case of this (GSoC) doesn't really apply well to the idea, because here the party that puts the money is not really the one that pushes the idea to be paid for (it's the open source organizations who choose what to invest time in), so Google is kind of an altruist player.

Besides, bounties do not always reach a good end. Many GSoC students fail to meet their deadlines, and many bounties are never given to their assignees because of lack of agreement on the objectives.

Shouldn't we then focus on a bounty system that focus on concretion (avoiding ambiguities), fosters motivation (to prevent failure) and is governed by many parties to prevent disagreement? If yes, then, let's learn from past experiencies and set a bunch of rules in order to try to avoid them:

1. From source (A), it seems there was never a clear status of where the bounty was in regards of the factual agreement. Some people thought that Mark did an agreement with Daniel, but the bounty was indeed still open. For this kind of problems we need a correct tool for managing each issue and for letting others know the state of it at any time. Something like Bugzilla but specific for bounties, or an add-in for Bugzilla (or <put here your favorite bug tracking tool>). The only reliable (open source) tool/service that I know of, for doing this, is FossFactory.org.

2. From source (A), the project for a bounty should not never be too large. Otherwise, there's risk that the developer gets stuck, burns out, and in the end never perceives any part of the bounty for an incomplete work. Thus, a third party should examine the viability of the time scheduled and planned goals for the bounty. Ideally, the third party should be a technical party involved in the development of the project (for example a current or former maintainer, or a really active contributor).

3. From source (A), one of the reasons that seem to cause the failure was the lack of the familiarity of the developer with the codebase. Of course this is open source and anyone is welcome to participate, but for the sake of having successful bounties, maybe we should have some very basic rules that limits the people allowed to participate. For example: the developer must have contributed for the project in the past, and a current contributor or maintainer has to vouch for him (kind of a referral system). Or, once the bounty is posted and a not-past-contributor steps up to work on it, let a certain time pass (like 2 weeks), before work really starts, in case some other guy in the community wants to opt for the work as well.

4. From source (A), in order to prevent disagreements about determining if the goals were reached (and which of them), either because of the project had to be stopped or because the funder doesn't agree with the resulting work, we should stablish 3 rules: a) In case the funder is one individual, he must provide clear and concrete testcases (as formal checklists or automated tests) he will run to check that the feature has been properly developed. b) A "third-party arbitrator" decides upon disputes refering to the success or failure of the testcases provided. c) We should not encourage bounties which are supported by many individuals. In an hipothetic world in which proprietary didn't exist, we would have a so big user base that it would be so easy to have, let's say, bounties supported by 100+ people where each supporter gives a very small amount, like 10 dollars. This way, the role of the "third-party arbitrator" vanishes to become just a matter of a democratical consensus.

5. [No particular bad previous experince on which we base this rule for now] In order to prevent disagreements about the approach selected (let's say the maintainer doesn't want to merge the work upstream...), some person with responsabilities in the project (the benevolent dictator) should be the one that approves the high level thoughts on the approach that the developer should take (decide which dependencies to use, what levels of abstraction, use of threads, etc.) just before the work starts.

6. [No particular bad previous experince on which we base this rule for now] If a group doesn't team up for the development of a feature (that is, the assignee is just an individual), there should be a rule to prevent facing overwhelmings amounts of work for people who don't really have enough time, so if the issue to be worked on is large enough, the individual should be unemployed or only part-time employed to be able to apply for the job.

Of course, you have to see these rules as a motivation to prevent failure, not as a list of commandments surrounding bounties in the FLOSS world, because, as you know, on open source there are no monopolies, and anyone can sign a deal or contract with any individual to provide any kind of service outside this bounty system that we may try to stablish in our community.

Things that we still need to figure out:

* What percentage of the bounty should the third-parties involved perceive?

* There are some voices in the FLOSS world that seem to compare the money-bounties to the failure of the healthcare systems in countries where it's not public/free. They seem to argue that FLOSS nature doesn't deal well with this kind of methodology. Some of these voices also advocate for an alternative in which the thing to trade is not money, but rather, just an exchange of development tasks ("I fix X for you if you fix Y for me").

Sources:

A) Gimp Bounties: http://dneary.free.fr/gimp_bounties.html

Please, don't hesitate to propose more rules, comments and sources of experiences about working with bounties. Thanks!