I think the interesting thing here is what I would call the tragedy of overregulation.

Most regulated businesses are big corporations with attached bureaucracies.

When they get a lawsuit because somebody was injured, what will happen is an analysis how this bug could occur.

If it is found that the problem was caused by a library or third party that could get sued, the corporation will sue them and get their money back.

If they find there's no one to sue like with FOSS, they will likely start regulating the use of FOSS.

This has the perverse effect that after a lot of iterations of this cycle the whole toolchain is designed for "sueability" not for quality, performance, or any other worthy goal. Further the toolchain becomes increasingly opaque and proprietary.

Even though the proprietary software has more bugs, and they're harder to find due to their closed source nature, the leaders of Big Corp have covered their asses. The engineers build more workarounds and spend less time improving the quality of Big Corp's code base. The quality of the product suffers. But none of it is the fault of anyone. That's what's important.

You'll be dealing with multiple contributors making changes if you want to upgrade to the latest version, with pull requests from all over the place. Nobody has time to read the entire codebase, so you have to audit and qualify all the random open source contributors instead of just the one group writing the code. You could start with a FLOSS codebase and then just keep any additions/modifications you make proprietary/not ever upgrade, try to fix security patches and things yourself. But that can become difficult, and if you find yourself actually tapping into the benefits of open source to be able to benefit from the collaborative work of thousands of coders, you're stuck having to trust lots of random people again. An old school finance firm could use R or Python, but a lot of them use SAS because you only have to qualify one provider, and if something goes wrong, you can sue them. You dont need to have programmers on staff to evaluate the codebase, you just need programmers that can use SAS. Newer forms and firms in less regulated industries are more comfortable breaking away from these to get the competive advantage of better tools, but it's not for everyone.