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.

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.