OpenLint Office Hours #2

00:00:00Before the start: Hellos while people join. Kin is fighting off a cold before speaking in Stockholm next week. The group talks about the Nordic APIs Summit and its unconference the day before, and remembers RESTFest: "a bigger version of RESTFest", "it was barely a conference", "everybody had to present".

00:03:44Kin Lane: We've got Mike Kistler joining in. I think we've got quite a crew here. We don't have Phil, but maybe give it a few. I'll start diving into the agenda and getting more routine and process into what we're doing here. We're slowly picking up.

This is being recorded, and I'll publish the recording for y'all. I'm not using Google Meet for that; I'm using a separate local tool. Everything's under the OpenLint community repo now. You can go under Issues. I try to prepare the office hours agenda at least a day or two before; I managed to get this one up on Tuesday. I'll publish the recording and the transcript from this on there, and then I try to carry it forward. So we'll always kick off with a recap: here's last week's, and you can find it on YouTube. I try to do some blogging. We did add a code of conduct, so if you're not in tune with the code of conduct, make sure to check that out.

We're official: we're OpenLint. We renamed from our earlier working name and whatever else we had on the table. I'm still hearing chatter that SmartBear might give us Spectral. Not holding my breath, and that's about as long as I hold my breath right there. We do have a website up, and we've got quite a few discussions going on in the community.

The way I broke this down: we had a laundry list of projects we said were a priority. I grouped those into three buckets, each with claimed and unclaimed sections: the spec, which is first and foremost, the toolbox, and then the administrative stuff. You're all welcome to throw things on, and we can refresh the page and check in during the open floor.

The process we're loosely following, doing our best, is that everything should begin as a discussion: start something in a discussion and get people talking. Once you start doing work, create an issue, and then create pull requests as evidence of that work. Sometimes I'm finding you can skip the issue and go straight to the pull request; there are exceptions. But generally that's the process, so that everything has a discussion, and everything has an issue outlining the work, with the stakeholders involved, focused on one thing. Some discussions have multiple pieces of work, multiple issues, multiple pull requests. Before I dive into the spec, any thoughts? Anybody want to share?

00:07:47An attendee: It looks good to me.

00:07:48An attendee: Yeah, that's a good plan.

00:07:53Kin Lane: Go ahead, Ricky.

00:07:55Ricky Moorhouse: I was just going to ask about the pull requests. What sort of thing are you looking for on reviews or comments? Obviously, if something looks odd, there's feedback to comment. But if it all looks good, do you want those comments on them as well?

00:08:11Kin Lane: I'll take anything along the spectrum. Please provide feedback, please comment. Don't feel like you're not welcome to. Keep it respectful, keep it within the code of conduct, and try to educate. I even started a discussion on one thing, and then someone reminded me there was already work going on there, and I closed it. So do your homework and look around a little before you give educated feedback. But yeah, dive in.

And if anybody here wants more access, to be able to create repos and do work: right now it's just Phil, Jakub and me. If you want access, I'm more than willing to give it. I'll take it away and play God if you abuse it. But I'm more than happy for people to have access to create repos and create stuff, so let me know. I'm trying to have reviews on pull requests, and to invite people to do reviews if they can. Don't be shy. If you're doing work and you need eyeballs on it, pull me in, pull Phil in, pull anybody from the group, and we'll do our best to provide feedback.

00:09:33An attendee: Cool, sounds good.

00:09:38Kin Lane: We'll get more formal and more structured. I'm hyper-aware of process, because I'm joining in on OpenAPI, Arazzo and Overlays, where I helped lay a lot of the foundation early on, in 2016 to 2019. I helped create the original SIG groups that are now Arazzo and Overlays. Seeing it play out now, in good ways, but also seeing things like the charter and the governing processes hamstringing people... Too much process is a pain, and too much infrastructure can be bad. So I'm trying to be light touch, but also lay down enough foundation here.

I'll also preface all of this: our goal right now is to get things open for business, business as usual. It's not new changes, new features, new properties, or new iterations on the spec or the tooling. It's to get it into an operational state on par with where Spectral is, or I'd say ahead of where Spectral is, just because we're open for business and we have governance.

