FFmpeg to Google: Fund us or stop sending bugs

Thus, as Mark Atwood, an open source policy expert, pointed out on Twitter, he had to keep telling Amazon to not do things that would mess up FFmpeg because, he had to keep explaining to his bosses that “They are not a vendor, there is no NDA, we have no leverage, your VP has refused to help fund them, and they could kill three major product lines tomorrow with an email. So, stop, and listen to me … ”

I agree with the headline here. If Google can pay someone to find bugs, they can pay someone to fix them. How many time have managers said "Don't come to me with problems, come with solutions"

The "kill it with an email" probably means that whoever said this is afraid that some usecase there wouldn't stand up to an audit by the usual patent troll mothercluckers. The patents surrounding video are so complex, old and plentiful that I'd assume full compliance is outright impossible.

The API manual for it is nearly 4000 pages and it can do insane stuff[1].

I had to use it at last job(TM), it's not terrible API wise.

[1] https://docs.aws.amazon.com/pdfs/mediaconvert/latest/apirefe... CAUTION: big PDF.

I interpret this as meaning there was an implied "if you screw this up" at the end of "they could kill three major product lines with an email."

It might not make sense morally, but it makes total sense from a business perspective… if they are going to pay for the development, they are going to want to maintain control.

As it stands, they're just abusing someone's gift.

Like jerks.

The problem is, the issue in the article is explicitly named as "CVE slop", so if the patch is of the same quality, it might require quite some work anyway.

Why? - It makes continued downstream consumption easier, you don't have to rely on fragile secret patches. - It gives back to projects that helped you to begin with, it's a simple form of paying it forward. - It all around seems like the "ethical" and "correct" thing to do.

Unfortunately, in my experience, there's often a lot of barriers within companies to upstream. Reasons can be everything from compliance, processes, you name it... It's unfortunate.

I have a very distinct recollection of talks about hardware aspirations and upstreaming software fixes at a large company. The cultural response was jarring.

In fact, we are probably just really lucky that some early programmers were kooky believers in the free software philosophy. Thank God for them. So much of what I do owes to the resulting ecosystem that was built back then.

But it's also a bug report about the decoder for "SANM ANIM v0" - a format so obscure almost all the search results are the bug report itself. Possibly a format exclusive to mid-1990s LucasArts games [1]

Pretty crazy that ffmpeg supports the codec in the first place, IMHO.

I can understand volunteers not wanting to sink time into maintaining a codec to play a video format that hasn't been used since the Clinton administration. gstreamer divides their plugins into 'good', 'bad' and 'ugly' to give them somewhere to stash unmaintained codecs.

[1] https://web.archive.org/web/20250419105551/https://wiki.mult...

The format being obscure and having no real usage doesn't help when it's the attackers creating the files. The obscure formats are exposing just as much attack surface as the common ones.

> Pretty crazy that ffmpeg supports the codec in the first place, IMHO.

Yes.

> We realized it was time to dump the confrontational attitude that has been associated with "free software" in the past and sell the idea strictly on the same pragmatic, business-case grounds that motivated Netscape.

https://web.archive.org/web/20021001164015/http://www.openso...

The entire point here is to pay for the fixes/features you keep demanding, else the project is just going to do as it desires and ignore you.

More and more OSS projects are getting to this point as large enterprises (especially in the SaaS/PaaS spheres) continue to take advantage of those projects and treat them like unpaid workers.

Certainly easier to give a good bug report and let upstream write the change, if they will.

It's enough if one or two main contributors assert their copyrights. Their contributions are so tangled with everything else after years of development that it can't meaningfully be separated away.

Edit: And also, how is anyone supposed to know they should compile the codec our unless someone makes a bug report and makes it public in the first place?

No, it didn't help giving them copies of licenses that have the usual liability clauses.

It seems a lot of corporate lawyers fundamentally misunderstand open source.

The only reason for needing control would be if it was part of their secret sauce and at that point they can fork it and fuck off.

