Can you elaborate on how OpenAPI didn't meet your needs for serverless function schema semantics? Because if OAS3 doesn't meet your needs, it clearly needs revision. I'm very happy with my current gig, but I'd certainly be interested in contributing to the OpenAPI specification to be enable it to be flexible enough to express what you need it to express. The community of open and collaborative APIs doesn't need to be fragmented to do encompass whatever's concerning you, does it?

I'm happy to make that offer because, frankly, I have also spent a pretty long time observing the OAS3 work, and it is not a committee where things get "bogged down" for years. The characterization strikes me as pretty unfair--the prevailing attitude certainly seems to be open, inclusive, and driven towards solutions. Everyone wins when the OAS stuff gets better, so the drive is to just do that. It's not an XML standards body or something.

Beyond that, OpenAPI certainly doesn't require a company to adopt a single thing about it in order for somebody to write a spec and to generate a client from that spec. It helps, but there's no need to advocate anything. It sounds like a misdiagnosis to claim it as the reason a company would fail as an integration partner given the significant help that being able to work directly with that company actually is.

Tearing down OAS for what have to be pretty minor flaws (and I use "minor" judiciously; if they're impactful upon "serverless function schema semantics", it's a niche of a niche--and AWS's API Gateway sure doesn't seem to have a problem building OpenAPI specifications off of serverless functions, either via import or export) and a downright fictional characterization of the process of its evolution is really unfortunate.