If your company is paying you to work on Product X and Product X depends on Open Source Library Y, Open Source Library Y's bugs are Product X's bugs. Open Source Library Y's features are often productivity enhancements that make Product X better. Your company is paying you to work around Open Source Library Y's defects and use Open Source Library Y's productivity enhancements, no matter what. Sometimes the fastest way to work around Library Y's defects is to fix them yourself and sometimes the best way to get more productivity out of tools like Library Y is to contribute Library Y features yourself.
Because your company may see Open Source Library Y as free as in beer they may not value the vendor relationship with Open Source Library Y. The "cultural" Maintenance Agreement with Open Source "vendors" is that good open source users contribute back to open source those bug fixes they need for workarounds and those features they request for productivity benefits. Compared to the costs of Maintenance Agreements with many large, classic closed source vendors, the cost of a few hours labor on dependencies to products is often quite cheap relatively speaking especially with the "free as in beer" platform/networking effect that other "good" companies following cultural Maintenance Agreement norms contribute as well.
The only real missing ingredient is that because that Maintenance Agreement is cultural more than it is written down in a way that Corporate Lawyers can read it and Actuaries and CPAs can understand it to be an asset and/or liability that impacts the books, it just becomes invisible guilt: either the guilt that you aren't doing your part as a developer with respect to that culturally assumed Maintenance Agreement OR the guilt that you are doing your part but that your company may find out and claim you are wasting their time. But seriously, that vendor relationship even though most of the "assets" are "free as in beer" should be on the books and have its own billing codes for the culturally encouraged "liabilities" of Maintenance Agreements to spend a few hours of developer time here or there for the "greater good", but also the specific good of "making Product X better" because that is an asset directly related to the performance and success of "Product X".
I think it is still related and relevant, though I did forget to address it, sorry.
Expanding out further from where I left off:
The "compact" of that cultural Maintenance Agreement further relies on network effects that make it powerful (and cheap as free as in beer as an asset): it isn't assumed that everyone can fix/build every bit of open source, it relies on community effects. It relies on a lot of individuals scratching their own itches becoming a collective force greater than the sum of its parts.
Absolutely, Accounting for that is even harder. It's not a "quid pro quo" that you can directly bill to a specific product. That's even harder for companies to deal with. But plenty of companies have much more complex classic liabilities than that: Marketing efforts, R&D, etc. Again, the "wastefulness" in budgeting for "Open Source Maintenance" both specific and general is a super cheap deal compared to classic R&D budgeting. It's a huge savings compared to classic third party software vendors on a combined "asset portfolio" basic. Companies can budget for it. They can and likely should assume some of that "wastage" on "maintenance costs" as natural overhead of building software. (That's what the cultural narrative of Open Source encourages: that everyone should chip in and assume at least some baseline of community effort, from every user [personal, corporate, whatever].)
Bringing things back even more full circle: my company tries to have somewhat regular Community Service Days to give back to the communities the company exists in (and professionally serves day to day). It budgets labor hours towards those efforts (and also promotional budgets for things like t-shirts to pat itself on the back), people sign up to meet those budgets, and things like "helping a homeless shelter" are direct uses of that budgeted time that the company is paying for. My company isn't alone in this practice, and expanding it to charitable "Match" contributions there are a lot of companies paying regular money and/or labor to "general good" charities.
Admittedly, part of those budgets every year come from charitable organization "vendor requests" asking for specific numbers of hours (in many cases) and from Accounting knowing that working with any 501(c)3 makes those hours spent a write-off liability come tax time. That's again where the "cultural" part of Open Source "obligations" meets the practical side that there aren't enough 501(c)3 charitable organization "vendors" to "invoice" companies and also help make the time/labor spent on such "invoices" to be even cheaper than usual labor costs thanks to tax write-offs.
Because your company may see Open Source Library Y as free as in beer they may not value the vendor relationship with Open Source Library Y. The "cultural" Maintenance Agreement with Open Source "vendors" is that good open source users contribute back to open source those bug fixes they need for workarounds and those features they request for productivity benefits. Compared to the costs of Maintenance Agreements with many large, classic closed source vendors, the cost of a few hours labor on dependencies to products is often quite cheap relatively speaking especially with the "free as in beer" platform/networking effect that other "good" companies following cultural Maintenance Agreement norms contribute as well.
The only real missing ingredient is that because that Maintenance Agreement is cultural more than it is written down in a way that Corporate Lawyers can read it and Actuaries and CPAs can understand it to be an asset and/or liability that impacts the books, it just becomes invisible guilt: either the guilt that you aren't doing your part as a developer with respect to that culturally assumed Maintenance Agreement OR the guilt that you are doing your part but that your company may find out and claim you are wasting their time. But seriously, that vendor relationship even though most of the "assets" are "free as in beer" should be on the books and have its own billing codes for the culturally encouraged "liabilities" of Maintenance Agreements to spend a few hours of developer time here or there for the "greater good", but also the specific good of "making Product X better" because that is an asset directly related to the performance and success of "Product X".