True, I didn't mean to come off as a purist. I think it depends on the service provided and it's maturity level. If you need basics like auth, persistence etc i think those parts should be open, at the very least have a stable API that has >1 provider. (The SRE analogy would be a SPOF).

For things like push- and email notifications, it makes more sense that a provider is involved (although APIs should probably still be open). New innovations can always start out proprietary, and the inventors can always offer support and managed infra for OSS projects.

Why? I believe the health and future innovations within the tech sector relies on healthy competition, and imo, that means that the majority of standard services have multiple providers to choose from. The only way to migrate from one provider to another is through standardized, or open, APIs. VPCs is a pretty good example of this: I can get the premium option from GCP or AWS, and have uptime, bandwidth, and choose a DC from all over the world. OTOH, I can get a cheaper, local one, depending on my needs.

Let's continue that s3 example. There are many products branded as "s3 compatible", but they all have slightly different definitions of what that compatibility means. Not to mention that the s3 api itself is a moving target, and doesn't even have a version number you can reference, so the best you can do is list which features you do or don't support. Some of these products actually have native APIs which IMO are better than S3, partly because they can learn from mistakes in s3s API.