You don't sponsor people or projects to complete specific issues or build specific features in the first place. Sponsorship is a reward and token of appreciation for doing good work.
Some don't mind doing the overall reward and appreciation thing. And some just have that particular issue that they want handled so the project works - better - for them. Both cases are valid.
I'm not sure how that's related to your initial question of "How do you ensure that funds ear-marked for a donor-specified issue goes toward that issue and not something else?"
The point is to get something funded. That's the goal. And negotiation doesn't scale. You can bet that nobody will negotiate contracts with 20 maintainers if they want particular features/fixes for 20 different projects that they're using. Otherwise it would be a thing today.
But instead we have these attempts and stopgaps, some of which have had some success here and there. This is something else in that pool making it easier to fund stuff, and if it gains traction than we'll know that it's serving its purpose. I think it has good potential.
I wasn't thinking about companies at all. Companies tend to only contribute to well-known projects, which leaves a very long tail.
I'm thinking about the far more random regular people using random projects that may not be that popular. Like I just did a rough count of the OSS apps on my phone: 60+. Of those there are 5 that I can immediately think of improvements that I'd like. One of them I've actually made improvements to already because it was a dead project that I really like and so had to revive anyway. And I used Claude to work on it as I'm not a mobile dev; been planning to republish but haven't gotten around to it. I won't bother to check my laptop but there's even more there.
Now imagine if I (and others interested in those projects) could contribute to small funding pools for various projects of interest, with the assurance that said funds go to that feature/fix which is of interest or gets refunded. I think that'd result in the general OSS support needle being pushed that much further over time.
You hit up the maintainer and negotiate a deal for that?
If all you’ve got is relative pocket change they probably aren’t going to agree but if you put real money behind it and it doesn’t go against their vision of the project then most people would be willing to accept actual contracting work to expand their project.
Pretty straight-forward solution: donors or maintainers don't use the service if it isn't good. But the maintainer is "accountable" (to the extent one maintaining a OSS project is) as they're the one actually providing the prompts and doing QA.
You don't sponsor people or projects to complete specific issues or build specific features in the first place. Sponsorship is a reward and token of appreciation for doing good work.
Some don't mind doing the overall reward and appreciation thing. And some just have that particular issue that they want handled so the project works - better - for them. Both cases are valid.
Yes, and donation/sponsorship is not the tool for the latter.
What matters is if it works out (gains traction) or not.
I'm not sure how that's related to your initial question of "How do you ensure that funds ear-marked for a donor-specified issue goes toward that issue and not something else?"
If you want that, negotiate a contract.
The point is to get something funded. That's the goal. And negotiation doesn't scale. You can bet that nobody will negotiate contracts with 20 maintainers if they want particular features/fixes for 20 different projects that they're using. Otherwise it would be a thing today.
But instead we have these attempts and stopgaps, some of which have had some success here and there. This is something else in that pool making it easier to fund stuff, and if it gains traction than we'll know that it's serving its purpose. I think it has good potential.
I don’t think companies are donating to 20 different maintainers in the hopes of getting 20 different specific features implemented, either.
I wasn't thinking about companies at all. Companies tend to only contribute to well-known projects, which leaves a very long tail.
I'm thinking about the far more random regular people using random projects that may not be that popular. Like I just did a rough count of the OSS apps on my phone: 60+. Of those there are 5 that I can immediately think of improvements that I'd like. One of them I've actually made improvements to already because it was a dead project that I really like and so had to revive anyway. And I used Claude to work on it as I'm not a mobile dev; been planning to republish but haven't gotten around to it. I won't bother to check my laptop but there's even more there.
Now imagine if I (and others interested in those projects) could contribute to small funding pools for various projects of interest, with the assurance that said funds go to that feature/fix which is of interest or gets refunded. I think that'd result in the general OSS support needle being pushed that much further over time.
Then you offer to pay the maintainer their consulting rate to do it if they are willing.
That's one way to go about it, but doesn't exactly work when one has targeted requirements in 20 different projects.
You hit up the maintainer and negotiate a deal for that?
If all you’ve got is relative pocket change they probably aren’t going to agree but if you put real money behind it and it doesn’t go against their vision of the project then most people would be willing to accept actual contracting work to expand their project.
Sounds like a lot of trouble to go through, vs just sending some funds to a wallet with the assurance it'll go where you want it to or return to you.
You actually hire a developer to work on that issue and not something else.
Pretty much what this ensures. Just that the "developer" is a LLM agent.
Yeah except that the agent cannot be held accountable if its fix is crap, or if it went off-track mid-fix.
Pretty straight-forward solution: donors or maintainers don't use the service if it isn't good. But the maintainer is "accountable" (to the extent one maintaining a OSS project is) as they're the one actually providing the prompts and doing QA.