These companies should be heavily shamed for leaching off the goodwill of the OSS community.

Sorry, that's ridiculous. Basically every major free software dependency of every major platform or application is maintained by people on the payroll of one or another tech giant (edit: or an entity like LF or Linaro funded by the giants, or in a smaller handful of cases a foundation like the FSF with reasonably deep industry funding). Some are better than others, sure. Most should probably be doing more. FFMpeg in particular is a project that hasn't had a lot of love from platform vendors (most of whom really don't care about software codecs or legacy formats anymore), and that's surely a sore point.

But to pretend that SteamOS is the only project working with upstreams is just laughable.

For instance, here's one for the Amazon Music apps, which includes an FFMpeg license: https://www.amazon.com/gp/help/customer/display.html?nodeId=...

Nobody who takes security even remotely seriously should decode untrusted media files outside of a sandboxed environment. Modern media formats are in themselves so complex one starts wondering if they're actually Turing complete, and in ffmpeg the attack surface is effectively infinitely large.

The issue is CVE slop because it just doesn't matter if you consider the big picture.

Some example issues to illustrate my point:

https://issuetracker.google.com/issues/436511754 https://issuetracker.google.com/issues/445394503 https://issuetracker.google.com/issues/436510316 https://issuetracker.google.com/issues/433502298

I don't understand how anyone believes that behavior is acceptable.

This is software that is directly or indirectly run by millions of people on untrusted media files without sandboxing. It's not even that they don't care about security, it's that they're unaware that they should care. It should go without saying that they don't deserve to be hacked just because of that. Big companies doing tons of engineering work to add defense in depth for use cases on their own infrastructure (via sandboxing or disabling obsolete codecs) doesn't help those users. Finding and fixing the vulnerabilities does.

But no. Intentionally or not, there was a whole drama created around it [1], with folks being criticized [2] for saying exactly what you said above, because their past (!) employers.

Instead of using the situation to highlight the need for more corporate funding for opensource projects in general, it became a public s**storm, with developers questioning their future contributions to projects. Shameful.

[1] https://news.ycombinator.com/item?id=45806269

[2] https://x.com/FFmpeg/status/1985334445357051931

Valve does seem somewhat rare position of making a proper Linux distro work well with games. Google’s Chromebooks don’t contribute to the linux ecosystem in the same holistic fashion it seems.

Again, Google has been doing this sort of thing for over a decade and has found untold thousands of vulnerabilities like this one. It is not at all clear to me that their doing so has been all that valuable.

Yes, I've also worked on OpenStack components at a university, and there I see Red Hat or IBM employees pushing up loads of changes. I don't know if I've ever seen a Walmart, UnitedHealth, Chase Bank, or Exxon Mobil (to pick some of the largest companies) email address push changes.

It's a dumb reason, especially when there are CVE bugs like this one, but that's how executives think.

Feel free to read lore.kernel.org, and sort out where the people contributing many patches actually work.

https://sfconservancy.org/copyleft-compliance/vizio.html

https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...

https://github.com/walmartlabs

https://github.com/Optum

https://github.com/jpmorganchase

So the premise here is that AWS should waste their own money maintaining an internal fork in order to try to make their competitors do the same thing? But then Google or Intel or someone just fixes it a bit later and wisely upstreams it so they can pay less than you by not maintaining an internal fork. Meanwhile you're still paying the money even though the public version has the fix because now you either need to keep maintaining your incompatible fork or pay again to switch back off of it. So what you've done is buy yourself a competitive disadvantage.

> that's how executives think.

That's how cargo cult executives think.

Just because you've seen someone else doing something doesn't mean you should do it. They might not be smarter than you.

I think Stallmann's ideological "allowing users to run, modify, and share the software without restrictions" stance is good, but I think for me at least that should apply to "users" as human persons, and doesn't necessarily apply to "corporate personhood" and other non-human "users". I don't see a good way to make that distinction work in practice, but I think it's something that if going to become more and more problematic as time goes on, and LLM slop contributions and bug reports somehow feed into this too.

I was watching MongoDB and Redis Labs experiments with non-OSF approved licences clearly targeted at AWS "abusing" those projects, but sadly neither of those cases seemed to work out in the long term. Also sadly, I do not have any suggestions of how to help...

That's a pretty good indicator it's likely just ffmpeg in an AWS Hoodie/Trenchcoat.

The ffmpeg project need to get in touch and get then to assign copyright to the ffmpeg project, then delete that format/decoder from ffmpeg. Then go back to Google with an offer to licence then a commercial version of ffmpeg with the fixed SANM ANIM v0 decoder, for the low low price of only 0.0001% of YouTube's revenue every year. That'd likely make them the best funded open source project ever, if they pulled it off.

If you're an unpaid volunteer? Yeah - nah. They can tell you "Sorry, I'm playing with my cat for the next 3 months, maybe I'll get to it after that?", or just "Fuck off, I don't care."

(I'm now playing out a revenge fantasy in my head where the ffmpeg team does nothing, and Facebook or Palantir or someone similar get _deeply_ hacked via the exploit Google published and theat starts the planets biggest ever pointless lawyers-chasing-the-deepest-pockets fight.)

I’ve been at several companies where upstreaming was encouraged for everything. The fewer internal forks we could maintain, the better.

What surprised me was how many obstacles we’d run into in some of the upstream projects. The amount of time we lost to trying to appease a few maintainers who were never happy with code unless they wrote it themselves was mind boggling.

For some projects you can basically forget about upstreaming anything other than an obvious and urgent bug fix because the barriers can be so high.

Is that somehow _less_ of a terrible way to think than "someone who's contributed their time as a volunteer to an open source software project that we have come to rely on, now has some sort of an obligation to drop everything and do more unpaid work for a trillion dollar company"?

> it really needs to be fixed in the up stream

Lots of people love using "Free Software" that they didn't have to write as essential parts of their business.

Way too many of them seem to blink right when they get to this bit of the licence they got it with:

SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

(That's directly from Section 15 "NO WARRANTY of https://code.ffmpeg.org/FFmpeg/FFmpeg/src/branch/release/4.0... )

Yeah. It's called YouTube... Why run fuzzers if you can get people to upload a few million random videos every day? ;-)

(I wonder if the BigSleep AI was trained on or prompted with YouTube error logs?)

  > If you used the scan to pdf functionality of a [Xerox] like this a decade ago, your PDF likely had a JBIG2 stream in it.

  > decoding LucasArts Smush codec, specifically the first 10-20 frames of Rebel Assault 2, a game from 1995.

Your point is still taken, but just to clarify that these are different situations. JBIG2 is included for legacy. The Lucas art codec is included for... completion's sake(?)

But given its license, they’re going to have to reveal those changes anyways (since many of the most common codecs trigger the GPL over LGPL clause of the license) or rewrite a significant chunk of the library.

True. In my case I literally had to fight for it. Our lawyers were worried about a weakened patent portfolio and whatnot. In my case at least I won and now we have a culture of upstreaming changes. So don't give up the fight, you might win.

This is the same tortured logic as Citizens United and Santa Clara Co vs Southern Pacific Railroad, but applied to FS freedoms instead of corporate personhood and the 1st Amendment.

I like the FS' freedoms, but I favor economic justice more, and existing FS licenses don't support that well in the 21st c. This is why we get articles like this every month about deep-pocketed corporate free riders.

I believe in FOSS and can make an argument that lots of people on HN will accept, but many outside this context will not understand it or care.

I don't even have to link the xkcd comic because everyone already knows which one goes here.

    git clone https://git.ffmpeg.org/ffmpeg.git
    cd ffmpeg
    git log --pretty=format:"%ae" | grep -E "chromium\\.org|google\\.com" | wc -l

As a side note YC and tech startups themselves have become reality TV. Your goal should be Valve! You should be Gabe Newell! You don’t need to be famous! Just build something valuable and be patient

Open source software is critical infrastructure at this point. Maintainers should be helped out, at least by their largest users. If free riding continues, and maintainers' burden becomes too large, supply chain attacks are bound to happen.

If you could highlight the relevant part of the bug report that demanded the developers "drop everything" and do "unpaid work for a trillion dollar company", that would be great because I'm having trouble finding it. I see "hey, we found this bug, we found where we think the issue is in the code and here's a minimal reproduction. Also FYI we've sent you this bug report privately, but we will also be filing a public bug report after 90 days." And no, I don't think having a policy of doing a private bug report followed by a public report some time later qualifies as a demand. They could have just made a public report from the get go. They could also have made a private report and then surprised them with a public bug report some arbitrary amount of time later. Giving someone a private heads up before filing a public bug report is a courtesy, not a demand.

And it's really funny to complain about Google expecting "unpaid work for a trillion dollar company", when the maintainers proudly proclaim that the likes of no less than Google ARE paying them for consulting work on ffmpeg[1][2][3]

[1]: https://fflabs.eu [2]: https://fflabs.eu/about/ [3]: https://ffmpeg.org/consulting.html

In the now deleted tweet Theo thrashed VLC codecs to which ffmpeg replied basically "send patches, but you wouldn't be able to". The reply to which was

--- start quote ---

https://x.com/theo/status/1952441894023389357

You clearly have no idea how much of my history was in ffmpeg. I built a ton of early twitch infra on top of yall.

--- end quote ---

This culminated in Theo offering a 20k bounty to ffmpeg if they remove the people running ffmpeg twitter account. Which prompted a lot of heated discussion.

So when Google Project Zero posted their bug... ffmpeg went understandably ballistic

Any patch sent in also needs to be maintained into the future, and most of the time it's the maintainers that need to do that, not the people contributing the patch. Therefore any feature-patches (as opposed to simple bugfixes) are quite often refused, even if they add useful functionality, because the maintainers conclude they will not be able to maintain the functionality into the future (because no one on the maintaining team has experience in a certain field, for example).

The quality bar for a 'drive by patch' which is contributed without the promise of future support is ridiculously high and it has to be. Other peoples' code is always harder to maintain than your own so it has to make up for that in quality.

Several software engineers left, several didn't sign it.

Yes, company was very toxic apart of that. Yeah, I should name and shame but I won't be doxxing myself.

It's not entirely unlike if someone said "the only person I know writing books successfully is Brandon Sanderson." I do think "you ought to go check out your local book store" would be a valid response.

1) Fix it yourself

2) Sit on it silently until the maintainers finally get some time to fix it

That seems crazy to me. For one, not everyone who discovers a bug can fix it themselves. But also a patch doesn't fix it until it's merged. If filing a public bug report is expecting the maintainers to "drop everything and do free labor" then certainly dropping an unexpected PR with new code that makes heretofore unseen changes to a claimed security vulnerability must surely be a much stronger demand that the maintainers "drop everything" and do the "free labor" of validating the bug, validating the patch, merging the patch etc etc etc. So if the maintainers don't have time to patch a bug from a highly detailed bug report, they probably don't have time to review an unexpected patch for the same. So then what? Does people sit on that bug silently until someone finally gets around to having the time to review the PR. Or are they allowed to go public with the PR even though that's far more clearly a "demand to drop everything and come fix the issue NOW".

I for one am quite happy the guy who found the XZ backdoor went public before a fix was in place. And if tomorrow someone discovers that all Debian 13 releases have a vulnerable SSH installation that allows root logins with the password `12345`, I frankly don't give a damn how overworked the SSH or Debian maintainers are, I want them to go public with that information too so the rest of us can shut off our Debian servers.

In this particular case it’s hardly obvious which patch you should submit. You could fix this particular bug (and leave in place the horrible clunky codec that nobody ever uses) OR you could just submit a patch that puts it behind a compile flag. This is really a decision for the maintainers, and submitting the latter (much better!) patch would not save the maintainers any meaningful amount of time anyway.

A tech company I worked at once had a "sponsorship fund" to "sponsor causes" that employees wanted, it was actually good money but a drop in the bucket for a company. A lot of employees voted for sponsoring Vue.js, which is what we used. Eventually, after months of silence, legal/finance decided it was too much work.

But hey it wasn't an exception. The local animal shelter was the second most voted and legal/finance also couldn't figure it out how to donate.

In the end the money went to nowhere.

The only "developer marketing" they were doing was sending me in my free time to do panels with other developers in local universities and conferences. Of course it was unpaid, but in return I used it to get another job.

Will you be still making a fuss over it?

Maybe the developer intends to some day change the internal implementation, such that that particular boolean flag wouldn't make sense any more. Or they're considering taking out the option entirely, and thus simplifying the codebase by making it so it only works one way.

Maybe the developer just doesn't care about your use case. If I have a project that works fine for what I do with it, why should I also care about some other use case you have for my work? I'm not your employee. Your product doesn't put a roof over my head.

I don't want a job where I do free work, for a bunch of companies who all make money off my work. That's a bad deal. Its a bad deal even if my code gets better as a result. I have 150 projects on github. I don't want to be punished if any of those projects become popular.

We can't go around punishing projects like ffmpeg or ruby on rails for the crime of being useful.

I'm not sure what you think you mean when you say "running AIs indiscriminately". It's quite expensive to run AI this way, so it needs to be done with very careful consideration.

Like, here's the deal: The work is proper, legit opensource. You can use it for free, with no obligations.

But if your company makes a profit from it, you're expected to either donate money to the project or contribute code back in kind. (Eg security patches, bug fixes, or contribute your own opensource projects to the ecosystem, etc).

If you don't, all issues you raise and PRs get tagged with a special "moocher" status. They're automatically - by default - ignored or put in a low priority bin. If your employees attend any events, or join a community discord or anything like that, you get a "moocher" badge, so everyone can see that you're a parasite or you work for parasites. Thats ok; opensource licenses explicitly allow parasites. I'm sure you're a nice person. But we don't really welcome parasites in our social spaces, or allow parasites to take up extra time from the developers.

I still had to upstream anonymously, though.

The company that I work at makes sure anything that uses third-party library, whether in internal tools/shipped product/hosted product, goes through legal review. And you'd better comply with whatever the legal team asks you to do. Unless you and everyone around you are as dumb as a potato, you are not going to do things that blatantly violates licenses, like shipping a binary with modified but undisclosed GPL source code. And you can be sure that (1) it's hard to use anything GPL or LGPL in the first place (2) even if you are allowed to, someone will tell you to be extra careful and exactly do what you are told to (or not to)

And as long as Amazon is complying with ffmpeg's LGPL license, ffmpeg can't just stop licensing existing code via an email. Of course, unless there is some secret deal, but again, in that case, someone in the giant corporation will make sure you follow what's in the contract.

Basically, at company at Amazon where there are functional legal teams, the chance of someone "screwing up" is very small.

There are many reasons, often good ones, not to pay money for an open source project but instead fund your own projects, from a company's perspective.

That seems to imply that Apple employees are prohibited from being good internet citizens and e.g. helping people out with any kind of software issue. This presumably includes contributing to open source, although I'm sure they can get approval for that. But the fact they have to get approval for it is already a chilling effect.

I can usually stop short of providing code and file a bug that explains the replication case and how to fix it. I've taken patches and upstreamed them pseudonymously on my own time when the employer believed the GPL meant they couldn't own the modifications.

If after all that you still want to label me a moocher at cons, that's your choice.

There's no penalty clause, there's no recovery clause. If you don't comply with the licence conditions then you don't have a licence. If you don't have a licence then you can't use the program, any version of the program. And if your products depend on that program then you lose your products.

The theoretical email would be a notification that they had breached the licence and could no longer use the software. The obvious implication being that AWS was wanting to do something that went contrary to the restrictions in the GPL, and he was trying to convince them not to.

The pattern I have seen is that if you want to contribute a fix into a project, you are expected to "engage with the community", wear their badge, invest into the whole thing. I don't want to be in your community, I want to fix a bug in a thing I'm using and go on with my life.

Given the usual dynamics of online communities which are getting somehow increasingly more prone to dramas, toxicity, tribalism, and polarization, I just as increasingly want to have no part in them most of the time.

I think many projects would be better for having a lane for drive-by contributors who could work on fixing bugs that prevent their day-to-day from working without expectations of becoming full-time engaged. The project could set an expectation that "we will rewrite your patch as we see fit so we could integrate and maintain it, if we need/want to". I wouldn't care as long as the problem is taken care of in some way.

Then say you don't expect contributions at all. That's a fair game, I'm ok with it. I will then exercise my rights granted by your license in another way (forking and making my own fix most likely). My gripe is with projects that write prominently "PRs welcome", and then make enough red tape to signal that nah, not really.

You could also just pay for it.

The work to upstream our changes was included in the Statements of Work which Walmart signed off on, and our time spent on those efforts was billed to them.

The stats for those projects will have recorded my former employer as the direct source of those contributions - but they wouldn't have existed had it not been for Walmart.

It used to be normal to build a business slowly over 20 years. Now everyone grabs for the venture capital, grows so fast they almost burst, and the venture capital inevitably ends in enshittification as companies are forced by shareholders to go against their business model and shit over their customers in order to generate exponential profit margins.

I was playing Fallout 3 on WINE well before Valve got involved with minimal tweaks or DIY effort.

Proton with Steam works flawlessly for most things including AAA games like RDR2 and it's great, but don't forget that WINE was out there making it work for a while

GabeN was also a MS developer back in the day and likely would have been well off regardless, but he didn't need to play the YC A-B-let's-shoehorn-AI bullshit games that are 100% de rigeour for all startups in 2025.

Windows support had gotten a boost from .NET going open source as well as other stuff MS began to relax about. It also helped that OpenGL was put to rest and there was a new graphics API that could reasonably emulate DirectX. I don't know much about the backstory of Mesa, but it's pretty cool tech that has been developing for a long time.

Yes, but Valve's involvement handled "the last 10% takes the 90% of the time" part of WINE, and that's a great impact, IMHO.

Trivia: I remember WINE guys laughing at WMF cursor exploit, then finding the exploit works on WINE too and fix it in panic, and then bragging bug-for-bug compatibility with Windows. It was hilarious.

Also, WINE allowed Linux systems to be carrier for Windows USB flash drive virii without being affected by them for many years.

Some simple setting expose like you describe can sometimes go in without a fuss or it can stall, that depends on a lot of factors. Like the other reply states: it could go against future plans. Or it could be difficult for the maintainer to see the ramifications of a simple looking change. It sucks that it is that way (I have sent in a few patches for obscure CUPS bugs which have stayed in limbo, so I know the feeling ;-) ) but it is hardly surprising. From a project's point of view drive-by patches very often cost more than they add so to get something included you often need to do a very thorough writeup as for why something is a good idea.