The spec is the first and foremost bucket. These are the things that have been claimed, and if you claim something, I hope you'll join the meeting and speak about it, because otherwise I can't really speak to it. We should probably start putting people's names next to these, so we know who owns each one in the conversation; otherwise it gets passed over. I see these calls as the high-level check-in on all the work. We won't go too deep, but we'll talk through the important issues.

First and foremost, I have a repo called spec set up. It has a pull request with basic generated documentation for the OpenLint spec, based on what Spectral is, and there's a JSON Schema to support it. Feel free to submit comments on the spec itself. It's pretty much derived from what Stoplight had published, but I'd say it's a little more robust, and it's trying to follow the normative language we want. That README is echoed in a single page on the website, so there are two repos: one in spec and one in the website repo. The website is just an echo of the documentation for the spec. Both those pull requests are out there right now. I intend to keep going through them, polishing, adding details, and catching some of the glitches, because both were generated. If I don't get any feedback or reviews in the next couple of weeks, I'll go ahead and merge them, and they'll become the README and the documentation page on the website for the spec. Like I said, there's nothing new there. It's formalizing the configuration for Spectral as a formal spec.

Next is formalizing the spec. Does anyone want to add anything? Anything you'd like to see, anything you'd like to talk about?

Well, I'll jump in and say I'm using this as a guideline for generating those docs, and I'm also going through by hand, making sure I'm conforming with it as much as possible. I think we've got to talk about what version we release this under, because this is OpenLint, not Spectral. What's our first version out of the gate? Is it 1.0? Is it 0.1? But I'm using this as guardrails for what I'm building.

Also backwards compatibility: existing rules, new rulesets. I've got a lot more work to do gathering up rulesets. I want a lot of evidence, starting with the Dutch government's rulesets, and then finding others: Adidas, and several other strong rulesets out there. I want to pull them in and look not just at the rules themselves, but at how they're managed, how they evolve, and how they're versioned. There's a lot of research that has to happen on backwards compatibility. I'll also add, though I haven't commented yet, that we've got to consider Vacuum as part of this conversation. So there's a lot of work to be done on backwards compatibility.

00:15:55An attendee: I think the first one is really important. All rulesets that currently work in Spectral still need to work. I think there's no way around this, in my opinion, as someone already commented. For the second one, I'm also not so sure. What currently works in Spectral, as far as I know, isn't really a described feature. It's a bit of a hidden feature: you can use x- to add fields, and Spectral will just ignore them. It was described in a commit, but it's not really in the documentation. If you want to add new fields to the format, it will be difficult, I guess.

00:16:40Kin Lane: Definitely. Mike.

00:16:42Mike Kistler: I think the x- extension has to be added formally in the documentation, in the new spec. It works in Spectral, it's just nowhere in the documentation. You only find it if you dig through the commits, and I've long used it.

00:16:59Jakub Rożek: The extensions field is actually harder to explain. I feel like we could possibly drop it, because I don't think anyone actually uses it, but there was a hack that needed it. Since this is recorded, I can't say why it's there, because it was for an application under someone else's control back then. But it's a hack, basically so the rulesets could be validated. It wasn't something that was documented.

Actually, in terms of backwards compatibility, there are two or three things. One is the JS API, because a lot of folks actually embed Spectral. They don't use the CLI; they embed it, whether that's the VS Code extension or the JetBrains extension for IntelliJ IDEs.

00:17:52An attendee: I can tell you, because we tried lately: the APIs are really bad, let's say. I needed to explore it, which is a huge problem in a big enterprise; it's not as easy. But I think IDE extensions are underestimated. They're really important for larger organizations as well, because developers want to use IDE extensions. Maybe that has nothing to do with backwards compatibility, but it's an interesting topic.

00:18:32An attendee: I have a question. I've been going through the repos. As far as the compatibility, or the support: is the idea for the overall spec that you could throw any of the popular DSLs at it, and it works? It's supposed to support all of them? Could I eventually say, I've got a different type, say Protobuf [?], can I throw that at it, and it'll lint it? Is that the goal, far out? What are we trying to do?

