Better yet: give them cold hard cash instead of what is arguably monopoly money for many OSS devs. Ironically this is something GitHub made "easy" with sponsorships several years ago.
One of the cool things about code is that you can build stuff out of thin air, basically for free. It's not like woodworking where you have to pay for the wood.
We are moving into a weird time where people are assuming that now we have to pay machines churn out code.
Somehow they packaged up our own ability to think and are selling it back to us. If they can get us to forget how to do it we'll be the perfect customers, dependent forever.
At first I was like "i want to use ai but dont have the money to burn for api tokens" cool.
But then I realized the backers are essentially saying "i have money and could support developers but i choose to give the money directly to a mega corp and skip the human".
I recommend you remove the policy of "Whatever the run didn't spend goes straight back to your backers' wallets." and make sure the human behind the wheel gets to eat. Somehow
While we're in the token-equivalent of ZIRP, tokens don't cost what they cost, so there's sort of arbitrage to be had. I have tokens I've been given than I'm not using, but that's not the same as me having been given cash in the first place.
> While we're in the token-equivalent of ZIRP, tokens don't cost what they cost, so there's sort of arbitrage to be had
Do you have a source for this? I believe “personal subscription” plans on OpenAI and Anthropic are likely ran at a net loss or close to it, but all indications elsewhere are that API pricing for these companies and likely Google as well are profitable per API call [1][2]. I would definitely believe that the Chinese players are operating at a loss though if that is what you mean.
It does seem like a worse version of a FOSS donation platform that uses regular old money. I guess one advantage is that you can ensure your money goes directly to using AI to solve specific problems on the codebase, but what does that solve? Are people genuinely worried that if they donate to some FOSS platform that their dollars would go to something else? It seems to me like this removes agency from the FOSS maintainer and gives donators more control over their donation, even though it's explicitly designed not to.
Its efficiency also relies on being better than whatever other platform/harness the maintainer is already using. It's limited to whatever the harness the platform provides, and they're taking a 20% platform fee on top. So I have to, instead of taking $10 from a donor, i take $10 worth of tokens, which may or not be spent more efficiently than me just going in with my claude subscription and fixing it, and I get $8 of those to run in a platform I don't control? In what world as a FOSS maintainer would I sign up for this? It just seems strictly worse than just having a platform that can back resolution of issues with real money... which already exists.
Howdy Solar_Fields, these are great questions and I can give you my thoughts on how I feel it's different than cash donations (which are great if you can get them!). I look at this less like patronage and more an exchange of a resource to meet the needs of both parties. I want to support the projects I care about, some I'll give carte blanche, but some I have no connection to and really just want a bug fixed. Rather than fire up my own Claude Code and throw a PR at that maintainer, instead I'm saying, "hey, you know this codebase and can use this resource (tokens) better than me, please fix it with 'free' tokens." The platform fee is really just for AWS costs and is based on modeling, but I'm sure that's not the final form. Does that make sense?
Your reasoning is logical, but fails to pass the bar of "better than or even equal to just literally using some existing platform to attach a $X bounty to some issue I want resolved". There are several popular solutions that exist already to do that, your solution doesn't materially improve there, so what is the value add? It certainly gives the donor more confidence that the issue is being resolved in the way the donor wants it to, but if your problem is to make FOSS maintainer's life easier it doesn't move the needle in that direction, because it gives more power to already demanding FOSS users and less agency to the FOSS maintainer. And even if you solve that problem, does that value add cover a very-steep 20% platform fee?
I think it's a cool idea, don't get me wrong. But it has to be a very good solution to get adopted, like, it would have to significantly streamline the operations of getting bugs resolved by a FOSS maintainer, and I think it's going to be tough for you to try to beat "fire up my favorite agent in my terminal with an already optimized setup and give it this issue that has $X attached" rather than "I have perhaps inefficient token spend from a platform I have no control over and I have to take 20% less of a donation for that privilege"
In other words, I think you've built this solution for donors, and not FOSS maintainers, but really the bottleneck and problem and who you would be selling this solution to is not donors, but rather FOSS maintainers, and that's who you need to solve for if you want a platform like this to work. The donors have the easy job: they throw money at the problem to help it get solved faster. The FOSS maintainers have the hard job: They have to understand, accept the issue, propose a sensible solution, build it out, test it, etc. And your solution just makes it harder for those end users, because now they have two paths to getting issues resolved that they have to maintain, the non paid path and the paid path. So you're significantly increasing the overhead burden on these people and the material gain promised to those end users materializes how?
I think I've read from a few different sources that the Claude Code $100-$200/mo plans are subsidized so hard that it's basically $2k-$8k/mo in "would-be" equivalent API token usages.
This kind of makes sense in that space while the subsidies (if true) last?
Unrelated, "tokens" feels very like... back-then blockchain to me. All the craze.
Yeah, rising token costs definitely played into my thinking too. I want builders to be able to use the best models and it seems like they are getting more expensive. But maybe local models will get there?
We are moving into a weird time where people are assuming that now we have to pay machines churn out code.
Somehow they packaged up our own ability to think and are selling it back to us. If they can get us to forget how to do it we'll be the perfect customers, dependent forever.
Do you have a source for this? I believe “personal subscription” plans on OpenAI and Anthropic are likely ran at a net loss or close to it, but all indications elsewhere are that API pricing for these companies and likely Google as well are profitable per API call [1][2]. I would definitely believe that the Chinese players are operating at a loss though if that is what you mean.
[1] https://newsletter.semianalysis.com/p/anthropic-growth-and-b...
[2] https://martinalderson.com/posts/are-openai-and-anthropic-re...
I like your approach of pooling resources around specific issues. That seems a practical missing piece for aiding the maintainers.
Its efficiency also relies on being better than whatever other platform/harness the maintainer is already using. It's limited to whatever the harness the platform provides, and they're taking a 20% platform fee on top. So I have to, instead of taking $10 from a donor, i take $10 worth of tokens, which may or not be spent more efficiently than me just going in with my claude subscription and fixing it, and I get $8 of those to run in a platform I don't control? In what world as a FOSS maintainer would I sign up for this? It just seems strictly worse than just having a platform that can back resolution of issues with real money... which already exists.
I think it's a cool idea, don't get me wrong. But it has to be a very good solution to get adopted, like, it would have to significantly streamline the operations of getting bugs resolved by a FOSS maintainer, and I think it's going to be tough for you to try to beat "fire up my favorite agent in my terminal with an already optimized setup and give it this issue that has $X attached" rather than "I have perhaps inefficient token spend from a platform I have no control over and I have to take 20% less of a donation for that privilege"
In other words, I think you've built this solution for donors, and not FOSS maintainers, but really the bottleneck and problem and who you would be selling this solution to is not donors, but rather FOSS maintainers, and that's who you need to solve for if you want a platform like this to work. The donors have the easy job: they throw money at the problem to help it get solved faster. The FOSS maintainers have the hard job: They have to understand, accept the issue, propose a sensible solution, build it out, test it, etc. And your solution just makes it harder for those end users, because now they have two paths to getting issues resolved that they have to maintain, the non paid path and the paid path. So you're significantly increasing the overhead burden on these people and the material gain promised to those end users materializes how?
This kind of makes sense in that space while the subsidies (if true) last?
Unrelated, "tokens" feels very like... back-then blockchain to me. All the craze.