> I just as increasingly want to have no part in them most of the time. If all people you meet are assholes.... ;-P Not to say you are an asshole, or at least not more than most people, but I have been in this situation myself more than once, and it really pays to stay (overly) polite and not let your annoyance about being brushed off slip through the mask. The text-only nature of these kind of communications are very sensitive to misinterpretations and annoyances.

It would be nice if all you'd need for a patch to be included somewhere was for it to be useful. But alas there's a certain amount of social engineering needed as well. And imho this has always been the case. If you feel it gets increasingly hostile that's probably your own developer burnout speaking (by do I know that one :-P )

Ultimately there will always be some healthcare rationing. This happens in every country. For example, the UK NHS has death panels which decide that certain treatments won't be covered at all because they're not cost effective. Resources are limited and demand is effectively infinite. So the only real question is how we do the rationing.

It may be the case that ffmpeg cannot reasonably support every format while maintaining the same level of security. In that case, it makes sense for distros to disable some formats by default. I still think it’s great that they’re supported by the ffmpeg project.

I agree there would probably need to be some unified guidance about which formats to enable.

If the format is old and obscure, and the implementation is broken, it shouldn't be on by default.

You can say publicly that “there is an ABC class vulnerability in XYZ component” so that users are aware of the risk.

I sympathize and understand those issues for small companies, but after a certain size those excuses stop being convincing.

