Six lessons from experts on building developer communities

I was going through the old Everything Outside Code episodes last week on spotify and realised we had some genuinely good stuff sitting there doing nothing.

Three episodes specifically stood out for me, the ones with:

1. Maddie Stratton, who leads Developer Advocacy and Community at Tiger Data.
2. Aditya Oberoi, Developer Advocate at Appwrite.
3. Ethan Lewis, CTO at Vault

Between them, roughly 50 years of building developer communities across open source projects, DevOps tooling, and infrastructure platforms.

Maddie started a community in 1999 for swing dancers in Chicago. Aditya built a global open source community without ever hiring a dedicated community manager. Ethan works with open source maintainers who have no funding and still need contributors to show up.

Here are six things from those conversations that I found interesting and wanted to share here.

1. Your community's identity is the only thing that keeps people around

Maddie Stratton spent time at Chef, one of the most referenced community examples in the DevOps space. When they built meetups, they did not call them Chef meetups. They called them infrastructure as code meetups.

If you're creating a user group around your product, the only people you're talking to are people who already use your product. If we're trying to get more folks involved, we need to connect to the problem, to the thing that we're trying to do. — Maddie Stratton, Developer Advocacy and Community, Tiger Data

People who had never opened a Chef cookbook showed up. The community had a reason to exist that had nothing to do with which tool was winning that year.

Maddie repeated the same approach at Ivan, where He built around open source data infrastructure as the shared identity. Aditya did something similar at Appwrite. The community there grew around a frustration that most developers know well, which is the pain of setting up authentication, storage, and databases from scratch on every new project. Appwrite was the solution people used, but the problem was what brought them there in the first place.

Eldad Fux, Appwrite's founder, has said the project started as his own itch to scratch but quickly became something much bigger than the product itself. That only happens when the identity around the community is wider than the product sitting at its center.

Ask yourself: if someone stopped using your product tomorrow, would they still have a reason to show up? If the answer is no, the community is tied to the wrong thing.

2. Nobody shows up to an empty room

Maddie Stratton and his friend started a website for swing dancers in Chicago in 1999. A calendar of events, a message board, a place for the local dancing community to find each other online. The problem was that nobody wanted to go first.

Nobody wants to come to a party and there's nobody there. Nobody wants to be the first one to talk. So I created about ten different users and talked to myself for the first month." — Maddie Stratton, Developer Advocacy and Community, Tiger Data

He is not saying you should do what he did. When someone lands in an empty community, they leave. Not because they are not interested, but because an empty room tells them nobody else is. Aditya saw this play out at Appwrite too. Eldad Fux, the founder, was the most active person in the Appwrite Discord for years. He showed up, answered questions, and kept the conversation going. That made the space feel worth being in, and other people followed.

If you are starting a community, the first job is making it feel alive before it actually is. Find two or three people who care about the problem and start talking in public. People join conversations that are already happening.

3. The community does not need a manager, it needs owners

Appwrite never hired a dedicated community manager. Aditya Oberoi was the first DevRel hire and the team has stayed that way. Instead, the DevRel team, the success team, and engineers all show up in the community as part of their regular work.

Because we didn't keep just one community manager, we enabled a shared responsibility structure where everyone from the Appwrite team has the opportunity to contribute and give back. — Aditya Oberoi, Developer Advocate, Appwrite

When one person owns the community, every question, every moment of feedback, and every conversation runs through them. When the whole team is involved, members end up talking to the engineers who built the product, the people who help them use it, and the founder. Ethan Lewis runs Vont with a team of three and describes the same setup. Everyone touches the community because everyone owns the outcome. That is what makes a community feel lived in rather than looked after.

4. A community tied to a work login resets every time someone changes jobs

Maddie raised this from his time at Pager Duty. The product worked in a specific way where your login and your community identity were both tied to your employer. Someone could spend years building relationships, contributing, and becoming a trusted voice in that community. Then they change jobs and it is all gone. The next employer uses a different tool and that person effectively disappears

Your Pager Duty login is highly tied to the company where you work. When you wanted to build community around that identity, you couldn't really do it, because all that stuff is gone when you go somewhere else." — Maddie Stratton, Developer Advocacy and Community, Tiger Data

This is a design decision most teams make without realising they are making it. When community membership is tied to a product credential, you are also deciding that your community resets every time your users move. The communities that survive this are the ones where the identity belongs to the person, not the employer. The Kubernetes community is a good example. People stay in it long after they stop running Kubernetes clusters daily because the identity is theirs to keep.

5. Rare events get attended. Frequent ones get ignored

Appwrite runs two large community events a year. Aditya arrived at that number after watching what happened to teams that ran community events every month and noticed a consistent pattern: attendance would start strong, drift after a few editions, and eventually the same small group of people would be the only ones showing up.

We do office hours every week, but it doesn't mean everyone has to go through those. The larger events we do are more occasional. Because we don't frequent those big events, we're able to curate content really well and generate more hype." — Aditya Oberoi, Developer Advocate, Appwrite

The Appwrite Init events are the clearest proof of this. These are week-long launch events where the team releases new features, brings in external speakers, and gives community members a stage to present their work. Thousands of people show up because the content is worth the time and because these events are rare enough to feel like something worth attending. When the team has six months between events, they have enough room to make each one genuinely good. That is what keeps the audience coming back.

6. Your community knows things about your product that you do not

Maddie built the Arrested Devops in 2013 for people who were new to the DevOps movement. The experts already had shows. He wanted something for people whose boss had just discovered DevOps and needed a starting point. A few months in, He noticed something unexpected. The people listening were not beginners. They were the practitioners who had built the DevOps movement in the first place.

You can't control your audience. You can have an aspiration, you can say this is what we built this for, but a really robust community is going to be developed and shaped by its members. — Maddie Stratton, Developer Advocacy and Community, Tiger Data

The same thing happens with products. Ethan Lewis works with open source maintainers through Vont and talks regularly to customers who run communities two to three hundred times larger than Vont itself. He describes community as one of the most valuable feedback channels a product team can have, precisely because members use the product in ways the team never designed for. Aditya built this into Appwrite's release process. Before features shipped, the community heard about them first. Feedback from that loop shaped what actually went out the door.

The information is there either way. The only question is whether your team is paying attention to it.

Wrapping up

Community building takes longer than most teams plan for and breaks in ways most playbooks do not cover. These six things came from people who have spent years working through exactly that, across products and audiences that look nothing alike.

At Hackmamba we have built developer communities from the ground up for companies like Actian and Auth0, and our own internal technical creator community has grown to over 2000 members. If you are trying to figure out where to start or why what you have built is not growing the way you expected, we are happy to talk through it. Book a call with us.