In the past ten years I have been working in multiple companies that have had businesses based on open source software. Very often these businesses not only used open source software, but also substantially modified it in order to adjust it to the needs of the enterprise, to make it scale or simply to fix bugs in code that otherwise has been rarely exercised.
In effect, this created a fork of the software, internally inside the enterprise.
These changes can be maintained inside the company, binding company ressources, or they can be put back upstream. Code can be part of what differentiates you from other companies, or it can be code that does stuff you do which others do as well - then it is infrastructure code to you. All infrastructure code inside your company you should share as open source quickly and reliably, because that not only improves the code but also shares your cost with others.
Very often companies do not do that - instead they are maintaining their fork of code internally, failing to integrate changes from the outside into their own fork, and binding valueable development ressources inside the enterprise in reproducing changes from the outside indepently. The reason for that is usually that there is an intellectual property regime which requires clearance of code before it can leave the company, but insufficient staffing for the actual clearance process.
As the enterprise slowly accumulates and integrates more and more open source projects to maintain their business they are slowly dragged down if they do not manage the process of giving changes back upstream properly.