When is the last time an OSS programming language that took off actually died? For example, even though it's not as popular Perl 5 is still used professionally in many environments and as far as I know the ecosystem actually went through a sort of renaissance a few years back.
And these days I think it's even easier for OSS ecosystems to achieve critical mass and sustain themselves for decades since communication is easier (a lot more broadband internet in the world) and there's a lot more programmers around. Python, Ruby, PHP & co will probably be around long after I'm dead.
This is certainly a cultural thing. In some organizations (and even the governments of other countries) open source is well regarded and sometimes required. These organizations realize that a strong trusted community around an open source project is usually good enough- especially when you invest in good employees.
Note, some FOSS products also provide a strong support team to handle this exact thing, and in those cases they were usually the winner.
Edit: Looks like abakker posted the same idea simultaneously.
You could say the same about proprietary software, no?
Reliable on call support. Oracle is not going to vanish overnight or de prioritize you due to lack of resources.
The possibility of that risk in other firms is sufficient to make them non options
You want support for sure but big companies are hit and miss on support quality.
Consulting mailing lists and IRC for a DIY solution is not an acceptable solution for most enterprise users. Moreover, there's nobody to sue if something goes wrong.
Red Hat was formed to fill that gap, but so far it has had only modest success. Companies like IBM, HPE, and Oracle exist because they are perceived as stable, likely to be able to support their technology over the long term.
For example, mainframes and COBOL are largely long dead technologies, but banks that bought mainframes running COBOL from IBM in the 1970s are still very much getting active commercial-grade support for those technologies from IBM today.
Again, for innovative new projects, this is changing.
Years ago, I worked on a project that used Oracle's BPM product. It was the only time I've worked on something where the team had a direct line to vendor support. When we had issues, all they ever seemed to do was ask for more logs, over and over again. I think they were hoping we'd give up and close our SRs.
Luckily, I got off that project pretty quick. I later learned that they 1) rewrote their BPM product and did not offer a clear upgrade path to the new version, and 2) planned to end support for the old version in a few years.
As a developer, the promise of vendor support doesn't ease my mind very much.
I agree with another commenter that in the long run, it'll end up as OSS + support from a 3rd party consultant or vendor that is commercially aligned with your success.
It has taken a very long time to convince most IT to behave like a branch of business that can create new value. Once that shift happens fully, we'll see the "keep the lights on at all costs" mindset change a bit in favor of truly measuring ROI and true total cost of ownership. For most large companies this has never been done.
The risk mitigation factor from large vendors comes not from performance but from reliability. You can trust that old mainframe code will continue to be supported for many years. You can trust that your COBOL workload will be continue to run, and that the 20 years of updates, patches, and tweaks have made it reliable and predictable in a way that precludes rip and replace in all but the most extenuating circumstances.
IT budgets tend to be governed by an 80/20 rule - maintenance vs innovation. Sometimes, its more of a 95/5 in practicality due to shrinking budgets. My experience says that the innovation side is drastically shifting away from these big vendors, but that the maintenance side has a lot more riding on it still.