Fran Mendez is the creator of AsyncAPI, the specification for event-driven APIs that now sits alongside OpenAPI and JSON Schema at the core of how we describe our APIs. In this conversation we go back to why he hacked OpenAPI into existence for events, what it actually feels like to own a successful open specification for a decade, and the responsibility, expectations, and thin economics that come with it. Fran is candid about the success of AsyncAPI being "overwhelming" — he stepped back from the organization this year — and about the trap of trying to save a space that never asked to be saved. From there we turn to Commune, the headless Substack alternative he is building now, why he is deliberately building on top of existing email vendor APIs rather than reinventing the wheel, and why the inbox remains one of the last digital spaces where people still hold real control.
API Evangelist Conversation with Fran Mendez on Creating AsyncAPI, the Weight of Owning a Specification, and Building Commune
Conversation
Why did you create AsyncAPI?
I had a need. About ten years ago I was building an event-driven architecture internally at the company that later became Hitch, using RabbitMQ as the broker, while our product was all about OpenAPI — so we were very well versed in working with specs for APIs. I found that crafting a new service for routing, consuming, and publishing events was very similar to building APIs, but there was nothing like that for events. I was repeating myself constantly — maybe eighty percent of the code was always the same boilerplate for connecting to the broker, consuming from a topic, processing a message, publishing a message. Only the business logic changed. There was no way to check whether the messages we received were well structured, and with JavaScript we didn’t even have type safety. So first I actually hacked OpenAPI for events — I assumed GET means subscribe, POST means publish. It worked decently for documentation but not for the rest. So I read OpenAPI top to bottom a few times and changed the things that didn’t make sense for events. That’s how it came to be.
Was AsyncAPI a success?
Absolutely, yes — to the point that the success is overwhelming, already too much for me. After ten years I actually decided to quit this year, to leave the organization and disconnect from AsyncAPI a little bit. I’m still on the governance board, but I completely disconnected, because it’s grown so much that it’s overwhelming the amount of things it involves. And it’s not about the spec or the code anymore — it’s about the community, community management, the whole human thing around building communities, the paperwork, the relationships, the travel. It’s too much. I always chose to make it open because of my ideals about how the world should be, independent of how much money it would or wouldn’t give me. I had chances to close it and sell it — to MuleSoft, to others — and I didn’t. You never know whether it’s worth what it’s worth because it’s open, or whether someone would simply have built another open alternative if I hadn’t.
What expectations are placed on you when you create a specification?
Always assume people are about ten years behind you on this kind of thing — that you’re ten years ahead. Because you’re working on a very specific niche, most people will be wondering why a spec is even needed and how it works, and even once you answer that, they still have to find a real need to use it. The problems you have are usually not the problems other people are having; you’re too far from them because you only work on this. And financially it’s another thing entirely. I recently learned AsyncAPI’s net worth is calculated at around thirty-four million dollars — and I don’t have thirty-four million dollars. I was very lucky: I worked for companies that bet on the project and put a lot of money on the table, asking nothing in return — at Postman my team was twelve people at one point. That’s very rare. In general, people creating specs struggle to even make half a salary. You may be creating enormous value for companies, but they won’t easily give you the money.
Do you have advice for people who want to create a new specification?
It’s more a recommendation than advice: always drive what you add to the spec from a real use case — ideally one that’s repeated across the industry, a need that many people are actually having, not just because something is possible. The same things we’ve heard from product managers for years apply here: before you add a feature, research whether anyone is going to use it and whether it’ll make an impact. And always default to not having things, or to having less powerful things, because it’s far easier to add over time than to remove. Removing features is a pain; changing them completely because you added them too early is a pain. That was actually my biggest mistake. You’re eager, you want to move fast, you want to make a lot of people happy and respond to the moment — but it’s going to change over time.
What is Commune?
Commune is a newsletter — a social network of newsletters, if you want. A headless Substack alternative. I’m not going to pitch the product, because honestly that’s not what’s important to me. For me, Commune is a way to escape the warehouse, the machine we all live in — but I’m not even trying to find fresh air, I’m trying to find myself again, back to me. For many years I did what the avatar of Fran Mendez was supposed to do. When I created AsyncAPI I wasn’t actually an API or messaging expert — I just like to build things, and I was making a tool for myself and sharing it openly. Commune is the same instinct with a different touch: I’m back to building, but now with much more knowledge about how to create, market, and sell a product than I had ten years ago. It’s the result of letting myself build whatever I want, not what people expect the AsyncAPI guy to build.
What technical, business, and political decisions have you made with Commune?
Technologically I’m deliberately not doing anything innovative, and that’s on purpose — I was tired of building for developers, so I’m building for humans, for writers and creators. I’m not trying to compete with email service providers like Kit or MailChimp, and I don’t plan to send emails myself; I build on top of their REST APIs and let them handle delivery, adding a social layer on top of your newsletter. As a concrete example, I needed a notification when someone sends a newsletter, but Kit’s API doesn’t have a webhook for that event — so I set up an inbound stream with Postmark, subscribed my own address to their list, and now I get an email when they publish, which is my event to react to and pull what I need. Business-wise, only people who have a newsletter can publish on Commune — you can’t post otherwise, you can only reply and comment. Newsletter owners can’t spam their subscribers, so they take more care about what they publish, and that’s how I keep more silence than noise. I don’t want people on Commune every day.
Is email one of the last digital spaces where we still have control?
I absolutely agree — that’s why I’m building Commune. Everyone is trying to reinvent Twitter with Mastodon and Bluesky, which I love, but a decentralized alternative was already there: SMTP and POP. It’s decentralized enough to hold the power yourself. The inbox is one of the few places that hasn’t had these warehouses built around it. My wife runs a successful newsletter on Substack — she’s not technical, but when it became a Nazi bar she was able to leave, move to Ghost, and keep her audience, precisely because her success was email-based. Email gives you a lot of control even when you use third-party services underneath. The other reason is noise: social networks are full of it, by design, like slot machines tricking your brain. I’m building a place with more silence than noise, where you should not be coming in every day. If you want to post something people will consume, start a newsletter.
Fran Mendez
Fran Mendez is the creator of AsyncAPI, the open specification for event-driven APIs that he started roughly a decade ago while building event-driven systems at the company that became Hitch, and which now sits alongside OpenAPI and JSON Schema at the core of how teams describe their APIs. He shepherded the project and its community through years of growth and significant industry investment before stepping back from the organization, remaining on its governance board. Based in southern Spain, he now describes himself as a builder and is creating Commune, a headless, open alternative to Substack that adds a social and discovery layer on top of people's newsletters.
