Would be cool if bounties could have an expiration date. I’ll pay $100 if issue X is fixed by date Y. Probably more reflective of business value too, since if an issue isn’t fixed relatively quickly I’ll have to build my own workaround.

Polar could certainly be abused that way, but I think it's a theoretical problem more than a realistic one.

Open source operates in a marketplace today (just not an economic one) so market dynamics would flush this out imo. Intentional bugs, stale development etc would lead to user churn and/or forks. I'd argue faster within OSS where users can see how things are handled.

Having said that, I certainly think the risk of it and fraud more in general increases once an economic marketplace is formed. However, I think those problems are then "good" problems to have and easy ones to fix, e.g flagging repositories with unusually high ratio of repeat pledges, velocity of bugs etc.

Another kind of problem would be when someone pledges a big sum for an obscure feature, a first-time contributor writes a (technically perfect) PR for it. Maintainer does not want to merge it, because the feature does not align with maintainer's project goals. But not merging will now look like a dick move, as it denies the PR author the compensation.

With Polar today only the maintainer receives the pledges once an issue/feature is completed. However, we're working on the ability for maintainers to split that with any potential contributors. It's definitely an important feature and part of our model. Just something we decided to scope out from the initial launch – in the interest of launching early and building in public.

An important distinction between Polar vs. traditional bounty services though and regarding your point is:

Everything goes through the maintainer(s) and we're equipping them with the insights, capital and tools to reward their contributors. While bounty services allow anyone to post a bounty and anyone to pursue it. However, ultimately it needs to be reviewed, merged and maintained indefinitely by the maintainer(s). By ensuring it all flows via maintainer(s) it:

1. Rewards maintainers as well – key given their efforts

2.Guarantees maintainers are aligned & behind pledges first. Combined with in control on how to expose, delegate and reward it. Avoiding unnecessary friction, bad faith and overhead if such alignment is first made during PR.

Then the payment can go to a fork. If the maintainer really wants to keep his vision for the project and others are literally voting with their wallets for something else, why would that be a problem?

If they were simple to fix other people would just fix them an make a PR.

If a project became notorious for pulling stuff like that, and rejecting pull requests, people would most likely just make a fork.

I guess that also raises the issue of who gets paid if a third party pull request fixes an issue.

Bad incentive structures are everywhere though, including at corporations where people design "cool" architectures which fail, and then swoop in to save the day.