// Why developer communities are not brand communities

I’ve spent a good chunk of my career working with developer communities (whether that’s external communities, or internal ones inside companies), and I’ve seen this pattern several times. A program would launch with strong company branding, get some early traction, and then eventually decline. Developers were using the technology and showing up. But they were showing up for the product and each other, not because of a deep attachment to the brand behind the program.

When designing the research for my dissertation, I expected to find a strong overlap between developer communities and brand communities (which seem to appear more in academic literature). It seemed reasonable; both involve groups of people organised around a common interest in a product or technology. Both produce advocacy, content, and community value.

As I worked through 13 interviews with DevRel leaders, I found myself revising that hypothesis. Developer communities and brand communities share some similarities, but the reason they hold together (the bit at the centre) is different. If you build a developer community strategy on brand community assumptions, you’re likely starting from the wrong place.

(Note: Respondents came from a range of company sizes, primarily skewed towards developer-first organisations – tech companies – so insights may not be universal.)

What brand community research tells us

One of the most useful pieces of brand community research, Brodie and colleagues’ 2013 work, says people tend to participate in communities in five main ways (what they call the consumer engagement sub-processes): advocating, co-developing, learning, sharing, and socialising.

Even prior to the research interviews, this similarity felt intuitive to me. The overlap with DevRel community activity is substantial, and active community members do all five things. Educational content is a form of sharing and learning. Ambassador programs create structures for advocating and co-developing. Community events are fundamentally about socialising. This all lines up well with the argument I made in my earlier post on DevRel as value co-creation rather than marketing.

But if you lift the brand community model straight across, you miss the bit that matters. Jono Bacon makes a similar distinction in Bridging Marketing and Community, where he describes brand management as more centralised and community work as more open-ended and decentralised. Richard Millington pushes it further in The Rise of Community Marketing, arguing that many company-run communities struggle because people do not automatically want to gather in a space owned by the brand.

That is the tension here. Brand communities often work because people want to identify with the brand, but developer communities usually work because the technology helps them do the job, they trust it and they learn from other developers using it. The product experience and the peer relationships around it do more of the binding work than the brand itself.

The missing ingredient in developer communities

That value from and shared passion for the technology isn’t the same as brand loyalty. It’s much closer to one developer recommending something to another because it helped them solve a real problem. (Of course, there are always exceptions - some companies build strong affection around their identity). For most day-to-day developer community participation, trust in the technology matters more than affection for the company behind it.

Developers typically advocate for tools because they work. Because the docs got them unstuck. Because the API made sense. Because the product genuinely helped them ship. That distinction absolutely matters for a strong developer relations strategy, and is a stronger core driver of developer community engagement than brand loyalty.

One of my interview participants put it simply:

Trust is your most valuable currency with developers

That trust tends to accrue to the technology, to the peer relationship, and to the individual advocate more than to the company itself. The perception of the brand, in some cases, can even become a liability if it starts to feel like the company is trying to sell or promote something rather than genuinely support developers and risks eroding the trust that holds the community together.

Community versus ecosystem: a distinction that changes DevRel strategy

On that point, the interviews surfaced another distinction which I had not seen articulated much in the literature: the difference between a community and an ecosystem. One participant captured that distinction really clearly:

[Community and ecosystem] do not mean the same thing but are similar. Community is what I consider invested developers who find value in your product and want to find other people who might be finding value or talking about it. Ecosystem is more all-encompassing. That’s gonna include everyone. I think of the community as more intentional and the ecosystem as everything that relates to and touches the product somehow.

Trying to convert your entire ecosystem into a community will fail, because many people in that ecosystem do not want that deep relationship. They have different needs, different constraints, and may have a stronger attachment to another part of their stack than to your platform. They just want to use the technology, not necessarily join a community around it. And on the flip side, if you treat your intentional community members like just another segment of your ecosystem, they will notice. Fast.

From what I saw in the interviews, the best DevRel teams are clear about this distinction and build different tactics for each. They invest in community-building programs, in-person events, ambassador initiatives, and co-creation opportunities for the intentional community. They invest in scalable resources like clear documentation, self-service support, and smoother onboarding for the broader ecosystem. Both matter, but they require different approaches and different levels of investment.

You can see that difference in the wild. Google Developer Groups are explicitly framed as places where developers connect, learn, and grow together around shared interests, often through local or campus-based groups. Slack’s community chapters use a similar model: meetup-style groups run by volunteers to help people connect, share, and learn with each other. That is community. It is narrower, more relational, and more intentional than the full ecosystem of everyone who happens to use Slack APIs or Google technologies in their day job.

This distinction connects directly to the developer experience foundations explored in an earlier post: the depth of positive DX that turns a user into an active community member is different from the minimum viable experience needed to keep a wider ecosystem participant productive.

Why the language around community matters to leaders

Chris, is this just semantics? Does it really change what teams prioritise?

Sadly, if you use the word “community” in the wrong room, some leaders hear “small side initiative” rather than a route into product feedback, adoption, and trust. The words “community” and “ecosystem” shape how leaders interpret the work. That framing can affect what gets funded, how success is judged, and whether the DevRel team’s activities are seen as strategically important or nice to have.

When DevRel’s value is already hard to measure, the language you use to describe it can make a big difference in how it’s perceived and supported. One participant put the consequence starkly:

if I don’t have executives that believe that we’re here providing value, to begin with, […] that’s where your DevRel team gets cut.

