Comment by TrainedMonkey

Comment by TrainedMonkey 6 hours ago

3 replies

For many large companies or even teams, there exists a class of bugs / issues / features where dropping 5-10k on a bounty is extremely cost efficient compared to working around the issue or internal development. That might not fund development outright, but at worst it would point out the features people want and serve to inform what to work on next. I think there are a couple reasons why that is not prevalent. Most important one is that highly compensated enterprise teams that would benefit the most from placing bounties tend to avoid software that is lacking features or has bugs. Secondary is not implemented here ego and general disconnect between people in the trenches that know what needs to be done and people controlling ability to place bounties.

Imagine FAANG assigning $500 per engineer per year to allocate to feature / bug bounties.

jaredklewis an hour ago

I’m confused.

Bounties for security holes make sense because you don’t need to submit the patch, just find the hole.

And bounties for open source (like in this case) also make sense because you have everything you need to submit a patch.

But for everything else (like almost big tech software, startups, and so on) bounties can’t fix bugs because even if I find a bug, how am I going to patch it without access to the source code?

IME your average SV startup has a long list of bugs they are aware of, but just haven’t gotten around to fixing because other priorities are in the way. And people can’t help patch unless you have an open development process.

Am I missing something?

zozbot234 5 hours ago

Most larger companies would probably find it way easier and more sensible to contract with some outside consultancy to work on these issues than just posting a random bounty, even if the latter might potentially be cheaper. See Google Summer of Code projects for a very practical example of how "just pay randos to work on issue X for cheap" can quite often end up in failure.

  • Avamander an hour ago

    > See Google Summer of Code projects for a very practical example of how "just pay randos to work on issue X for cheap" can quite often end up in failure.

    That potential for failure is there for any "subcontractors". I wonder if anyone has any stats on this.