Especially for a software company like Google who runs dozens of open source projects, employs an army of lawyers to monitor compliance, and surely has to deal with those issues on a daily basis anyway.

At some point there needs to be pushback. Companies get a huge amount of value from hobbiest open source projects, and eventually they need to start helping out or be told to go away.

None of us want the economy to be hurt, right?

Even if Wine was 90% there technologically, the most important 90% is really that last 10.

This also informs users that it’s not safe to use ffmpeg or software derived from it to open untrusted files, and perhaps most importantly releasing this tells the distro package maintainers to disable the particular codec when packaging.

Basically I got to do the work on company time&dime, but I couldn't give my employer credit, due to this kind of legal red tape.

I liked that teamlead

That brings us full circle to the topic because one important thing that gets people motivated into accepting other people's changes to their code is being paid.

If you work in FOSS side projects as well as a proprietary day job, you know it: you accept changes at work that you wouldn't in those side projects.

In the first place, you write the code in ways you wouldn't due to conventions you disagree with, in some crap language you wouldn't use voluntarily, and so it geos.

People working on their own FOSS project want everything their way, because that's one of the benefits of working on your own FOSS project.

The first is that you have a shared finite resource, the classic example being a field for grazing which can only support so many cattle. Everyone then has the incentive to graze their cattle there and over-graze the field until it's a barren cloud of dust because you might as well get what you can before it's gone. But that doesn't apply to software because it's not a finite resource. "He who lights his taper at mine, receives light without darkening me."

