What four months of community analytics taught me about how developers build trust.
When people think about my work at the AsyncAPI Initiative, they usually think about product design, and that's fair. Product design is still where I spend most of my time, and it's the work that has shaped my career. As an Open Source Maintainer and member of the Technical Steering Committee, I'm usually thinking about design systems, accessibility, contributor experience, governance, and the countless small decisions that make complex tools easier for developers to use.
Earlier this year, another opportunity came up.
Since March, I've also been responsible for publishing and shaping much of AsyncAPI's communication across our social channels. I never considered it a change in direction; it was simply another way of contributing to a project I already cared deeply about.
What I didn't expect was that it would change the way I think about Developer Experience.
Around the same time, I found myself revisiting Adam DuVander's Developer Marketing Does Not Exist. I remembered agreeing with its central argument when I first read it: developers have little patience for traditional marketing because they care far more about solving problems than consuming promotional messages.
At the time, I thought it was an interesting perspective on developer relations.
Four months later, I realised it was really a book about trust.
That realisation didn't come from reading the book again. It came from spending months analyzing community data and asking a simple question:
what actually earns a developer's attention?
Between March and June, the content we published generated more than 27,000 organic impressions, over 1,300 link clicks, and maintained an average engagement rate of 7.18%. Those numbers were encouraging, particularly for a technical open-source project, but they weren't what held my attention.
Metrics can tell you what happened. They rarely explain why it happened.
To understand that, I had to stop looking at dashboards and start looking at the conversations behind them.
Over time, several patterns emerged. None of them was particularly revolutionary on their own, but together they changed how I think about communication in technical communities.
People are part of the product
One of the first things I noticed was that some of our strongest-performing posts weren't about product releases at all.
They were about people.
Posts welcoming new maintainers, celebrating contributors, recognising conference speakers, or highlighting community milestones consistently generated more meaningful engagement than many feature announcements. At first, that felt surprising. We're an open-source project centred on technical specifications and developer tooling. Surely the technology would always take centre stage.
The more I reflected on it, the less surprising it became.
Open source has never been just about code.
Every release represents hundreds of conversations, reviews, design discussions, pull requests, and decisions made by people who have chosen to invest their time in building something larger than themselves. The software is important, but it exists because a community exists first.
When we publicly recognised contributors, we weren't manufacturing stories to increase engagement. We were acknowledging work that had always been happening behind the scenes. The community responded because those stories reflected something genuine.
As a designer, I found that an important shift in perspective.
I stopped thinking of community as something that exists around the product. I started seeing it as part of the product itself. Every interaction with a maintainer, every first contribution, every conference talk, and every thoughtful discussion shape the experience developers have with a project long before they open the documentation or clone a repository.
Good technical communication starts with the problem
Another pattern became clear as we shared technical articles.
Whenever a post simply announced that a new blog had been published, engagement was usually modest. The same article often performed much better when we began by discussing the engineering challenge it addressed.
Instead of leading with the existence of new content, we started with questions developers were already asking. Why does API drift become more complicated in event-driven systems? What changes when an organisation adopts AsyncAPI 3.0? Why should infrastructure be generated from the same specification as application code?
Those questions created context before introducing the article itself.
Looking back, this feels obvious. Developers rarely read documentation because it's new. They read it because they're trying to solve a problem. Explaining the problem first acknowledges where the reader is starting from, and it turns an article into the continuation of an existing conversation rather than an interruption.
That small change reminded me that communication isn't simply about distributing information. It's about reducing the distance between someone's question and the answer they're looking for.
Transparency is a feature, not an afterthought.
Perhaps the insight that resonated with me most came from posts about the work happening behind the scenes.
Some of our most engaging updates weren't polished launch announcements. They were conversations about redesigning the AsyncAPI website, improving AsyncAPI Studio, evolving our governance model, or introducing new community processes. They gave people visibility into decisions that are usually hidden from view.
As product designers, we're often encouraged to present only the finished interface. We refine every interaction, polish every screen, and reveal the final experience once everything feels complete.
Developers are often interested in something different.
They want to understand why a decision was made, what alternatives were considered, which constraints influenced the outcome, and what the team learned during the process. Sharing those details doesn't weaken confidence in the product. If anything, it strengthens it because people can see the thinking behind the work.
That observation changed how I think about transparency.
It's easy to describe transparency as a communication principle or an organisational value. Increasingly, I see it as a design principle.
*> Good Developer Experience isn't limited to interfaces, documentation, or APIs. *
It also includes making decisions understandable and giving people enough context to participate meaningfully in the project.
Conferences are stories, not events
The same shift occurred in how I approached conferences.
Initially, I thought about conference communication as a sequence of announcements. Open the Call for Proposals. Introduce the speakers. Share updates during the event. Publish a recap once everything is over.
After a while, that model began to feel incomplete because it treated conferences as isolated moments rather than ongoing experiences.
A conference really begins long before anyone steps onto a stage. It starts when someone decides to submit their first CFP. It continues through mentoring sessions, programme announcements, speaker preparation, hallway conversations, recorded talks, follow-up blog posts, and contributors who discover the project months later after watching a presentation online.
Once I started looking at conferences that way, the communication almost planned itself. The question was no longer What should we post this week? It became Where is the community in this story, and what would be valuable for them right now?
That subtle shift made everything feel more natural because it reflected how open-source communities actually grow.
Communication is part of the Developer Experience
Looking back, I think that's the lesson I'll carry forward long after the analytics dashboards have been forgotten.
As designers, we spend much of our time reducing friction inside products. We improve navigation, simplify workflows, organise information, and make complex systems feel easier to understand. Those are all important aspects of Developer Experience.
But developers don't only experience a project through its interface.
They experience it through the documentation they read, the governance they observe, the release notes they follow, the contributors they interact with, the conference talks they attend, and the conversations a community chooses to have in public. Every one of those interactions influences whether a project feels approachable, trustworthy, and worth investing time in.
That's why I keep returning to Adam DuVander's book.
I don't think Developer Marketing Does Not Exist is arguing against communication. If anything, I think it argues for a different kind of communication, one grounded in education, transparency, and genuine technical value rather than persuasion.
Over the past four months, I haven't become convinced that developers dislike communication. I've become convinced that they can quickly recognise the difference between communication that exists to create value and communication that exists to attract attention.
The distinction matters.
One builds trust.
The other tries to borrow it.
These past few months haven't changed how I think about product design. They've expanded it.
Developer Experience doesn't end when someone leaves the interface or closes the documentation.
It continues every time they encounter a contributor who feels welcomed, read an article that helps them solve a problem, watch maintainers explain the reasoning behind a decision, or see a community openly recognise the people building it.
Perhaps that's why the phrase developer marketing has always felt slightly incomplete to me.
The work isn't really about marketing.
It's about making meaningful work visible.
When the work itself is valuable, honest communication isn't another layer added on top of the product.
It's simply another way of designing a better developer experience.
About the Author
Aishat Muibudeen (Maya) is a Product Designer, Open Source Maintainer, Technical Steering Committee member, and Code of Conduct Committee member at the AsyncAPI Initiative. Her work sits at the intersection of Developer Experience (DX), design systems, accessibility, and open-source governance, where she focuses on making complex technical systems easier to use, contribute to, and sustain. She is also the co-founder of OpenNest Africa and regularly writes and speaks about design, open source, and building healthy technical communities.
Top comments (0)