00:19:17Kin Lane: Yes, and I'd say that's under the format, or document type, conversation. But yes, the goal right out of the gate is that it's used for much more than OpenAPI, AsyncAPI and Arazzo. Right now it's just JSON and YAML formats, and there's some work to separate that language: data format, being YAML or JSON, versus API formats and other types. We're going to get pretty pedantic about that. But yeah, that's the goal. I use it to lint JSON-LD, and I use it to lint APIs.json, so there's already a wide swath it's being used for. One of the reasons I forked it is that I needed to support Markdown. I needed to support skills in Markdown, which is half YAML and half unstructured. So yes, that's the long-term goal.

00:20:21An attendee: That's great. I'm heading in the same direction, but I wasn't sure, so thanks for clearing that up. I can see being token-sensitive, and supporting the native formats that come along, and right now that's the big one.

00:20:44Kin Lane: There are quite a few on the table. Back real quick: Jakub, can you talk...

00:20:55Jakub Rożek: Yeah, I'd like to extend my thoughts, because there are three things. I'm talking from the perspective of a maintainer about what I would consider a breaking change. You might disagree with that, obviously. For me, it's not just the format of the ruleset itself and whether it's accepted or not. People are also sensitive to the actual behavior, the linting behavior. By that I mean: I give a ruleset to Spectral, and I get the same results back. If I don't, I don't consider it backwards compatible, even if my rules didn't change. The rules are still accepted by OpenLint, it still lints, but the results are different. Instead of getting, say, five errors, you get six or seven now, or something else is different: a message is different, or the range, the line and character position in the output, is different. Some people could consider that a breaking change.

So I'm thinking about whether we strive to be compatible with regard to that as well, because that will be hard in general. We wouldn't be able to make any changes if we strive for one-to-one output, where you put the ruleset in and get the same output out of OpenLint as from Spectral. That's difficult. That's the second one, apart from the JS API I mentioned, and then obviously the ruleset format itself, which I feel is what we mostly talked about before.

Technically, the core functions, like schema, truthy, falsy and so on, aren't necessarily part of the ruleset spec per se. Their behavior isn't listed in a spec, what exactly they should do. But they're what actually makes the linting happen: they take the input and eventually produce the diagnostics that users see. So I'm asking how far we go with backwards compatibility. There's more than the ruleset format itself, and a lot of it isn't documented. Mostly it's a sample that was accepted in a test. It's difficult to assess. You need a very extensive conformance suite to assess against. Only then can you start moving forward and see what you actually break or don't, and whether you're fine with it. Just to keep everyone honest about it. Again, it's up for discussion. I'm not saying we should be very strict on anything, just that there's a little more to it.

00:24:16Kin Lane: Yeah, great thread in the chat. It starts with: what is our definition of backwards compatible? There's a lot of research I have to do on this, and then we move into the conformance testing realm. So we need to work on our definition and our baseline of testing. I don't think we'll be able to conflate backwards compatibility with the popular definitions of it, because we're dealing with a fork here, and with several branches of that fork. I know Vacuum is a big one, and I'm going to push Dave to try to join in. He made it pretty clear he doesn't really care about the rules as a format; Vacuum rules are all he cares about. But it's important to me that we have some compatibility. For backwards compatibility, we'll need clear definitions of what it is and what it isn't, and then, separately, we need to get to work on conformance testing to help us with this.

I'm going to close that one up, because we've got a lot to get through and only another 30 minutes. Please chime in on that discussion; I'll take everything from this transcript and get it in there.

We started talking about document types, aka formats, and data formats, and there are several threads: are we talking about different formats, or different document types? Phil's done a bit of work to start down this road, so chime in there. This one is really important to me; as I said, I use it across many formats. I'd love to see Ansible, Terraform, any JSON or YAML output of any system, any gateway, anything I want, on this list. But that's going to take champions and a lot of work.

I can't speak to aliases; Phil will have to come in on that. Do you have anything to add, Mike or Ricky? It looks like you've been chiming in. Anybody?

00:26:52An attendee: Nothing for me.

00:26:54An attendee: Nothing more than what's in there. I really like the split Phil was suggesting, between the core aliases and the custom ones Mike was talking about. I think that's heading in a good direction.

