The session where the fork got its name. Mike brought news that his OpenAPI 3.2 pull request had finally been merged upstream. Jakub noted the Spectral repo has been busier since the fork was announced, though mostly triage. Mike also showed that the fork's ruleset schema was already validating his AEP rules in CI and in his editor. Due diligence settled the tie: Spectacle has an active German trademark, while OpenLint was mostly clear. So we're going with OpenLint. The option for SmartBear to give Spectral to the community stays open for another week, and the first decision in the new repo will be how to handle the existing fork.
OpenLint · Session 6 of 6
Choosing OpenLint
September 17th, 2026 · 0:18:38
OpenLint
Naming
Spectral
OpenAPI 3.2
What we worked through
Upstream is moving
Mike’s OpenAPI 3.2 support was rebuilt and merged by the maintainers after an AJV problem. Jakub has seen more activity on old issues since the fork was announced, though not much in the way of harder features shipping.
The ruleset schema in practice
Mike followed the fork’s instructions to lint the AEP ruleset, added it to CI, and added YAML schema markers so rules validate as he edits them.
The decision
Spectacle and OpenLint were tied. Spectacle has an active German trademark; OpenLint’s only problems were a dormant npm package and a taken .com. The group agreed on OpenLint and suggested reserving the npm scope right away.
Starting clean
Every decision from here should be an issue or pull request in the new repo, so it has a public record. The first one: how OpenLint relates to the existing fork and to Spectral.
Connecting the specs
I have been sitting in on the OpenAPI, Arazzo, Overlays, AsyncAPI, JSON Schema, MCP and A2A meetings. OpenLint can connect those specs, providing guidance and guardrails as well as governance.