Fork Stewardship

The ruleset format that most of the industry governs APIs with today lives inside one company's linter, as a config file with no separate specification and, since the acquisition, very little investment. I have watched this pattern break my heart for sixteen years — API Blueprint, RAML, Swagger, one good open thing after another absorbed and left to stall. Governance is too foundational to leave sitting there.

So the work is to lift the ruleset out and make it a first-class, documented specification the whole community owns — a real spec with a strong JSON Schema, education around it, and a vendor-neutral home alongside OpenAPI and Arazzo. When I talked with a longtime maintainer of the original linter, this is exactly what he pointed to: the canonical implementation, clearly specified, is what unlocks a healthy tooling ecosystem — the way Swagger did for OpenAPI. Without it, everything is buried in one implementation and everyone else is reverse-engineering a black box.

There is a right way and a wrong way to fork. The wrong way is one strong personality declaring "here is my approach" and walking off — a fork that optimizes for one company's edge case and never invites anyone in. The right way is community-led: get the people who built and depend on the thing back around the table, put the spec somewhere neutral, and steward it in the open. That is what I am doing, working with others from the standards community, and it is what I can help you do — whether you are a provider who wants a seat at that table or an organization that needs its governance to rest on a standard that will outlive any single vendor.

I do this in the open under API Commons: the ruleset format is being specified as Spotlight Spec with its JSON Schema on SchemaStore, a community linter fork, and a suite of tools around it. Open tooling is how a standard earns trust; stewardship is how it stays healthy.

What you walk away with

• A governance foundation that rests on an open, documented specification — not one vendor's config file
• A seat and a voice in a community-led effort to keep the ruleset format neutral
• Provenance and portability: rulesets that outlive whatever tool you run them in
• A path to contribute the spec into a neutral standards home alongside OpenAPI and Arazzo

Related reading & tools

• Spotlight Spec — the ruleset format as a standalone, documented specification
• Spectral Ruleset Studio — turn a style guide into an owned, grounded ruleset
• Ruleset Commons — adopt a provenanced ruleset by reference
• Rules service — craft the machine-readable rules themselves
• The State of Spectral in API Pipelines (paper)