Focused open source and developer centric vendors are steam-rolling the competition
There is a renaissance happening in software development and integration of off-the-shelf software components. It is being driven by developers having more robust capabilities with how they can glue things together.
That is being further fueled by the tension between successful open source software in use by large enteprise, the big 3 cloud providers each working to make their ecosystem more competitive to discourage customers from going 'outside the wall', and the desire of companies to not be overly locked in, putting all their eggs in one basket. Each of these things is pulling against the other, and the main beneficiary of this tension are a new crop of developer centric vendors and open source projects.
Improved developer-centric models for defining software workflows, deploying, securing, and integrating software, are making it harder and harder for traditional software vendors to compete. Developer centric market leading vendors and purpose built open source components are competing on something that is not easily measurable on a marketing/sales checklist: flexibility.
Building in Flexibility
The general pattern of enterprise software and sales for vendors of yester-year was that they built a solution, topped it with a pleasing administration UI, and added an API when required by customers. Contrast this to focusing on the things that will enable the developer flexibility first: API and integration options. Building an aesthetically pleasing admin UI now comes last, but it forces a focus on ways to provide essential value early rather than a focus on aesthetics of demos given in sales pitches. The tail on this is long, but it enables a huge long term advantage.
Traditionally, integration was viewed through a narrow lens. With a few breakout exceptions to that rule, there was nothing driving a focus on flexibility early in a product cycle. A developer and integration focus flips that model on its head. The difficulty for traditional vendors here is that the devil is in the details. You can't just check a box off on a feature comparison chart late in the game to provide parity with a more progressive vendor or open source solution that has been building a community and developer focus early. It's too architecturely significant of a change, too late in the game.
It's not easy to assess without direct experience
The flexibility and approachability of how a solution enables integration with existing customer investments has a huge weight in how much value can be derived and at what pace. It's becoming more rare that an on-paper comparison can effectively measure if a given tool has the malleability needed to maximize potential value-add to the wide variety of value streams that vary from company to company. Even an initial POC may not be enough to assess that.
If a customer can't iterate effectively, gaining incremental value as they do, an implementation veers off into the dangerous territory where it may fail or sometimes worse have hidden costs that add up to a level that would not have justified doing it in the first place.
This is a big part of why we're starting to see API-first vendors (like HashiCorp) and a wider variety of open source solutions starting to take a significant hold in large companies. When you can adopt and de-risk the implementation of a new thing incrementally and quickly, you maintain the flexibility to adjust your on-going investment as needed.
You can see this manifesting in some banks and retailers adopting open source first strategies. Enterprises are also more actively backing open source foundations and adopting tooling which enable portability of their custom applications.
When evaluating a vendor or open source solution, it's essential to consider this kind of flexibility so that you retain the ability to change direction as needed. Don't paint yourself into a corner.