For posterity: Through a bit of engineering work and better anomaly management, I’ve been able to get the platform fee down to 5%! I’m quite proud of this as there’s a lot of moving parts. In time I’ll probably be able to get it lower too which makes me happy (says the guy that tried to give his first startup away for free). :tada:
I've got a couple good docs in the footer of www.clevercrow.io that will answer the token stuff. GitHub app integration for all repo interaction. Yep, backers can target specific issues or entire repos, their choice.
100% expected, in fact, desired (maintainers should be/are in charge). My goal is to create enough surface area that backers see their tokens going to many of the things they care about, not necessarily all.
Well then, I'm hoping it's more of a San Junipero/Hang the DJ episode where good stuff happens by the end.
I think there's a trust continuum that culminates at giving money no strings attached, but it starts somewhere else. If my goal (as creator of CleverCrow) is to get more people to support maintainers, then I have to open the funnel wide and connect with where people start (transactionally, I'm assuming).
Probably an oversight on my part. I was thinking that backers would find out about CleverCrow through the project maintainers so the public pages are repo specific.
As an aside, when you do login, CleverCrow shows projects that you've starred on GitHub to help find things you might want to support.
Full details on the permissions we request from GitHub are present here: https://app.clevercrow.io/github-access. Regarding bank access, all financial transactions are handled by Stripe in an incredibly conventional manner. Additional details on that in the privacy doc: https://app.clevercrow.io/privacy
While I definitely like the Patreon for Software Builders idea, that's got some moving pieces which take additional legal work. My hope is that could come in time as it would be really cool.
Regarding rewarding maintainer effort, I'm shooting for the value prop of "free AI", this only works if reconciliation is per-phase and liquidity is accessible across as many repos as possible. So if I had each reconcile drain the pool, there would be a lot of stalled work and human intervention required.
That said, there are probably some maintainers that don't want "free AI" and that's okay.
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?
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 in their development workflow 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 as the tradeoff is not convincing at all.
I hear you. I'm trying to balance the needs of backers and builders and it's admittedly a tough one. 20% is too high and I'll be adjusting that. The numbers I'm getting from usage today are really helpful in calibrating, so I'm sure I can get something more balanced there.
My hope is that maintainers can offload some busy work to helpful agents and create a more connected community. Likewise, that people otherwise unable to afford the high end frontier models would get to use them for free. Also not something everyone wants, but I know some do. I really do appreciate your feedback and your passion.