00:27:11Kin Lane: Agreed. And I've said it before: I'm always hyper-aware of the critics of any spec, and everybody I've talked to says, "You shouldn't even fork Spectral, it's crap." And I ask, why is it crap? "Because it uses JSONPath." I understand JSONPath has issues, but I see aliases as a way of abstracting away some of that complexity to begin with, because JSONPath can be a pain. And then potentially swapping out the engine behind JSONPath, if we want to support something else. I think aliases are the bridge to that. So definitely jump in on aliases. Lots of good work there.

00:27:58An attendee: And with all the people we have here, we also have a good idea of what people already use for JSONPath, or what's typical in rules, from all the rules we already know about, including internal ones. So we can collect a good list and know which aliases we need. I think that's a really good place to start. We have a bunch of people who really use this feature or write the JSONPath, so we can easily collect a good list and start with the most common ones. Then more aliases could be added in the future, depending on what people need. This could be very helpful.

00:28:44Kin Lane: Yeah, I'd say aliases, in that light, are a big part of education, training and onboarding. You shouldn't have to become a JSONPath expert to put this to use effectively. I'll produce a lot of that data from my APIs.io harvesting. I harvest Spectral rules from anywhere I can find them, so I'll start compiling the most common JSONPath and feed that into the catalog. Aliases have a lot of potential; they could mask quite a bit. It's a short code, and right now it maps to JSONPath, but my goal would be that it could map to many different things, in different formats, with different queries. When we start bringing in GraphQL and gRPC, there are a lot of possibilities for abstraction.

Rules testing: yes, yes, yes. We had a really good one at Postman. Let me see if I can find it; I'll link it in. It was a rules builder, but you could test, including custom functions, so it was a quick way of building and testing rules and making sure they were valid. This is going to be pretty critical, so jump in on that.

I added a Learn 101 section, which is my attempt, out of the gate, at having a basic "what is a rule, how do you build a rule" entry level on the website. Then I'll start working on 201, 301, the advanced levels and other pages. Rules testing, the rules builder, rules education, and aliases, as we just talked about, are important to have. Education is one of the biggest things that didn't exist with Stoplight, and it frustrated me endlessly.

00:31:15An attendee: I think education is going to be a big key to getting adoption, and to people understanding how and where to use it better than they do today.

00:31:24Kin Lane: Agreed, 100%. If you subscribe to the API Evangelist newsletter, I say it's API governance, in parentheses, guidance: rules with a link to the documentation. Education is guidance. The only thing that makes a rule matter to me isn't the enforcement, it's the education and awareness that go with it. That's where I found success at Bloomberg: lighting people up and getting them involved in the rules creation process, by first educating them on what a rule is and why it matters. The only two rules I was able to flip to red severity at Bloomberg were "must have a title" and "must have a description". I wasn't successful converting anything else.

00:32:28An attendee: Yep, I know the feeling.

00:32:29Kin Lane: That was a year's worth of work on those two. Anyway, there's a bunch of unclaimed items on the specification. I'm doing a lot of research on how we should think about modularity, rules federation and industry-level rulesets. Then there's the tool conformance suite, rules testing and custom functions. Custom functions are important. I have some work on ratings, but I'm trying to set the table before I move too fast or too far. Go ahead, Mike.

00:33:15Mike Kistler: Are you publishing where you're finding all these rules? I think that would be a really great resource for people as well, to be able to go and look at what rules other people have written.

00:33:31Kin Lane: The OpenAPI extensions are one source of that. I don't have the rules linked up here anymore; they're on a different site. I'll link them up. I have a whole repo where I publish them, and I'll clean them up, start organizing the JSONPath usage as part of that, and republish it. This is where I publish all my artifact research: A2A cards, Arazzo, things like that. I try to have a separate section for each, and I'll make sure rules are on there by the end of today, because I know I have them.

The IDE stuff: there's quite a bit unclaimed here, but let's jump down. That's the spec. I want to get the table laid: the formal spec repo, formalizing the spec, answering backwards compatibility, diving into the types question, aliases, and getting some base testing and education. That's the table. I want a lot of these other things, but I'm trying to move forward thoughtfully and get the base table set up for the new spec.

On the toolbox: Phil and others have jumped in, forked it, and begun removing telemetry and renaming. Anybody want to speak to the work going on there?

00:35:19An attendee: I talked a bit about that with Phil. There was one library, I think it's called Scarf, that added the telemetry, and removing it was pretty simple. I did it myself for a demo at a conference last week.