The second is that you're trying to produce an infinite resource, and then everybody wants somebody else to do it. This is the one that nominally applies to software, but only if you weren't already doing it for yourself! If you can justify the effort based only on your own usage then you don't lose anything by letting everyone else use it, and moreover you have something to gain, both because it builds goodwill and encourages reciprocity, and because most software has a network effect so you're better off if other people are using the same version you are. It also makes it so the effort you have to justify is only making some incremental improvement(s) to existing code instead of having to start from scratch or perpetually pay the ongoing maintenance costs of a private fork.

This is especially true if your company's business involves interacting with anything that even vaguely resembles a consolidated market, e.g. if your business is selling or leasing any kind of hardware. Because then you're in "Commoditize Your Complement" territory where you want the software to be a zero-margin fungible commodity instead of a consolidated market and you'd otherwise have a proprietary software company like Microsoft or Oracle extracting fees from you or competing with your hardware offering for the customer's finite total spend.

But old AND obscure, well it's nice that it is supported but enabled by default? Fully with you there.

Sounds like they'll just throw their employees to work on it rather than monetarily fund it, that way they can aura farm.

The can, but there's not an obvious reason why they should. If anything, public disclosure timelines for commercial closed source projects should be much much longer than for contributor-driven projects because once a bug is public ANYONE can fix it in the contributor-driven project, where as for a commercial project, you're entirely at the mercy of the commercial entities timelines.

> Also, if Google has the funds to pay for bug finding, they also have the funds for bug fixing the community projects they depend on.

They do. And they do. They literally higher the ffmpeg maintainers via the maintainer's consulting business (fflabs.eu) and they routinely contribute code to the ffmpeg project.