[gunsch]

I spent a few years building OpenAPI-related tools at Google, collaborating with Apigee.

One of the "open secrets" about OpenAPI's history was how Smartbear spun out the OpenAPI spec to be a community-managed spec, but with the requirement that there wouldn't be official tooling offered with it --- arguably to protect Smartbear's investment in Swagger. (it's been a minute so specifics are hazy but IIRC it was something like this). The tooling ecosystem feels pretty disjointed as a result.

Compare to gRPC/protobuf, where the specification and tooling have been developed together. Parsers, static analyzers, code generators, documentation tooling all happen in lockstep with spec development, and the ecosystem feels much more cohesive.

[handrews]

My involvement started in the lead-up to OAS 3.1 so I don't have any insight into the Smartbear/OpenAPI Initiative hand-off. Yes, the decision to be vendor-neutral is part of the reason the ecosystem is so fractured. But most technical standards are vendor-neutral and work just fine.

OpenAPI also has the problem of not providing any guidance on what the tooling ecosystem ought to look like, regardless of who implements the tools. You want enough leeway to encourage innovation, but if you don't put out _anything_, you get... well... this. Lots of tools that don't all fully implement things, and not much in the way of interoperable points of hand-off between tools beyond the format. And when many tools leave off some feature or another (most egregiously, external referencing - down the line in this blog post I'll actually show a concrete solution for that), just sharing the format isn't enough.

I'm hoping that this approach I'm sharing through these blog posts will help us start to shape the ecosystem more. For Moonwalk if nothing else (although I'd love to get 3.x into more of an interoperable state- let's make life better for people working with things now, not just years down the line).

[The_Colonel]

> but with the requirement that there wouldn't be official tooling offered with it --- arguably to protect Smartbear's investment in Swagger

That kind of seems backwards. If there was a official tooling, it would be Smartbear's (who else would provide it?) This clause actually seems to be designed to limit Smartbear's ability to use OpenAPI to push their products (and at the same time push OpenAPI as a credibly vendor-independent spec).

> Compare to gRPC/protobuf, where the specification and tooling have been developed together.

Yes, because it's a protocol pushed by one company, not pretending to be independent.