Forking puts you in another hell as Google. Now you have to pay someone to maintain your fork! Maybe for a project that’s well and fully complete that’s OK. But something like FFmpeg is gonna get updated all the time, as the specs for video codecs are tweaked or released.

Their choice becomes to: - maintain a complex fork, constantly integrating from upstream. - Or pin to some old version and maybe go through a Herculean effort to rebase when something they truly must have merges upstream. - Or genuinely fork it and employ an expert in this highly specific domain to write what will often end up being parallel features and security patches to mainline FFmpeg.

Or, of course, pay someone in doing OSS to fix it in mainline. Which is the beauty of open source; that’s genuinely the least painful option, and also happens to be the one that benefits the community the most.

If you're going to fix the bug, why not in the main project?

Any time I have tried to fix a bug in an open source project I was immediately struck down with abusive attitudes about how I didn't do something exactly the way they wanted it that isn't really documented.

If that's what I have to expect, I'd rather not even interact with them at all.

I don't think this is what typically happens. Many of my bug reports were handled.

For instance, I reported to the xorg-bug tracker that one app behaved oddly when I did --version on it. I was batch-reporting all xorg-applications via a ruby script.

Alan Coopersmith, the elderly hero that he is, fixed this not long after my report. (It was a real bug; granted, a super-small one, but still.)

I could give many more examples here. (I don't remember the exact date but I think I reported this within the last 3 years or so. Unfortunately reporting bugs in xorg-apps is ... a bit archaic. I also stopped reporting bugs to KDE because I hate bugzilla. Github issues spoiled me, they are so easy and convenient to use.)

I feel you, and that's a different issue than the one in this thread, which is in general if maintainers ignore bug reports, their projects will be forked and the issue fixed anyway but not in the main project.

If you really care, I would suggest helping with documenting how the process should work for others to reference going forward.

I would if people were not abusive to me in the first place, but that attitude just turns me off to the entire project.

They undoubtedly already maintain a fork of the project, considering that they have a private compression accelerator that nobody else has access to.

That costs cash and the big tech companies are a little short at the moment.

Probably what they want to do once the original project burns out

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?

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.

I'm very sympathetic to the premise of slop bug reports being harmful. Somehow zero of this thread has info about the slop bug reports though, it's all focused on one specific seemingly completely legitimate CVE issue.