[mtndew4brkfst]

I can't see how Amazon is incentivized to avoid making any changes that break compatibility for their imitators, so long as their first party SDKs continue working. Standardized feels like it should be suffixed with "as long as Amazon doesn't ever feel like evolving the product further".

[uroni]

There is a lot of software that directly implements the HTTP S3 API. That API is also documented by Amazon.

E.g. the last implementation I saw was by DuckDB https://github.com/duckdb/duckdb-httpfs/blob/main/src/s3fs.c...

[mtndew4brkfst]

I think my point doesn't really land. I was trying to express the idea "S3 is not a standard where AWS is the reference implementation, it is a successful commercial product with many many copy cats".

Their only real inherent commitment here is to whatever backwards-compatibility expectations are being set for their first-party SDKs. If they fulfill that but other vendors can't or won't follow suit, the outcome is gonna be different than it would be for an actual standard rather than an assumed one. There is no meaningful leverage for the third parties to exert to force a community-favored outcome if Amazon decides otherwise.

[bigbuppo]

If amazon changes the API they've angered their entire customer base that relies on the API. Sure, some will stick around if they're fully entrenched by the ecosystem, but others will be able to leave, and they will, because hey, S3 is a standard-ish API.

[necubi]

It would be pretty shocking for Amazon to break the S3 API at this point. There is a huge 3rd party ecosystem that would be affected. For example, in Rust land the object_store crate is at least as popular as the official SDK.