00:35:45An attendee: Yeah, I did this last week.

00:35:49Kin Lane: So that's done? The removal of telemetry has already been merged in, and the renaming is still ongoing?

00:36:04An attendee: Yeah, the renaming is still ongoing.

00:36:12Kin Lane: Yes, and getting it to pass, I think, is what he's working on, along with the renaming. Y'all will have to dive into the PR. There's a lot behind it; I was digging in, trying to help. So dive in there. That's in motion. Once the naming is done, the telemetry is gone, and it passes the tests, I'm going to bring it in and swap it out for Spectral in all of the tooling I use, to see how well it works for me.

Backing up one second, before supply chain: that's back to setting the table, being open for business. Having the spec established as a spec at these basic levels, getting the base toolbox working without telemetry and with the rename, and then having implementers actually make the switch. Migration is on the list, and we've got to tackle it: how do we help people migrate? I think we need a few of us who are using it to help with that, write up that migration, and help folks. That's going to be pretty critical. Then there are other things, like removing some of the Stoplightisms, making things more modular, and cleaning up, which continue setting the table without doing new things. Getting it working in my base tools, and getting my APIs.io ratings and everything else switched over and off Spectral, with no telemetry, is pretty critical for me.

Supply chain health: I can't really speak to this, but I think we need to go through the whole supply chain, and I'll work on how we visualize and document it. I want to make sure we're not lazy moving forward, that we respond rapidly to any supply chain issues, and that we have a triage process and strategy ahead of time. We've really got to have our hands on what the whole supply chain looks like. I'm not a Docker expert, so I can't dive into the Docker work, but I want to help document it. Staying up to speed on the latest from Docker, and what they're doing with AI and sandboxing, will be a critical piece.

Rules for OpenLint repos, requiring reviews and who approves: this will be governance. We're still tailoring and figuring it out, but whoever steps up and does the work will become the working group. Please make sure any pull request has reviews. I'm not going to enforce things with GitHub right away, but we'll need to enforce reviews pretty quickly and lock down the repos.

Anybody want to speak to the VS Code extension? I haven't dived in here, but this is a critical one, another piece of tooling. I think we need to get it forked and in use. I need to be editing rules and playing with it; I'm a VS Code user, so this is pretty critical to me.

00:40:20An attendee: We were en route to create an LSP for our own checker, instead of a VS Code extension. I can imagine the market has changed and everyone's using VS Code nowadays, but would an LSP be a more agnostic approach, perhaps?

00:40:54Kin Lane: I agree with that 100%. I'm a VS Code user, but I'd rather have a larger circus tent and be able to work across multiple IDEs, or just in general. I haven't commented on this yet, so I'll dive in, provide some feedback, and see what they're thinking.

00:41:16An attendee: Yeah. I'll post a comment as well, because I'm curious why this decision was made. Maybe it's too difficult to create an LSP; that's also a good argument. Maybe it's about using the common library rather than forking anything into a separate form. I don't know. Interesting to understand.

00:41:40Kin Lane: Yeah, comment, and I'll dive in as well, based on work I've done, because that one's pretty critical. I'd say VS Code is good right out of the gate, but it needs to be bigger, it needs to be wider, and LSP is definitely where we need to be looking.

I'd probably move item five, cleaning up vendorisms, up under core libraries, right there with supply chain. I'll make it item three and bump the others down. As soon as the naming and telemetry are done and we're working on the supply chain, we should be cleaning up any other vendorisms. Then I want enough research to inform the default ruleset, so it's less Stoplight-focused and more OpenAPI-focused. That opens the barn door pretty wide.

Rules builder: I'll have to let Phil talk to what he's describing here. Let me see if I can find it real quick: the Postman toolbox. This was the Postman one I wanted to emulate, and I'll talk to the builder behind it. Being able to build your rules and apply them from a library is pretty key, so I'll get that in there. The rules builder is going to be pretty key, but it brings in other considerations I don't even see on here: a rules registry, and an OpenAPI or other artifact registry. When you're working in a rules builder, should you be able to pull from a catalog of rules, or work from a bunch of existing ones? That's how I learned. I'm not an engineer, I'm a reverse engineer: I reverse engineer other people's work.

