OpenLint picking up where Spectral left off
In an age of relentless slop, it's never been more important to protect your API ecosystems with automated style guides, and whilst Spectral has slowed down, OpenLint is about to hit the ground running.
Spectral is an open-source OpenAPI, AsyncAPI, and JSON Schema focused linting tool created by now acquired Stoplight. The tool is much like ES Lint for JavaScript, and Rubocop for Ruby, it spots mistakes in code. At first people use it to check if their OpenAPI is valid, then they discover it's ability to automate API Style Guides with limitless ability to cover any sort of rule you could imagine due to its extensibility with custom rules and custom functions. For a long time Spectral was saving a lot of people a lot of trouble fending off bad contributions to API ecosystems before code was even written, fundamentally enabling the API Design-first workflow, which has become even more important in an increasingly sloppy world.
Phil Sturgeon
Automating style checks with Spectral has enabled API governance teams to attack problems at the API contract level, which is almost impossible in polyglot ecosystems otherwise. Without OpenAPI and an automated style guide, you might as well all be reading tea leaves trying to work out if APIs are useful, consistent, and secure. Using Spectral, APIs can be built with Ruby, TypeScript, Java, and languages you've never heard of and/or forgot the name of already, and the governance teams (or the API designers and developers themselves) can easily flag up non-compliance with various standards and styles during development stages before time is wasted writing code.
Since Spectral's owner Stoplight was acquired by SmartBear the open-source project seems to have ground to a halt, and to be honest it had been slow for a long time even at Stoplight as they focused heavily on corporate solutions and the hosted Spectral platform, with little functionality making it back down to the open-source offering.
Some contributions from the community have added OpenAPI v3.2 support, but mostly the only notable changes have been adding spyware (aka telemetry) which people have not been too excited about. With Spectral in decline a variety of vendor-specific implementations have appeared, with Vacuum, Redocly CLI, Speakeasy CLI, all taking a bite of the apple with varying levels of compatibility with the original Spectral ruleset format.
As always happens in these situations, a group of motivated individuals are forking the project to get things moving again. This is not just a ragtag crew of flippant users, this is everyone you would want to see involved, including ex-SmartBear staff, ex-Stoplight staff (Jakub Rożek and myself), a bunch of the vendors maintaining their own versions, longtime users and contributors like the chap who contributed that OpenAPI v3.2 support (Thanks Mike Kistler!). Beyond contributors are the folks using Spectral at major banks, like HSBC and various European governments who quite like the idea of making this a non-US project for reasons I can only guess at and laugh about before I cry a bit. All of this being headed up by the API Evangelist himself, the man who bleeds API standards should you dare to cut him, Kin Lane.
Group chats have been had over the last month, and much has been discussed, first and foremost a project needs a name, and that name is...
OpenLint
It's not a name I picked but it's a name that's immediately grown on me.
- Spectral (and Speccy before that), were named because they would look at your "API Specifications", but it's long since been agreed that the documents full of OpenAPI you have are not API Specifications, they are API Descriptions. We weren't going to call is Desctral or Desccy because that would be shit.
- Various ideas like Beacon or Sherpa were suggested with a view to making the tools be more about guiding you in the right direction instead of shouting at you for missteps, but these did not get the vote.
OpenLint is not yet ready for you to install, and it's all still being discussed, but here is what does exist.
- There's a domain name: https://openlint.org but the website isn't ready yet.
- There's a GitHub organization: https://github.com/openlint
- It's entirely open-source and always will be.
There will not be any vendor involved with this project, it will be truly open and funded by sponsorship from the huge organizations that use it. This will pay for the team who maintain it, which will probably involve myself.
Spectral has a place close to my heart as one of the most used open-source projects I've ever been involved with. CodeIgniter, FuelPHP, PyroCMS, The League of Extraordinary Packages and the PHP-FIG all had a huge impact, but since leaving the world of PHP to focus on APIs in general the biggest issue was API Governance and tools had to be built. I built Speccy (with Mike Ralphson) in my time at WeWork which I was disappointed to see they abandoned when I left. Stoplight hired me to product/project manage their Speccy rewrite Spectral, which I loved doing for years, but they redirected focus and took resources away from the project when it needed it most.
OpenLint is all of our chance to make something amazing, working together with the amazing folks behind the other linters like Vaccum, Speakeasy, Redocly, to standardize things, increase reusability, and push the space forward.
I cannot reiterate enough, that API Governance is more important than ever. Inexperienced developers fresh out of a scam bootcamp used to just be throwing rails generate APIs into your complex microservice architectures without anyone noticing and it was already difficult enough to spot the probems, but now that everyone has a ClankerBot built into their IDE fire-hosing nonsense into production, it's increasingly important we make sure those APIs are following basic standards and security principles. We can't do this all ourselves, but we can deploy OpenLint and automate a lot of it, and this is a tool which will response quicker to this changing landscape by not being tied to product release cycles.
Hop on over to OpenLint's GitHub community to discuss how we should tackle many of the key problems, like ruleset testing, aliases, autofixing, removing Stoplightisms, tooling conformance suites, and all sorts of other stuff discussed in our last meeting.
