 Hi, this is your host of the party on behalf of the Linux Foundation and today we have with us friend Mendes founder at a sync API Initiative friend. It's great to have you on the show. Thanks for having me here. Linux Foundation will host a sync API To kind of help the community Before we talk about this whole collaboration. I understand what is a sync API project all about so I think API is an initiative that is composed by two main areas one is Specification they seem to be a specification and a related tooling tooling to work with the specification, right? So the spec is a specification meant to describe even driven architectures or asynchronous API's and we have tons of tooling to support users and developers to To work with it when driven architectures. What problem is the project trying to solve and for whom so the problem is The problem is for developers trying to Create build, you know event driven architectures In the past it's been very it's been very hard to work with Event driven architectures because everyone was doing rest API's or recently GraphQL API's and there was almost no tooling or no Standards around event driven or how to do event driven architectures, right? So I think if you get specification address this problem the standardization problem and And the tooling and the really tooling is aiming to solve this value for the user this final value for the user which is Building event driven architectures in an easy way. Now, let's talk about why did you choose Linux Foundation to host the project? Well, that's a that's a good question. We've been exploring different Different ways to become neutral We wanted to first become neutral as a project in the past It's been all related to myself and I wanted to just get read like get rid of this legally speaking right and so companies and and other people can trust the project and They don't think it's it's a tremendous thing, right? so we chose the next foundation because they allow us to to create our own our own system of open governance if you want and And we have this freedom while providing too many good services and then it's also Linux Foundation It's we all know it's really it's a really great foundation. So So, yeah, so it was it was an easy choice for us actually How is Linux Foundation helping a sync project because typical Collaborative projects in the links foundation, you know Linux Foundation provides you with the governance model, which you can follow. They provides you with funding. They provide you with the marketing resources they also They have a structure, you know where companies people can become member paid memberships are their sponsorships are there So, can you talk about the structure of a synch API at the Linux Foundation? We're not a funded project So that means that we don't accept members paid members because we don't we're not seeking for money here and What we're only seeking is for a standardization and you know and neutrality here. So we we have So Linux Foundation offers as Marketing offers as advice legal advice all the stuff just not the part of Funding right we chose not to do it yet and regarding the open governance. They they have they usually offer That's also optional and we chose to have our own structure and regarding open governance, right? Because their their approach was the open governance offer was related to having members And we don't want to have Companies to vote just because they pay so can you talk about what kind of governance is structure? You have for a sync API project because traditional Linux Foundation projects They have you know a technical oversight committee and then there is you know other boards so they're also separation you know that the members they do not influence the code and Technically oversight community. They don't control the marketing. So can you talk about the structure of governance of the project? Sure? so starting from top I will say there's a technical steering committee and Technical steering committee is the one that controls everything here the whole the whole things in the project And when I say control is that the ones that take the the vote these are the voting members, right? And when there's something to when there's something to vote These are the ones that have the right to vote the way it's the it's the way someone gains Voting right on the project is by contributed contributing very often and being invited by the rest of the TSE members, right? or proposing themselves as as voting as a voting member and The thing here is that We wanted to remain as flat as possible and as democratic as possible as an as a As a project as an open source project and that's why we didn't want to allow people to pay for vote, right? and All the decisions are taken and I mean all the decisions are taken by TSE whenever it's needed Usually if discussions are happened by and decisions are taken by consensus on a per case basis So for instance, we usually discuss on pull requests or on issues on the on the github on the github project on the github organization and We have what we call maintainers of such repositories on on github, right? these maintainers are Part of the of the technical steering committee and are the ones responsible for that part of the project and discussions happen there and Things are escalated to the the technical steering committee whenever it's needed Which is usually not needed because things are usually discussed and agreed on a per case Basis, right? Can you also talk a bit about there are other Projects that are dealing with the same problem one is like open API initiative. How different is this project from that project? So open API initiative takes us think it's the defaults or suggested model by Linux Foundation and many other or many other Foundations, which is you take members and so you take companies or individuals who can pay For for a vote to vote on the direction on taking decisions in the direction of the product, right? and so that's Essentially, that's how it's different then on the on the content side on the on the on the process side We also chose to have reference implementations and tooling associated with the spec Pretty much like what GraphQL is doing They have the spec, but they also have the tooling right? They don't they don't offer only the spec and and the Model that we have that we are using here on it's in KPI initiative It's pretty similar to the Node.js open.js foundation now, but to the Node.js Project so yeah, we're not inventing the wheel here. We're just taking bits and pieces from different projects learning from others people other people's experiences Of course, this is an open source project So anybody can go and see the code out there But what kind of road map do you have for this project number one number two is that as part of Linux foundation now, do you have a specific vision? Also, this is time for you for call of action to invite members to come and contribute to the project The vision that we have for let's say five years from now Is that we we want async API to become the number one spec for defining APIs any kind of APIs? Actually, not just even driven or asynchronous APIs Why is that? we think we believe that Developers don't usually work on event driven architectures only or the rest API is only or on graphql API is only right You usually work with Many of these technologies at the same time and we want to make developers lives As easier as possible without having to Redo and rewrite all the time the same things at the same pieces On async API format on open API format on graphql format That's a mess. We want to solve that we don't want And I want to make it clear. We don't want to reinvent graphql or reinvent open API But instead what do we want it's in kpis to become a format where you can reference these other Specifications and our tooling will be ready to interpret that to to parse this information By leveraging existing tooling from these communities from graphql community from open API community, you know So we're not we don't want to reinvent. We want to become like kind of a half kind of a half spec The same way we're doing with avro right now And json schema both of them are supported into the spec But none of them are created by using kpi like we just leverage in json schema and leveraging avro So we want to continue this trend and leverage graphql data types Leverage open API schemas leverage, you know other technologies And and regarding the you know regarding the these ambitious vision We can't make this alone right just a A few of us this needs to be a community project And that's why we're always getting given this importance to the community To make this project successful this vision successful We need to get people from the graphql with graphql background with open api background your pc background And even driven architectures background to join forces and work on the spec together And create a tool that will treat all these needs right so So i'll from here i would like to take the the opportunity to To call out or to to take to tell the community to join it We're flat and we're a nice project And uh, you're gonna have fun. So yeah, just join our slack You have everything you need to know on asnkpi.com or asnkpi.org Wherever you prefer awesome friend Thank you so much for taking time out today and talk about this project and i look forward to talk to you again. Thank you Thank you so much