Well most of the software is crap because almost all of them use Shibboleth, where every configuration is stored in ugly XML files and then a reconfiguration means restarting the service with new XML files.
SAML is very used at Government level and because Government likes JavaEE so much, but the libraries/frameworks implementing/offering SAML are pretty garbage
For Shibboleth, the XML configs are unwieldy, but both the IdP and SP are solid and eminently configurable, which is helpful when interfacing with someone else's broken software or odd requirements. In running our Shib IdP, I've had far more trouble with hand-rolled SPs (presumably using found libraries) than I've had with poorly managed Shib SPs. SimpleSAMLphp is comparable, if you're not a Java shop.
Commercial IdP-aaS products have their place, but with their spread, some SPs just code and document how to integrate with the two or three most popular IdP-aas products, and if you're using something else, you're left trying every possible binding, signing, and encryption, until you figure out which one works. Competent SP authors and operators can likely say similar things about various IdPs.
Despite the standards, it's nice if knowledgeable, accommodating people are running capable software on both ends of the exchange, and frustrations will probably increase the further you depart from that ideal.
SAML is very used at Government level and because Government likes JavaEE so much, but the libraries/frameworks implementing/offering SAML are pretty garbage