[HN Gopher] Show HN: Algora - Paid open-source contributions
___________________________________________________________________
Show HN: Algora - Paid open-source contributions
Hey HN! We're Ioannis & Zaf, building Algora.io to help open source
projects reward their contributors & grow their communities. 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!
Author : zcesur
Score : 69 points
Date : 2023-04-02 16:23 UTC (6 hours ago)
(HTM) web link (console.algora.io)
(TXT) w3m dump (console.algora.io)
| varunjain99 wrote:
| Congrats! I've always thought the bug bounty structure in
| security should be more prevalently applied to just building OSS
| software
| irf1 wrote:
| couldn't agree more, why limit bounties to just bugs/security
| rather than apply them to OSS product development broadly.
| thank you for your input!
| bakigul wrote:
| Congratulations. it's great
| irf1 wrote:
| thank you Baki! great to have you on our platform :)
| techn00 wrote:
| 23% fee is way too much for this service
| Maksadbek wrote:
| I can't sign in on iPhone. The only option available to signup is
| by magic link. I receive the link and open it on gmail app then
| when I click it automatically opens in a sandbox Safari tab. As
| sandbox tabs are temporary, the cookie is lost when it's closed.
| zcesur wrote:
| hey Maksadbek, thanks a lot for reporting this! looking into it
| right now. in the meantime, you can hold down the button in the
| email to copy the magic link and paste into your browser
| Maksadbek wrote:
| Hey! I already tried this. iPhones auto open links in mini
| window as a preview when holded. As a result, the copied link
| will be already expired.
| zcesur wrote:
| oh i see, sorry about that. just deployed a new version
| with an additional link typed out in the email. can you let
| me know if that works?
| raybb wrote:
| Am I understanding correctly that this only works in a flow such
| that the Org maintaining the project can create and pay bounties?
|
| 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
| irf1 wrote:
| excellent question, thanks! correct, at the moment only Orgs
| create & pay bounties
|
| 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!
| em-bee wrote:
| crowdfunding could be handled in a way that organizations
| decide what issues/features to accept, like they would now,
| but instead of putting up a bounty from their own funds they
| say: we don't have the funds to pay for this feature, but if
| we get enough donations then we can pay someone to build it.
|
| 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.
| irf1 wrote:
| interesting. in this scenario, who would end up
| implementing the feature & earning the bounty? a
| maintainer, a contributor or either?
|
| 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
| mendorshikh wrote:
| Congratulations on launching Algora.io! Your solution to
| incentivize open source contributions through streamlined
| bounties is much needed in the community. It's great to see that
| you're tackling the problem of low trust and high friction in
| paid contributions. I'm excited to see how Algora.io will help
| grow open source communities and reward the hard work of
| contributors. Best of luck with your project!
| zcesur wrote:
| thanks for your message & sharing your first bounties today, MJ
| - super excited to have you on algora!
| Met_Ade wrote:
| Hey! We at Remotion are super happy to be Algora's first customer
| and found their solution to streamline open-source bounties on
| GitHub really helpful. It's awesome to see other great projects
| joining. The team at Algora is doing a fantastic job in
| continuously improving the experience to engage and reward our
| contributors. Keep up the great work!
| zcesur wrote:
| <3 wouldn't be here without you guys. thank you so much!
| Drunken_Founder wrote:
| What if the user who made the bounty suddenly changes his mind
| and decides not to reward someone who solved it and made a
| commit? how would you guys go on making sure that nobody does
| this, just curious seems like a cool idea though.
| irf1 wrote:
| that's a great question, thank you Drunken_Founder! haven't
| experienced something like this. because everything is public,
| we think that acts as a deterrence for people to do what you
| described. in addition, we closely keep track of bounty
| activity, and so if we see that a bounty has been completed
| (per the spec/acceptance criteria) but not rewarded for a
| while, we'd reach out to the maintainers to check in. if we
| ever determine any foul play, it's only fair and reasonable to
| un-feature that org from bounty discovery on Algora and suspend
| their use of our app.
|
| I hope this answers your question, thank you so much for your
| feedback! happy to follow-up here
| pl90087 wrote:
| I suppose that even covers a more intricate case: Somebody
| submits a PR, lots of discussions back and forth, lots of
| asks from the project, finally the submitter gives up since
| they don't want to keep spending time on things that start
| diverging from the original ask. After that, the code is
| there, the project eventually takes the code and integrates
| it themselves after little work. Or a lot of extra work.
|
| 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.
| irf1 wrote:
| thank you for your input! the best way to ensure everyone
| has a great experience is to spec & scope bounty issues +
| provide acceptance criteria.
|
| 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
| hankchinaski wrote:
| i had exactly the same issue and was planning to build something
| like this before. glad i have found you. i opened a couple of
| bounties for my OSS project.https://console.algora.io/org/golang-
| cafe/bounties. willing to try now although i will only use it for
| small items, the fee is too high.
| irf1 wrote:
| glad you found us too Diego! thank you very much for sharing
| bounties :)) always happy to get in touch and work something
| out, we wouldn't want our pricing to prevent you from enjoying
| the service! ioannis@algora.io welcome to Algora!
| _query wrote:
| At IHP we've been using Algora for a while now and it works
| really great. Here's e.g. one PR that was merged last week with a
| bounty attached
| https://github.com/digitallyinduced/ihp/issues/1621 Everything
| was set up in less than 15 minutes and ioannis and zafer have
| been super helpful with any questions we had.
|
| 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! :)
| irf1 wrote:
| thank you so much Marc!! super excited to have IHP on Algora,
| we love how the project streamlines web development in Haskell
| and helps new developers get started, really appreciate working
| together!
| preya2k wrote:
| I've been looking for something like this forever. Unfortunately
| all existing platforms are extremely shady and deal in
| Crypto/Blockchain. Please stay away from this and focus on what
| you're doing now. I hope you'll be successful with this project!
| irf1 wrote:
| thanks so much for your kind words! really appreciate your
| input here. will stay focused :)
| RobotToaster wrote:
| >Algora charges a 23% fee over your rewarded bounties
|
| 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.
| scrollaway wrote:
| It's far too high. The collectives in OpenCollective
| (https://opencollective.com/) usually charge 5-10%, and they
| take on a LOT of legal and compliance operations on top of the
| billing etc.
|
| 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 :/
| irf1 wrote:
| we're sad to hear you feel this way. not sure OpenCollective
| is an appropriate reference/comparison, but your point is
| duly noted.
|
| 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.
| irf1 wrote:
| if companies try bounties, are satisfied and would like to
| utilize them at a bigger scale, we offer the option to pre-pay
| fees at a discount for a bounties budget of their choice.
|
| 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?
| KomoD wrote:
| Yeah, that's incredibly high.
| candiddevmike wrote:
| A non commercial license would actually disqualify FLOSS
| projects
| Peer_Rich wrote:
| its great to offer bounties to our cal.com community!
| irf1 wrote:
| it's our pleasure to support the cal.com community, thank you
| Peer!!
| alixanderwang wrote:
| Looks great! Giving it a try, posted a $220 bounty:
| https://github.com/terrastruct/d2/issues/921
| irf1 wrote:
| Thank you so much Alex, welcome to Algora!! love the chess
| diagram in the Terrastruct D2 README ;) first Golang open
| source bounty, let's go!
| Atlas22 wrote:
| Great to see some more innovations in this space. What seperates
| it from bountysource or similar?
| AlexITC wrote:
| Congrats on the launch!
|
| 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.
| goldfeld wrote:
| Regarding point #1, I also launched something that is the
| volunteer idea of the OP, or just a journal with weekly themes
| of projects needing help, some AI related. Investing the time
| in this case is simply a volunteering or not decision.
|
| [0]: (emacs week) https://news.ycombinator.com/item?id=35413940
| irf1 wrote:
| fantastic feedback, thank you so much for all your input
| AlexITC!! regarding the potential issues you noted:
|
| 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!
| AlexITC wrote:
| > 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
|
| 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.
| irf1 wrote:
| we will update our docs accordingly about the assignment
| flow, thank you for noting this AlexITC!
|
| 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!
| KomoD wrote:
| I keep reading it as Algolia
| zcesur wrote:
| ha you're not alone. algora comes from the greek word agora
| (community gathering / marketplace) + the word algorithm :)
___________________________________________________________________
(page generated 2023-04-02 23:01 UTC)