Lots unclaimed there: the CI/CD work, format auto-detection, how modular the tools should be, the ref bundler. I love that work. There's a lot of work in here, so feel free to follow the discussion, issue and pull request process. If you're not interested in doing the work, but it's important to you, fire up a discussion anyway and start the conversation, even if you're not going to do the work. I'm fine with that. There's a lot in here I don't want to do the work on, but it's really critical to me. I took the first pass. I was at API Days London last week, and next week I'm in Stockholm, so I probably won't then, but this week I'll probably take another pass and start some discussions on a few of these, just to get the ball rolling.

So that's the spec, and that's the toolbox. They're separated; that was important to me. I wanted the spec to have legs and stand up on its own.

On administration: governance. I've got a governance page, discussion and proposal in place, the base governance doc that articulates what I just talked about: who's doing it, how it happens, getting some rules of the road in place. It references the code of conduct. The code of conduct was even more important to get in place, I'd say, but they're both up for discussion right now. As I said earlier, only three people are listed as maintainers, but I have all of y'all on the maintainers page as contributors. If you show up for a meeting, you'll get added to the maintainers doc. The top-level maintainers are the ones with GitHub privileges, and if you want GitHub privileges, just ping me. I'm happy to turn it on and give you more control, and then happy to get you in trouble when you do things you shouldn't, or yell at you, but I doubt that will happen.

Funding, which I put first: I set up Open Collective. We're on Open Collective now that we have a name; that was one of the critical things about having a name. I've also applied to Open Source Europe to be our fiscal host. Those were two critical next steps, which is why we needed a name and why it was pushing us toward naming. Once Open Source Europe accepts us as a fiscal host, we can accept donations, and we'll have some IP protection as part of Open Source Europe. Once that's lit up, API Evangelist will probably throw down about a thousand dollars or more to get the ball rolling, and then we can figure out how we use that money. One of the things I want to start chasing is corporate sponsors. I'm already pushing people to sponsor OpenAPI and other specs, and I'm going to start begging. I'm pretty good at begging and harassing enterprises into giving money; it's my hobby, we'll say. The other is chasing public sector money, from the European Commission. My goal is to get Phil paid. I'd like someone to help as an administrator, but I'd like to get Phil and others paid, and start figuring out how we fund actual project work and get it done. Since we're in Open Source Europe, there's European Commission and other money for that, so I'll be chasing that as well. If you come across any links, potential organizations, anybody, feel free to submit an issue or email me directly. [email protected] is open; you're welcome to ping anything, and I'll chase it.

The code of conduct is already up. Getting involved: I keep the GitHub README open, but it did take you a while to get plugged in, Miguel. Hopefully it was painless. I'll keep an eye on that.

The website is pretty basic right now, and I'm purposely keeping it minimalist. I'll add the spec once that pull request is in. That'll light up, along with the naming and how we got here. I publish these meetings to the list. I try to blog, not always successfully. I like how blogging is a record of how we got here, so I'm trying to document as many things as I can. If you want to blog, feel free to ask for permissions or submit a pull request. And I'm keeping the GitHub org as updated as possible. I'll add the education page once that pull request is in. I'll keep it minimal for now. If we want a site overhaul, or to make it look prettier down the road, we can do that, but I'm trying not to do too much.

There's licensing and trademark work to be done. I'm not too worried about it right now. On licensing, we're following the licensing of what we forked, so we're staying there. I'll add our copyright, because we're keeping the Stoplight copyright; that's part of what we've got to do.

Use of AI: I'll get a formal page up. I haven't published it, but where I'm leaning is that if you're using AI for something, talk it out with the stakeholders at the discussion level first. When you create an issue or a pull request, how AI is being used should already be agreed, maybe as a score from one, don't use it at all, to five, fully automated. I'm working on a rating system for that, and I'm going to apply it to some of my issues and pull requests. What I'm seeing across all the specs I'm attending is that AI is a major problem, because people don't disclose or talk about how they're using it. It's funny to be on MCP spec calls with Anthropic folks, and they're saying AI is a problem. So with that said: Miguel, go ahead.

00:51:32Miguel Quintero: I think Andrzej was first.

00:51:34Kin Lane: Oh, okay, sorry. Go ahead.

