There's a trade-off being made by picking proprietary software vs. open source and it's entirely about control, strange as it might sound. A
good CTO/CIO has some measure of power over their vendors and can boss them around a bit like they're an employee. If the primary account manager is golf buddies with him, endangering the relationship with arm-twisting on either part isn't just business it's personal and can be viewed in some respects as stable. With open source software, you don't really have anyone you can hang over a fire that holds the kind of political weight - you don't want to have to talk to every single open source project lead or something as a super busy F500 C-level, you want less throats to choke and that your hands are big enough to wrap around them. For open source, the trend has somewhat shifted into each major open source product having a corresponding company offering the full support cycle like any other closed source vendor (Red Hat, Chef, Cloudera, Sqrrl, Puppet, etc.) so things are looking better for hybridized open source efforts today as they grow, but without some consolidation they're not going to be a full enterprise "solution" due to most of them being too specific in applications for their technologies.
As an engineer, I like to think of this primarily social problem like trying to focus a huge, distributed system architecture upon as few languages and platforms as possible. With most enterprises having grown through dozens, maybe hundreds of mergers they have a huge zoo of different stuff to support culturally. You could try integration approaches like message buses and such, but there's a lot of people overhead involved there and it gets really ugly when everyone disagrees upon the message bus (and in sufficiently large groups, conflict is inevitable).