←back to thread

1124 points CrankyBear | 1 comments | | HN request time: 0.227s | source
Show context
ranger_danger ◴[] No.45891460[source]
Wouldn't they just fork it, fix their own bugs and stop contributing at all?
replies(6): >>45891483 #>>45891531 #>>45891743 #>>45892105 #>>45892143 #>>45892666 #
blibble ◴[] No.45891483[source]
Google internally maintaining a fork that attempts to track upstream has a ongoing cost that increases over time

vs. spamming OSS maintainers with slop reports costs Google nothing

replies(1): >>45892349 #
esrauch ◴[] No.45892349[source]
Is there really slop here though? It sounds like the specific case identified was a real use after free in an obscure file format but which is enabled by default.

If it was slop they could complain that it was wasting their time on false or unimportant reports, instead they seem to be complaining that the program reported a legitimate security issue?

replies(1): >>45902715 #
1. kastagg ◴[] No.45902715[source]
If a maintainer complains about slop bug reports, instead of assuming the worst of the maintainer, it'll often be more productive to put yourself in their shoes and consider the context. An individual case may simply be the nth case in a larger picture (say, the straw that broke the camel's back). Whenever this nth case is observed, if you only consider that single case, a response also informed by detailed personal consideration of the preceding (n-1) cases may appear grossly and irrationally disproportionate, especially when the observer isn't personally that involved.

For a human, generating bug reports requires a little labor with a human in the loop, which imposes a natural rate limit on how many reports are submitted, which also imposes a natural triaging of whether it's personally worth it to report the bug. It could be worth it if you're prosocially interested in the project or if your operations depend on it enough that you are willing to pay a little to help it along.

For a large company which is using LLMs to automatically generate bug reports, the cost is much lower (indeed it may be longer-term profitable from a standpoint like marketing, finding product niches, refining models, etc.) This can be asymmetric with the maintainer's perspective, where the quality and volume of reports matter in affecting maintainer throughput and quality of life.