Well I certainly have at least $0.02 of perspective on this topic. In 1996, I started working with Electronic Data Interchange (EDI) systems for a chip design company (Xilinx) in silicon valley. I don't think we could have achieved our goals without the enterprise software (RMS OmniTrans, which has apparently since been sunsetted – another issue with enterprise software), as I don't think there was any viable open source alternative at the time, and we certainly weren't going to write something that was challenging for software vendors to deliver. There was no way to do anything with this software without using it's proprietary, semi-declarative, largely sequential language, meaning instant relatively light lock-in.
To do anything significant, such as write to a database instead of files, we had to write in C/C++, and we further locked into a library from another vendor. I really liked Oracle RDBMS and supporting tools at the time, but have since learned to despise Oracle as a company. So, we had relatively tight lock-ins to at least three vendors, plus a bunch of shell scripts on Solaris that might have worked on other platforms, and eventually Perl scripts to replace some of the shell scripts. This was a great learning opportunity for me, and it kindof made sense for a technology company.
After going back to school for a while, I worked for Tri Valley Growers, which is basically a food canning operation. They were doing something similar with Gentran and SAP, which was a nightmare. What I realized then is that a company that cans food should not have to have expertise in technology (and especially managing its own data centers), but this actually seems impossible.
After that disaster, I started working as a consultant with the Interwoven product line including the TeamSite Content Management System (CMS). That product was incredibly specialized, requiring extensive custom code in a vendor-extended flavor of Perl, often using command line tools to interface with the product. I eventually developed Perl libraries that the vendor didn't provide, where they eventually provided Java libraries and a JavaScript interface (like everyone else at the time, I also invented AJAX!), but only for some aspects of the product. This was a hugely lucrative product and consulting environment, though I never worked for the vendor.
In 2004, I started working with one of the major .NET CMS vendors. I see a a sort of triangle – customer, consultant, vendor, where the consultant and the vendor get big money from the customer, who always gets screwed. Some of my clients were John Deere and Pioneer Hi-Bred (I know, not necessarily the most ethical companies, but the money was good and the work was interesting). It seems really strange for a tractor company and a seed genetics company to be required to try to differentiate themselves with marketing technology rather than focusing on what should be their core competencies.
One problem with enterprise software is that they're always trying to grow sales, which often means expanding into new product lines, reducing their focus on their core competencies. This might have some advantages for customers when those products are well integrated in advance, but this seems extremely rare, requiring the customer to do some level of integration on their own. And this approach furthers lock-in to a vendor, who can modify pricing and make any other changes whenever they want.
All of the solutions I ever worked with required extensive custom code, meaning extremely high vendor lock-in. Open source is not a complete solution, as documentation and support can be limited, products can still fade over time, any custom code still locks the customer in, and required features don't always appear when needed. In any context, extensibility is key, but that further enforces the lock-in. Vendors seem more likely to have the resources to evolve products quickly, but this can increase administrative costs (patching, upgrades, documentation, training, and so forth).
What may be more important than anything is open standards such as EDI. I don't see things like MCP as very useful or complete and complex standards. Standards for things like electronic commerce and ERP interfaces make more sense, but relying on them completely could impact product features and architecture, they never seem complete, they evolve, and (maybe following the Microsoft model) software vendors seem to work against open standards. See: MACH Alliance, which should have developed relevant standards, but is really just a marketing organization.
Another perspective is that, if AI really can eventually develop software at viable scale, that could seriously reduce the cost of producing code, which would seem to seem to doom enterprise software vendors. But customers aren't always great at making platform decisions, especially when vendor marketing and sales influences them, and they always think they get a throat to choke. In fact, there is no throat to choke. When Interwoven started bluescreening on one project when scale testing, the vendor first blamed Microsoft, then 3COM (the NIC), and even Intel until Microsoft support responded "if you uninstall TeamSite, that machine will stop bluescreening, That is an Interwove-specific stop code." The entire solution architecture depended on that feature, so it risked the entire project. Supposedly, Interwoven eventually fixed the bug, but I had moved on by that point.
So, I really don't really see a complete solution. SaaS with web service APIs could be part of it, but has its problems. It certainly seems harder and harder to justify expensive enterprise software nowadays. Anyway, it was all educational, interesting, lucrative, and fun for me at the time, and most of the companies I worked for that had viable business strategies regardless of platform technologies somehow seem to have survived.
