The mixture of motivations includes a desire to contribute something to humanity, a desire to make a mark or achieve recognition, or a desire to gain experience that might enhance your ability to get hired.
It can be a hobby like model trains and it can be a a social context like joining a club or going to church.
But it's safe to say that nobody is volunteering "to make billionaires even more profit."
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.
The text and context of the complaint can be used to steelman it, adopting the principle of charity.
From that perspective, the most likely problem is not that bugs are being reported, nor even that patches are not being included with bug reports. The problem is that a shift from human-initiated bug reports to large-scale LLM generation of bug reports by large corporate entities generates a lot more work and changes the value proposition of bug reports for maintainers.
Even if you use LLMs to generate bug reports, you should have a human vet and repro them as real and significant and ensure they are written up for humans accurately and concisely, including all information that would be pertinent to a human. A human can make fairly educated decisions on how to combine and prioritize bug reports, including some degree of triage based on the overall volume of submissions relative to their value. A human can be "trained" to conform to whatever the internal policies or requirements are for reports.
Go ahead and pay someone to do it. If you don't want to pay, then why are you dumping that work on others?
Even after this, managing the new backlog entries and indeed dealing with a significantly larger archive of old bug reports going forward is a significant drag on human labor - bug reports themselves entail labor. Again, the old value proposition was that this was outweighed by the value of the highest-value human-made reports and intangibles of human involvement.
Bug reports are, either implicitly or explicitly, requests to do work. Patches may be part of a solution, but are not necessary. A large corporate entity which is operationally dependent on an open source project and uses automation to file unusually large volumes of bug reports is not filing them to be ignored. It isn't unreasonable to ask them to pay for that work which they are, one way or another, asking to have done.
> Even if you use LLMs to generate bug reports, you should have a human vet and repro them as real and significant and ensure they are written up for humans accurately and concisely, including all information that would be pertinent to a human.
Look at the report that's the center of this controversy. It's detailed, has a clear explanation of the issue at hand, has references and links to the relevant code locations where the submitter believes the issue is and has a minimal reproduction of the issue to both validate the issue and the fix. We can assume the issue is indeed valid and significant as ffmpeg patched it before the 90 day disclosure window. There is certainly nothing about it that screams low effort machine generated report without human review, and at least one commenter in this discussion claims to have inside knowledge that all these reports are written by verified and written by humans before submission to the projects.
I won't pretend that it's a perfect bug report, but I will say if every bug report I got for the rest of my career was of this caliber, I'd be a quite happy with that.
> It isn't unreasonable to ask them to pay for that work which they are, one way or another, asking to have done.
Google quite literally hires some of the ffmpeg maintainers as consultants as attested to by those same maintainer's own website (fflabs.eu). They are very plainly putting cold hard cash directly into the funds of the maintainers for the express purpose of them maintaining and developing ffmpeg. And that's on top of the code their own employees submit with some regularity. As near as I can tell, Google does everything people complaining about this are saying they don't do, and it's still not enough. One has to wonder then what would be enough?
Capitalism is what it is in reality, not just in our fondest hopes.
The problem with the phrase is the assumption that any day now, something else will inevitably come along to replace it and make everything better. That "replacement" has unfortunately proved at least as problematic as the history of capitalism.
You didn't have an unlimited sick policy. You had an undocumented limit. Documenting it lets people know where they stand and protects them in the event they need to take sick time but the boss wants to punish them for it anyway. It also means there's one standard for everyone, rather than people being treated in a discriminatory fashion (you get three weeks, but Samantha gets one).
But isn't this how it always goes? There's an informal policy because writing up every single thing in a contract is tedious for both parties. Then someone comes up and figures "hey, free vacation, I'd be stupid not to take advantage".
So, they do take advantage for a while, until everyone realizes they're a jerk, so now everyone has to go through the new "process". Because they can't just be fired "for taking sick leave", which "is their right".
There's no value in thinking all day about how bananas are delicious. Before you can eat the banana, it has to be produced and shipped. That process does not even involve thinking that bananas are delicious, so that kind of thinking isn't abstracted in the production process, it's simply irrelevant.
I disagree. If you ignore the actual value your product provides to the final consumer "this banana is delicious", you'll come up with solutions that diminish that value. The only reason why blending whole bananas (peel and all), and sending that slop in an unrefrigerated shipping container isn't even considered as an option is an understanding of what the banana-buyers want.
Nobody is proposing ignoring what people will buy. What I said is that literally thinking "this banana is delicious" does not achieve anything toward the actual delivery of any bananas for consumption. It is the end of the production story, not a part of the process, so it is not abstraction to leave it out. Set up a process for sampling batches of bananas if you want, but the value of that isn't for an employee to think "this banana is delicious" 100 times per day. That is confusing consumption with production. There's a good reason why production doesn't include consumption.
If you take the doors off of a small city car to make it quicker to get in and out of at the expense of keeping thieves and the weather out, is that good UX?
I use Linux, and my whole family drives classic cars and kit cars. My father ran a garage at one point.
My point is that what's on /r/unixporn is predominantly gimmicky nonsense, precious little useful ideas. I'm not blinkered to seeing what's style and what's substance.
I must conclude that this is satire, unless you truly see nothing sinister in the notion of sociopathic corporations training humans for drooling obedience in the same way that humans train dogs.
On one hand, there are people who say "flood the zone with shit" and regularly signal boost memes from Stormfront. On the other hand, there are people who think that the New York Times is a newspaper of record and want to fight misinformation. Obviously, there's wrongdoing on both sides here. Instead of fighting Stormfront, why don't we create state-backed committees at community colleges which label populist, right-leaning viewpoints as academic consensus?
It can be a hobby like model trains and it can be a a social context like joining a club or going to church.
But it's safe to say that nobody is volunteering "to make billionaires even more profit."