It’s also not reasonable to require the government to just get 10,000 support contracts just to implement a single application.
What makes the most sense is what they’re doing here:
1. come up with a strategy for managing these risks
2. Collectively work with OSS developers instead of treating every one of the governments 10 bazillion projects like it needs a separate support contract for a component that is shared
I disagreed that things are all that different "if you have a support contract."
> It’s also not reasonable to require the government to just get 10,000 support contracts just to implement a single application.
I agree, but I'm not sure that's relevant? If a single support contract is sufficient for proprietary software - making them responsible for addressing (incl. possibly working around) issues in any dependency - why is that not also viable for FOSS software?
I don't disagree that what they're doing here seems likely to be a good idea, I just think you were initially selling "pay for support for the software you rely on as a big organization" a little short in its general applicability; indeed, this probably be viewed as providing that service internally.
Finding out that you have a problem when you don't have a support contract and then looking around for someone to work on the thing is not the same thing as having a support contract, although in some cases it can be a sufficient substitute and it's certainly cheaper in the best case (like any other form of skipping insurance).
Depending on context, providing the "support contract" internally is also an option.