Maybe not what you meant, but I immediately thought of SaaS. Or various companies' policies of open sourcing non-core software.

Both of those are along the lines of "I need code to do this thing, but I don't want to be the (sole) maintainer."

You could write your own language, IDE, OS, build system, source control, networking library, logging library, shopping cart, payment processor, etc.

That's an overly pedantic use of the word "liability." It simply means that all things being equal, it is better to do $THING in 50 lines of code than it is to do it in in 500.

This is easy to explain when you treat third parties as liabilities as well. For many companies this is a bigger liability than maintaining the code in house.

I recently made the decision to have a third party build a component as opposed to doing it in house. The cost and time to build a component in house vs using a third party ended up being a wash, but the third party offered to maintain and support a solution so this presented less risk to us. This major risk we incurred was in vendor lock-in.

These types of trade offs happen all the time. Think about virtually any SAAS offering that could otherwise be built in house.

In software, there's a whole industry around this: we call it SaaS and/or cloud services. And in fact, it's basically what it means to be a 'services' company. Your customers are paying you to move that liability I mentioned onto your balance sheet instead of theirs.