Paying someone to offload things you shouldn't be doing is a sound strategy when applied correctly. Unfortunately this message can't come from someone like Orac

Paying someone to offload things you shouldn't be doing is a sound strategy when applied correctly. Unfortunately this message can't come from someone like Oracle whose entire business depends upon companies choosing to buy instead of build. I used to work for Oracle in the field as an SE working on the largest enterprise customers they sell in to. What's left out of the rebuttal is how Oracle (or really any vendor), often sells solutions to problems that customers don't have. And even the solutions that do solve the customers problem on paper are often complicated, don't quite work right because of implementation problems, and lower quality because they're more general purpose. So you end up with a situation where it's dubious that you're any better off at the mercy of a vendor whose interests aren't well enough aligned. The real trick is figuring out where the line should be drawn in buy vs. build for any given initiative and the underlying technology required to satisfy those requirements. Can a homegrown software org. handle the entire lifecycle of building and maintaining the products they build? The ideal place for these teams is at the margins and leveraging highly used products where there's as little custom code ownership as possible. Open source or otherwise. There's certainly a tipping point beyond which an open source project has better quality but it's not clear where that lies. And if you're getting into bed with any software vendor without transparent pricing and good vendor management you risk subjecting yourself to renewal conversations that answer the question of "How much?" with "How much you got?"