9 years of AsyncAPI (and why I'm stepping down next year)
Fran Mendez
9mo·6 min read
Nine years. That is actually wild to think about.
If you asked me back in 2016 if I saw this becoming a global standard, I would have laughed. I wasn’t trying to start a movement. I was just trying to fix a specific headache I had. I wanted to generate documentation and code skeletons for my event-driven services. I was using RabbitMQ, and the whole thing was a total mess. So I built a tool to fix it.
For the first two years, I felt like I was speaking to a wall. I’d push code, write about it, and get silence in return. I honestly thought about walking away. It felt like nobody was listening.
Then, the tipping point happened. My friend Nico sent a tweet from the Spec by Slack conference. He posted a picture of the screen where Slack engineers were presenting, and right there, they mentioned they were adopting a new specification called AsyncAPI.
Slack announcing their adoption of the AsyncAPI specification.
That was the moment. It wasn’t just my side project anymore. It was solving actual problems for real companies.
As the project grew, I had to learn the hard way how to professionalize it without killing myself. I went from pushing “WIP” commits directly to master (because who cares, right?) to trying to act like a serious organization while still being completely alone.
That is a fast track to burnout.
The real work wasn’t just rewriting the spec to support more protocols than just AMQP. Though making AsyncAPI the “Switzerland of protocols” was a huge technical challenge. The real work was learning to let go.
Today, I’m on the Governance Board with Thulie and Hugo. We have the Technical Steering Committee (TSC). There are times when I disagree with the direction things are going. I’ve learned that if I want this project to outlive me, I have to shut up and let the community drive. I have to practice loose-coupling with my own creation.
But let’s be real: keeping that community engine running is incredibly hard. We have so many tools, parsers, and the spec itself. Finding and retaining maintainers for such a complex ecosystem is a constant battle. It takes a lot of effort to onboard people, and it takes even more to keep them engaged when the problems get tough. It is definitely not a walk in the park.
Here is the thing that still drives me crazy, though.
We have solved many technical problems, but we still have a massive culture problem in the market.
Don’t get me wrong, better code and documentation generators are great. They absolutely improve the developer experience, and we should keep making them better. I love a good generator. But if you think that is the main priority, you are missing the bigger picture.
AsyncAPI works best when it is part of your application code, when it’s a config file integrated into the runtime.
You should use it to validate messages before they are sent and before they are processed.
You should use it to automatically subscribe to channels.
You should use it to enforce auth mechanisms.
If you do this, documentation becomes a side-effect. A really nice side-effect, sure, but not the main goal.
If you combine this with CI/CD to apply governance and update your Event Catalog, you get a system that is almost impossible to get wrong. But right now, people are too focused on the “easy” wins of generation because building the runtime integration, like a rock-solid Spring plugin, is hard work. But it is the only way to really fix the mess.
Wrapping Up
So, why write this now? Why not wait for the big 10th anniversary?
Because this is just the warm-up.
Next year, for the 10th anniversary, I am stepping down. Completely. I will be leaving the Governance Board and removing myself entirely from the organization.
I am handing the keys to the new wave of people. The project needs servant leaders. People like Lukasz, Thulie, and Hugo, who are there for the community, not for their own interest.
I have done my best. The project charter is strong. The power resides with the TSC. It is time for AsyncAPI to be truly loosely-coupled from its creator.
See you at the finish line next year.
P.S. My new book, Shift, is now available for pre-order.
It's the definitive guide to the politics, persuasion, and strategy of driving architectural change. This is the stuff they don't teach you in engineering school.
Pre-Order: The "Shift" Book
This isn’t another technical book on EDA. Shift is the playbook for the other half of the job: getting people on board.... Read more
This week, I want to shine a spotlight on a newsletter: Start Data Engineering. If our conversations about Event-Driven Architecture resonate with you, I think you'll love their approach.
Start Data Engineering
Bringing software engineering best practices to data engineering.
Over the last decade, I've built highly scalable distributed data platforms and helped companies scale to processing multiple exabytes of data.
My mission is to bring software practices followed by top tech companies to data engineering and help data engineers level up.
I help data engineers land high paying tech jobs and significantly up skill themselves.
