You seem to be reading me as implying any use of FOSS is equivalent to having a support contract; it's not. I was claiming that having a support contract for FOSS is equivalent to having a support contract for proprietary software. If you need "support contract" level support you should probably be paying for a support contract. At least with FOSS that can be competitive for the same piece of software (although that probably also means that some of the services on offer are quite a bit worse, having not had to organizationally have passed the hurdle of "actually making the software" at any point).
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.
I said the issues are different and you disagreed, so I detailed what I meant.
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 said the issues are different and you disagreed
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.