Show HN: Algora – Paid open-source contributions (console.algora.io)
1 min demo: https://twitter.com/algoraio/status/1641560954746839042
The problem: paid contributions in open source are scarce, low trust & high friction
Our solution: we built an app that streamlines open source bounties on Github
Our 1st customer was Remotion.dev (15.6k stars, Typescript/React) in November 2022, whose feedback helped us ship our Github app & iterate through our bounty workflow. To date, Remotion.dev has rewarded 17 open source bounties: https://github.com/remotion-dev/remotion/issues?q=label%3A%2...
Since then, we’ve been fortunate to also onboard Cal.com (17.6k stars, Typescript/Next), IHP (3.9k stars, Haskell), Qdrant.tech (5.4k stars, Rust), erxes.io (2.8k stars, Typescript) and shuttle.rs (YC S20, 2.1k stars, Rust).
OSS contributors in the US, Europe (Germany, France, Norway), Canada, Nigeria, India, Egypt, UAE, Brazil, Colombia, Philippines and Australia have already earned bounties with Algora — we hope this list keeps growing!
We also started a COSS founder interview series to share lessons & advice for building open source companies: https://youtube.com/@algora-io
We are really excited to hear your feedback/questions and connect further: our emails are ioannis@algora.io & zafer@algora.io. Thank you!
70 comments
[ 3.2 ms ] story [ 134 ms ] threadI hope this answers your question, thank you so much for your feedback! happy to follow-up here
What I'm trying to say is: The line could be blurry. The PR code quality could be crap and the project really needs to invest a lot of time to make this fit for merge, in which case they rightfully refuse the bounty. But it could be that the code quality is great and they are just trying to misuse this to make people do more than they originally wanted. And the difference between those scenarios could be hard to see for somebody external. Or even for the parties involved: The project could legitimately think that the code is not of sufficient quality while the submitter could legitimately think that they satisfied the request.
Who is the arbitter? Will people tend to accept the PR anyway (silently clean up and spend time afterwords), not wanting to risk their reputation? Or will submitters tend to accept major changes, possibly beyond the original ask, not wanting to risk their reputation? Seems a bit to me like a problem also faced by Airbnb and similar services.
you can look at Remotion's 17 completed bounties, where specs & acceptance criteria are always included: https://github.com/remotion-dev/remotion/issues?q=label%3A%2...
that being said, we have only had a handful of projects using OSS bounties so far so we haven't seen everything under the sun. I acknowledge what you mean by blurry lines and how/when they might occur. but as I said before, when specs/scope/acceptance-criteria are in place, it's really hard to go wrong
At these levels it's not such a concern about getting stuck with a bad job. You just don't use that developer again and the $200 didn't wipe out your company.
I've commissioned jobs like that on freelancer sites for a lot more and pretty much did the same thing. Paid someone else to rework it or reworked it myself. I wouldn't use them again, but I did still get enough of what I needed and the job got done.
I guess it goes the other way too. Let's say I'm uncommonly generous and most other consumers will be much more demanding and try to get away with whatever they can. So the same thing as a provider. You get burned by one buyer for $200, you just don't service them any more but otherwise don't worry about the chance too much.
I see many potential use cases for this project:
1. As a developer, I have had customers paying me to contribute improvements to open source projects they depend on, this case is very tricky because there is no guarantee that the upstream project will accept the change.
2. As a company, we have had the need for some improvements to our projects that we don't have time for handling, a platform like this could have helped us.
On the other hand, I see some potential issues:
1. As a developer, it is hard to invest the time on a task when there is no guarantee for the payment, imagine I start investing 1 week in completing a bounty just to see someone else getting its PR merged before I finish mine, have you considered adding a locking mechanism? let's say, if I get the bounty assigned, I get up X time to deliver, otherwise, the bounty can go to someone else.
2. As a company, I'm not sure that many companies would be willing to commit to the 23% fee, maybe there is a way to structure this in a friendlier way? for example, taking a 20% fee up to $Y, even Upwork has a different % based on the amount paid by a company to a developer (staring at 20%, going up to 5%).
3. As a company, assuming a bounty can get locked to a dev, if I get many people interested in a bounty, how do I decide which one to pick? displaying historic data about devs could help.
In any case, good luck!
EDIT: I also haven't seen how a dispute would be handled, let's say, a dev sends a PR but a company rejected it but silently takes the code to use it. The inverse case could happen, a dev submitting low-quality work and demanding the company to pay.
1. developers get assigned by the maintainers/core-team so there is no duplication of effort, there are never multiple developers working on the same bounty. if there's no progress from the assignee, maintainers / other developers would check in and the issue would get reassigned, there is self-regulation. that being said, standardizing this process through a 'locking mechanism' is an interesting idea, we will think it through - thanks!
2. the sliding-scale fee model you are suggesting is an interesting idea, we'll think it through! if companies try bounties, are satisfied and would like to commit to a bounties budget, at the moment we offer the option to pre-pay fees at a discount. there's definitely room for experimentation here, thanks for your note!
3. great point, at the moment you'd evaluate people by looking at their github profiles and whether they've contributed to your project before (or other projects in your ecosystem). there's definitely room to improve that 'selection' process for maintainers. once again great point!
I have read the website docs again and I can't find any reference to this or how the process work.
As a company, I would hope to see more docs related to the business before trying it out, the docs assume that you are already integrating the bounties, there are even API docs (which are fine) but no clear definitions on dispute handling (these cases will occur sooner or later).
> 1. As a developer, I have had customers paying me to contribute improvements to open source projects they depend on, this case is very tricky because there is no guarantee that the upstream project will accept the change.
So far, my understanding is that this case is not supported, is there any plan for it? it is the most common I have been hired for.
Thanks.
regarding your last point, yeah this use case is very tricky, indeed there is no guarantee that the upstream project will accept the change. in fact, that project would need to have the algora app installed to begin with. that being said, we understand there is a pain point here, so we will note this down and seek additional feedback. we won't hesitate to reach out if/once there is a development here :) thanks so much once again for all your feedback!
[0]: (emacs week) https://news.ycombinator.com/item?id=35413940
In general I think this is a good direction and an interesting take on the open question around sustainable open source. Congrats on the launch and keep up the great work! :)
That seems, a little high, nearly a quarter.
>We also offer discounts to FLOSS projects (non-commercial license, no monetization).
That isn't what FLOSS means, FLOSS can still be commercial, usually by offering hosted solutions. I may be misinterpreting what you mean though.
Indeed it's also not what FLOSS means.
Still, I wish you the best and hope you succeed, because a proper alternative to bountysource is welcome. But this leaves a bad taste in my mouth from the beginning :/
in order to ensure we can continue providing value to the open source community, we need to make sure our own project is sustainable.
we are a bootstrapped startup without any VC funding and so we cannot cut corners when figuring out a sustainable business model. our current customers, who are all commercial open source companies, are happy with our pricing. and we're happy to accommodate non-commercial projects with discounts.
I say this as someone who tried to build something extremely similar years ago (Fosset, also bootstrapped). I thought I’d get away charging 30 percent, and it was both stupid and greedy. My cut should have been less than 10%, including payment processing fees.
I can see that you have very little cash coming in because despite some high profile clients (congrats on cal.com, love em), very few bounties are being paid out. But that’s a now thing, not a long term thing if you do things well. Your service should/would make it dead easy to support bounty setups and payouts.
A flow of 1k usd per day would net you today around 6k per month. That flow is basically nothing. A comparison point for you I think is codementor.io — small jobs with coding help (= dev centric community, focused on enabling payments for coding). They have about 20 jobs per day getting completed, at around 50-100 usd per job. That’s a flow of 1500 usd per day for someone who will be a far smaller player than you in the long term.
Your advantage is that you have a viral business model: you’re operating in public so the more people use you, the more you’ll get noticed. But you depend on open source projects signing up and that will be your bottleneck. And projects won’t sign up if a quarter of the cash goes to the landlord. If you do manage to get to cash positive with this cut you’re unlikely to ever reduce it; whereas if you start with a reasonable cut, you can still increase it potentially while grandfathering current users for a long period. And you’ll land more projects.
My advice: Lower your cut to 7.5 percent and focus all your effort on landing projects that have high intensity bug trackers and don’t move much money today. Make it so users can contribute bounties to issues and that a customisable public cut of the issue’s bounty always goes to the project maintainers (this will make it easier for maintainers to adopt). Make all this dead easy and you’ll move 10k per day in 2-3 years.
contributors get 100% of the bounty :)
thank you for your feedback here and sharing your story!
I edited my post to make it more useful. Good luck, feel free to email me if you want to chat.
there's definitely room for experimentation here. that being said, we do not think the Algora 20% fee (+3% Stripe fee) is unreasonable, especially when we offer discounts upon request & are happy to accommodate non-commercial projects.
perhaps "non-commercial" (no monetization / financial backing) is a more appropriate term here?
Fairness is important. I've refused to use platforms because the cut seemed unfair before - it's one of the reasons I've had to stop buying kobo books through the android app- and I'm sure that's a common sentiment.
wanted to clarify that contributors get 100% of the bounty
our fee is paid by the bounty creator (org) on top of the award
For example, NextCloud Tasks has an issue that is years old with hundreds of people asking about it and offering bounties but nobody has made it happen. Can this product help with crowdsourcing bounties or would NC have to be paying the bounty? https://github.com/nextcloud/tasks/issues/34
crowdfunding bounties amongst users of OSS for features they'd like to see is a very interesting concept indeed and could help. however, it may also be a double-edged sword for the maintainers (ex users might feel 'entitled' with their requests now that money is involved, and this might happen on issues that are not part of the maintainers' roadmap).
we've been asked about this before, we don't yet understand all the dynamics here fully and refrained from developing, but it's a feature we can ship easily. we're holding back until a project explicitly agrees to have crowdfunded bounties in their repo and users who are ready to crowdfund it. happy to hear more feedback on this and continue the conversation!
so instead of the crownd deciding what they want to fund, the organization puts up something like a kickstarter for that feature and then asks the crowd to chip in.
or put differently: now you only support bounties that are already funded, and these would be bounties that are not yet funded, and like a kickstarter they are waiting for supporters.
as noted above, the dynamics of this feature can be tricky, but we're open to give it a try once an organization is onboard for such an experiment and users / contributors have already voiced their intention to crowdfund in this way
really appreciate your input, thanks em-bee! happy to discuss further ioannis@algora.io
I'd be interested in using a service like this, but only if it offered a good way to crowd-source the funding for bounties.
Ideally we'd be able to accept proposals for bounties, and then have a Kickstarter-style mechanism for the funding, which is held in escrow and then released to whoever completes the bounty.
Feel free to email me if you'd like to chat more :)
we'd definitely appreciate your thoughts on this one, will email you :)
the same people that work on regular bounties.
once a bounty is funded through crowd-donations, the organization and the developers just treat it like a regular bounty.
effectively, what it comes down to is implementing a crowdfunding system.
i see three scenarios:
the current bounty means: we have money, but we don't have developers for this feature, so we'll put up a bounty.
then you have the case where: we have developers, but we don't have money, so we need crowdfunding.
and finally both together: we have neither developers nor funding for this feature, but if we can get this crowdfunded we can put up a bounty.
actually, crowdfunding would or could be independent from the bounty process because it is just a method to get funding. so it's even a question whether this is in scope of algora or should be something separate. i can see the advantage of having both in the same app because a crowdfunded feature could graduate into a bounty automatically: this bounty goes live as soon as the funding goal is reached,
but on the other hand this would also add complexity and maybe even confusion, because now you are dealing with three types of users: the organisation, the contributing developers and the financial supporters.
non-commercial open source orgs usually lack the budget for bounties, and so they'd miss out on this utility. we shipped a sponsorships feature in february (1min demo: https://youtu.be/cl-1tQaN-40) to eventually ameliorate this, but have kept the feature in alpha. it could be tied into the crowdbounties as you described.
we also think there can be an advantage to having both in the same app.
just taking it one step at a time.
would love to chat about this (cal.com/ioannisflo) & keep you updated (ioannis@algora.io) if you'd like, once again really appreciate your feedback on this!
btw: consider a monthly (or other interval) repeat option
Wish the project all the best!
what's wasting people's time here? is there a specific alternative you'd like to see or?
thank you for your wishes!