00:51:37Andrzej Jarzyna: It's kind of a side question. You mentioned that SmartBear may, or probably won't, give us the name Spectral. What happens in that case, for example, to joining Open Source Europe, or to the branding?

00:52:14Kin Lane: What's there now is the minimum entry for me, because we need the fiscal responsibility and we need the governance. In short, I'm not going to think about it until it happens, because I honestly don't think it's going to happen. I have déjà vu from Swagger; this happened before. I don't think they care, and I don't think they want to. They already look kind of bad because of us, me being so theatrical about it. And I think they'd want more control over it, the way they took control of Swagger. That was a different CEO. So I'm not going to worry about it until it happens, because I don't think it will.

00:53:07Andrzej Jarzyna: Okay, thanks. I was just curious how it would go.

00:53:13Kin Lane: Miguel?

00:53:15Miguel Quintero: My question is about funding. I'm thinking maybe we could use some of that funding, or really get some sponsorship, from some of the AI code review tools. I'm using some of those, so I can make suggestions. We have to protect ourselves against any swamp; it's inevitably going to happen. I know a couple of those people, so maybe I could reach out and say, "Hey, do you want to help OpenLint out for free, or sponsor OpenLint?" CodeRabbit, for example, is one I've been using, and Greptile [?]. There are a couple out there, and in my opinion they're really, really good. On top of what you mentioned about being honest, "this is AI-generated" and so on, those tools are really good at actually catching things that get through. So I could look into that and reach out to them.

00:54:23Kin Lane: Please. Any research or outreach. That's partly why I'm joining all the other spec conversations, to understand how people are approaching it. I'm building this one-to-five rating system to use in practice, and if it sticks, we can evolve it. But I see communication and disclosure as the top issue. Look at the website spec page and the README: I generated them with Claude, and it says so at the top. So it definitely has a use. But what I was doing before, some of the issues and pull requests it would create were just enormous. So I'm handcrafting issues and most of my pull requests, but I use Claude locally to provide a lot of information and generate things, and then I pick from it and submit. There will be parts I just use Claude for completely, because I only have so much time in my day. But we've got to have the review process, and consensus and agreement on where it should be applied. So any outside help, as well as tools to help us do that work: hell yeah.

00:55:46Miguel Quintero: Okay, thanks.

00:55:50Kin Lane: And on another front: please spread the word and get other people to the table. We've got IBM, with Ricky. We've got the Dutch government, and API Evangelist with me. But we need more corporate people jumping on. I know Pavel from SAP was really interested. And all the new players, like Speakeasy. I'm going to keep pushing on Dave and Vacuum, as well as Adam at Redocly, and APIMatic, and others, but they're less interested in the ruleset than in the tooling. I'm going to push on a lot of these players and try to get more people involved. And I think Arazzo and Overlays are a really great opportunity to renew OpenAPI energy, and I'm chasing people for OpenAPI money and involvement there as well. I'm trying at the A2A and MCP levels too, but we'll see what luck I have.

If you've got other players who want to be involved, tell them about the weekly call. Right now I'm keeping it at this time, one hour, but we may start breaking it up into tooling versus spec, and we may talk about the schedule for the US West Coast, US East Coast and Europe. I want to get more people involved, so tell people about the meeting, point them to the repo, and feel free to blog, on your own blog or the OpenLint blog, and let's get the word out. There's already been some great storytelling out there. Bruno Pedro took a shot at us this morning, which I love. Bruno and I are very adversarial in our approach, but he's questioning it, and there's a lot of good conversation about it right now. We need to stir that up. I even talked to SmartBear at API Days London, and they're very supportive of what we're doing: the workers, the people on the ground floor.

I love the energy behind all of this right now. For me, OpenLint plus Arazzo and Overlays are the front end of a rejuvenation, new energy that'll carry into OpenAPI, AsyncAPI and JSON Schema as well. And when it comes to validation, and steering and guiding the AI pendulum as it swings back toward the need for determinism and skepticism, I think OpenLint has a massive role to play. But we have to have the table set and the ground floor in place. That's what I'm shooting for, folks.

And we're at time. Thanks for showing up, I appreciate y'all being here. You know where to find me; let me know if you need anything. Chime in on the repos and the discussions, and we'll see you next week. Cheers.