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