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!
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.
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?
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.
[0]: (emacs week) https://news.ycombinator.com/item?id=35413940
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.
I 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.
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!
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! :)
