[devonkim]

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).

[StillBored]

I don't think this is a really an open vs closed source question. If anything, long term you might be better off on a closed source solution if you don't mind paying for it. To many open source projects die because something cooler comes along and the maintainers lose interest. Then you end up being the maintainer of some piece of dead open source history.

Really if your worried about becoming attached to a particular technology, you should choose from the beginning to build a heterogeneous environment, and require all your in house development to adhere. In the beginning it might be painful to assure that your software stack runs on two different databases/OSs/ec, but once the abstractions are built up it will likely result in a more stable environment, and ease porting to a third should one of your original choices die.

[devonkim]

This sounds like you're talking about abstracting and decoupling components. Building systems to accommodate heterogeneous environments early is akin to starting a project with microservices instead of a monolith - it's overscoping probably. Furthermore, it's fallacious to say that all software should fit some new standards of environments when there's no scenario for it all (the COBOL code that's for accounting doesn't have anything to do with the products your company sells probably).

This then raises issues of compatibility with your customer's environments. The configuration matrix that you'd need to test is tedious (read: costly) in traditional software releases compared to SaaS where you're free to make a lot of decisions independent of your customer and not everything can be automated (anyone that's deployed automated tests against TN3270 terminals with a lukewarm IQ QA department is right to challenge this). Then there's longevity. What happens when your biggest paying customer wants you to stay on IE 8 until 2025 (not an exaggeration)? Want to create yet another customer-specific branch? Eventually you wind up needing a test environment that matches exactly what that customer has and paying contractors to maintain that dead-end tech stack and doing that for every customer. That is quite common and also quite costly but not needing much talent, so the washed up maintenance engineers go here at less than mediocre compensation to cut costs. That's zombie software for you - the soul and spirit of engineers are gone and its corpse is animated by money by a cruel master that cares little for its past life.

[greedo]

It's not so much that the CIO/CTO wants the ability to call up a vendor, or have his employees call up a vendor for support. What a CIO/CTO wants is the ability to tell his CEO that "Yeah, we're having a problem with our database, but it's Oracle so we're good. I'm kicking the vendor's ass, but he's going to make things right on our next renewal." It's all about plausible deniability, and goes back to the days of "Nobody got fired for buying IBM."