Sometimes the ecosystem language can help in executive conversations because it shows how DevRel connects to the wider developer audience, not just the most visibly engaged part of it. But that only works if the team still protects the depth of investment required for the actual community.

But there is an inward advocacy dimension too. The same way DevRel advocates for developers inside the organisation, bringing community feedback into product decisions and representing developer needs to engineering and leadership, the language you choose internally can either support or undermine that advocacy. “We invest in our community” and “we’re building an ecosystem around the platform” can send very different signals about what the team values and why.

GitLab’s Developer Relations handbook is explicit on this point. It describes DevRel as the voice and ears of GitLab in the wider tech world and says the team should actively listen to and incorporate community feedback to inform product development and improvements. Mary Thengvall makes a similar argument in DevRel Qualified Leads, where she shows that community work becomes strategically valuable when it routes feedback, beta testers, and difficult product issues to the teams who can actually act on them.

That also showed up very directly in the interviews:

If a community person says, “This doesn’t work”, “I’m having problems with this”, or “I need this feature”, you push that back to the product teams. If you’ve got multiple community members talking about certain things, it will be important for the rest of your users.

Community engagement levels: why the spectrum matters for DevRel

The research also helped me articulate something I don’t think we talk about enough: not everyone engages at the same depth, and that’s okay. That means you will often get something different back depending on where someone sits in that spectrum. An occasional user, an active community participant, and a trusted community leader should not all be served in exactly the same way.

Similarly, brand community research talks about a range from passive consumers to active co-creators. DevRel has something similar, even if it looks a bit different: from users who have never touched a community space, to deeply invested people who create content, mentor others, contribute to the ecosystem, and represent the technology in public.

Mary Thengvall describes the same broad progression in The DevRel Path to Success: Awareness, Enablement, Engagement. Developers first need to know the product exists, then they need the resources to succeed with it, and only then does deeper community engagement start to make sense. The team at DeveloperRelations.com makes a similar point in its guide to mapping the developer journey: developers test before they trust.

It also lines up quite neatly with Sonia John’s post on GitHub’s ReadME project about developer onboarding and community participation, which frames developer onboarding as a progression from documentation and education through community support and developer enablement. Practically speaking, some people need clear docs, smoother onboarding, clearer signals when something goes wrong, and an obvious way to get unstuck. Others are ready for workshops, community calls, product feedback and opportunities to test, teach, and shape the ecosystem around the product.

Many companies have this spectrum in practice, even if they don’t talk about it explicitly. For example, Twilio makes that split very visible. Its Quickstart docs are built for broad, self-serve adoption across multiple programming languages and framework setups. Its Champions program, by contrast, is for a subset of developers who are passionate about the Twilio ecosystem and share knowledge, support communities, and participate in focus groups and product feedback sessions. Different programs, different audiences, different expected outcomes.

That logic came through in the dissertation too, especially around high-investment programs:

We consider them key influencers in the community and unpaid developer advocates. We get feedback directly from them under NDA, showing them what’s coming and what we’ve been working on to see how it’ll best reach the audience.

NN/g’s piece on participation inequality gives the same warning from another angle: in most online communities, a large majority lurk, a smaller group contributes occasionally, and a tiny minority drives most of the visible activity. If that is true, then it should already make us suspicious of any strategy that treats all engagement as if it were equal. The DevRel teams that think this through tend to get much more from the work. The ones that treat community as one big blob usually get a lot of activity, but not much that really moves.

What this means for your DevRel community strategy

If I were pressure-testing a community or ecosystem strategy after this research, these are the questions I would ask:

1. Are you clear whether you are building for the community, the ecosystem, or both? If you blur the two, be clear about where it’s appropriate to use high-investment community tactics for intentional community building, and relying on docs, onboarding and similar tactics for scalable ecosystem support.
2. What is doing the binding work in your community? If trust is being built through positive product experience, peer learning, and honest feedback channels, reinforce those tactics. If the brand is contributing to the binding work, be careful about how you use it, and make sure it’s truly supporting the trust that holds the community together.
3. How are you designing for different levels of engagement? Occasional users will need clear docs, smoother onboarding, lightweight support, and signals (e.g. in-product experiences, errors, warnings, and notifications) that help you spot friction early. Deeply engaged members may need ambassador or superfan programs, community calls, beta access, and tighter feedback loops into product to cultivate a sense of belonging and connectivity within the community which also enables them to contribute to the wider ecosystem.
4. Is your inward advocacy strong enough to connect both groups back to the product team? Community conversations, support patterns, onboarding friction, and more data-driven insights like telemetry or conversation trends on social media all create signal. The question is whether that signal is reaching engineering, product, and leadership in a way that changes anything. The four pillars of DevRel help explain why that feedback loop matters so much.

Overall, the academic frameworks on brand communities are useful starting points. But that’s just it, they’re starting points and not blueprints. Developer communities need their own separate model, grounded in how developers actually build trust, evaluate technology, and decide where to invest their time and reputation. As we’ve seen, that partly exists, and has room to be built out further.

If this has sparked a thought, I’d love to hear your perspective by contributing on the BlueSky thread below. Or if you prefer a more private discussion, drop me a message on LinkedIn.

In the next post, I’ll look at how DevRel teams handle feedback with their community, not as a broadcast exercise but as one of the clearest ways product teams learn what developers are actually experiencing. Until the next post, bye for now!