I worked a little bit with OpenStack about four years ago, and my impression was that it was very design by committee. Design by committee doesn't work too well in software: https://sourcemaking.com/antipatterns/design-by-committee
I think a lot of the enterprise companies supporting OpenStack, like Mirantis (https://en.wikipedia.org/wiki/Mirantis), realized this one way or another, got themselves acquired, and then used the new funding to pivot to Kubernetes or another open-source IaaS offering: https://www.mirantis.com/
Without any promise of enterprise support, there's really no way for the large companies targeted by OpenStack to adopt it and make that adoption sticky. So that's how it died.
The practical end result was that you didn't buy "OpenStack", you bought "Mirantis OpenStack" or "Juniper Openstack" (... that one was so broken...) and so on, and there wasn't much portability between them.
The basics worked across all distributions, as far as I know. (The openstack-cli which was built on the HTTP API, which was shared.)
Mostly I had problems with the classic deployment, debug, develop cycle. Reporting bugs is like throwing time out of the window, debugging through overlay networks, über verbose python daemon logs and RabbitMQ madness was also more of a surreally dark exercise in futility, than rewarding experience.
Most of the problems I experienced were problems due to the fundamental trade offs taken during the deveopment of OpenStack. And these are slowly addressed, but ... it was too little too late - at least in our case.
I think a lot of the enterprise companies supporting OpenStack, like Mirantis (https://en.wikipedia.org/wiki/Mirantis), realized this one way or another, got themselves acquired, and then used the new funding to pivot to Kubernetes or another open-source IaaS offering: https://www.mirantis.com/
Without any promise of enterprise support, there's really no way for the large companies targeted by OpenStack to adopt it and make that adoption sticky. So that's how it died.