On bounties

~

Bounties are great for well-scoped, low-context work. For example, bounties work can quite well for things like penetration testing, because it's fairly clear what the objective is (specifically: prove that you can wreak havoc on a system) and the task itself requires no collaboration with the core team of the project (in fact it's even better to have no collaboration, because that simulates a blackhat hacker's circumstances more closely).

However I'm not so bullish on the idea of bounties for ambiguous, high-context work. And my view is that (A) ambiguous, high-context work is much more central to the success and innovation of any sort of project, not just open source ones, and (B) people with the capacity and desire to do ambiguous, high-context work are what open source projects tend to be most sorely lacking.

If penetration testing is on one extreme of the well-scoped/low-context spectrum, then defining the vision for a project is an example of a responsibility that lies on the opposite end. There are a lot of types of work in between that may benefit from something akin to bounties, and those are all valuable, but what I'm most eager to solve is "how do we develop more leaders who can give life force to open source projects?"

~

On top of that, there are some challenging dynamics around bounties. Just to name a few:

A. Bounty allotment: Alice is the maintainer of Foo, and Bob is making his first contribution ever. Bob opens a PR to resolve an issue that someone put a bounty on, Alice reviews it, and then she merges it. Who gets the bounty? Does Bob deserve it as the author of the PR? Or does Alice deserve it as the maintainer who created/cares for the project, thus making it possible for Bob to create a PR in the first place? Do you split it in half?

One idea — You could solve this with a concept of equity, where the maintainer gets X% of any bounty and that's determined up front. Determining the right values that various folks get could be tricky, but perhaps the maintainers could just set that themselves from the beginning. This would have a very similar shape to startup founders deciding how much equity they get vs how much their employees may get. I'd need to think this through a lot more before I actually recommended it as a solution, but it's a first pass!

B. The spec isn't the territory: How do you determine if the bounty terms were met? Defining a spec is hard work, and it's never airtight. Plus, the best engineers will reframe a problem you pose rather than following exactly what you describe as a solution. This is a bit of a the-map-isn't-the-territory type of problem. The only way to define a spec completely is to write the code yourself! Of course that's taking the problem to ad absurdum, but it underscores the main point that it could be tricky for the developer and bounty poster to agree to whether or not something was met.

C. Race conditions: What happens if Bob and Charlie both work on the same bountied issue, and then open PRs on the same day? How does Alice choose whose PR to accept, and thus who earns the bounty? One way you could solve this is to tell contributors to "lock" the issue while they're working on it, but then what if they never finish it? Then, it just wastes everyone's time because no one else is working on that issue in the meantime.

D. Honeypot for (more!) low-quality contributions: Lots of maintainers already say that they're flooded by low-quality contributions. (Lots more detail in Nadia Eghbals's recent book, Working in Public. Highly recommended if you're interested in this topic!) Putting a price tag on issues would only accelerate this.

This could be mitigated by making the bounties only visible to folks who are part of the project's organization, people who've already made contributions, or some other filter. My point is just that you'd have to think it through, not that it's a dealbreaker.

E. Project coherence: Another failure mode is that bounties could warp maintainer's incentives and ability to execute on the best architecture. A maintainer might want to make one choice because it's a better architectural decision, but then a bounty for a particular feature that pollutes the roadmap is just too temptingly big.

Even if a maintainer holds fast, it could incentivize more forks because other developers see that bounty just sitting there, waiting to be satisfied. Maybe this isn't such a bad thing, because then the org that posted the bounty is happy without polluting the main project. But it leads to fragmentation (which is sometimes but not always bad) and likely immense tension within the project.

~

I don't mean to be defeatist at all! These problems are probably solvable, but I just mean to call out that designing such a product would require a lot of care and subtlety.