What Is Open Source Developer Relations? - by Danica Fine

Open Source, On Purpose

SubscribeSign in

What Is Open Source Developer Relations?<br>It's not the same function with a different label

Danica Fine<br>Jul 28, 2026

Share

As I’ve settled into my role leading an open source developer relations team over the past year, I’ve had a lot of conversations—with folks across open source, developer relations at other companies, and engineering leaders trying to figure out where open source engagement fits in their org. And I’ve noticed a pattern: most people don’t really understand what open source developer relations is (or can be).<br>They either have developer advocates who primarily serve the product and do a bit of open source engagement on the side, or they only know developer relations from a product perspective and assume that the open source version is the same thing with a different label. It’s not. The work overlaps. The skills overlap. But the goals and metrics are different. And what the company needs to provide for the function to succeed is fundamentally different, too.<br>In this post, I’d like to share how I think about open source developer relations.<br>What open source developer relations actually is

The way I view it, open source developer relations is the practice of building and maintaining a company’s credibility within open source communities. That’s it. Credibility is the currency.<br>Everything an open source developer relations team does—whether that’s giving talks, writing content, engaging in community channels, contributing to projects, or running events—serves that goal. That’s not to say that product adoption, signups, and MQLs aren’t important (and I’d argue that those things will follow eventually) but they should not be the top priority on an open source developer relations team.<br>Credibility is absolutely critical because, without it, nothing else works. An open source developer advocate without community credibility is just a marketer with a GitHub account, and the open source community will see through it immediately. Every form of engagement that your company attempts lands differently when it’s backed by individuals that the community trusts versus people the community has never seen before.<br>The foundation of that credibility is presence. An open source developer advocate’s primary mode is simply to be a part of the community. That’s done by showing up, participating, and being a known and trusted face. You earn the right to be in the room by showing up consistently with no agenda beyond participation. On top of that presence, the work itself is inherently bidirectional. And I think this is where the distinction between an evangelist and an advocate matters.<br>If you’re not familiar, the terms “Advocate” and “Evangelist” are used across the developer relations space as a title of folks in this function. Sometimes they’re used interchangeably. I think they shouldn’t. A lot of folks may have differing opinions on this, but, to me, an evangelist is one-way: company outward to community. “Here’s what we built, here’s why it’s great.” Contrast that with an advocate who works in both directions; they’re carrying the company’s contributions outward to the community, but they’re also bringing the community’s needs and feedback back inward to the company.<br>Traditional developer relations teams may be able to function with evangelists. Open source developer relations teams absolutely cannot. If you’re not bringing community signal back to the company and acting on it, you’re not advocating—you’re broadcasting. And broadcasting without listening destroys credibility in open source contexts fast.<br>How it differs from product developer relations

So open source developer relations is a distinct thing from traditional developer relations. But let’s make it clear how.<br>The success of a traditional developer relations team is ultimately driven by product adoption. You measure awareness, activation, engagement, and conversion; however you slice the funnel, the goal is getting developers to use your product. That’s legitimate work, and it requires real skill.<br>An open source developer relations team’s success is driven and measured by community health and the company’s standing within it. The work they do helps to move the needle on and answer questions like: Are you seen as a credible participant? Is your company’s contribution to the project valued? Do people trust your team’s presence in the community? or Are you supporting the project and making the ecosystem healthier?<br>These are different questions with different answers and, importantly, different timelines. Product developer relations can show results in a quarter. Whereas an open source developer relations team often takes a year or more to produce the kind of trust and standing that translates into tangible outcomes.<br>This isn’t a value judgment. Both functions matter. But conflating them, e.g. measuring open source developer advocates by product...