What Is Open Source Developer Relations?
It's not the same function with a different label
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).
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.
In this post, I’d like to share how I think about open source developer relations.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
This isn’t a value judgment. Both functions matter. But conflating them, e.g. measuring open source developer advocates by product developer relations metrics, is one of the fastest ways to kill an open source developer relations program’s credibility.
All that said, open source developer relations absolutely can influence the business metrics leadership cares about—it’s just a lagging indicator. The same activities that build credibility in a community are the ones that support your customers. When you’re creating resources that show how your product integrates with an open source project or where it’s positioned in the ecosystem, you’re helping existing and potential customers understand how their architectures fit. When your advocates are trusted voices in a community, engineers in that community want to work at your company. When you earn a seat at the governance table, the project evolves in ways that are compatible with your product. These are real business outcomes. They just don’t show up in a quarterly funnel report.
The substrate for successful open source developer relations
Another key difference is that a successful open source motion takes more than just a few committed individuals. You can hire the right open source developer advocates, give them the right charter, measure them by the right metrics, and the function will still fail if the company around them isn’t set up to support it.
It takes a village
Open source developer relations doesn’t operate in a vacuum. It’s one piece of a broader open source engagement strategy. Without the supporting structure, your developer advocates are out there building credibility that the rest of the company undermines every time an engineer makes a tone-deaf PR comment or marketing publishes a blog that doesn’t respect an open source project or leadership makes a decision that contradicts the community’s interests.
An OSPO or equivalent strategic function. Someone needs to own the company’s overall open source strategy—which projects to engage with, how deeply, and why. An OSPO also critically defines policies on how employees interact with open source, both existing projects and new ones that your company may be releasing. Open source developer advocates execute within that strategy. Without it, they’re making ad-hoc decisions about where to spend their time with no strategic backing.
Engineering investment in open source. Open source developer relations can’t be the only team engaging with open source. If your advocates are building credibility in a community but your engineering teams aren’t contributing code, reviewing PRs, or participating in governance, the credibility is hollow. The community will ask “where are your engineers?” and the developer advocates won’t have a good answer.
Executive patience. Success in open source is a long game. The return on investment isn’t measured in quarters, it’s measured in years. If leadership expects open source developer relations to show product-tier ROI on a quarterly cadence, they’ll push the team toward inauthentic behavior that destroys the credibility they’re supposed to be building.
The right metrics. Measure open source developer advocates by community health indicators, not product conversion. Conference talk acceptances (and reception). Community sentiment. Contributor growth in your target projects. Responsiveness in community channels. Invitations to participate in governance and other areas of the community. Not MQLs from a talk at KubeCon.
Placing and building a motion
Although it’s important to have the entire company behind an open source motion with an open source developer relations team, it’s important to carefully consider where the team, itself, lives and how it’s built out.
Developer relations is notoriously flexible in where it can live in an organization. However, placement of an open source developer relations team should be done with intention. Open source developer advocates can live under marketing, but leadership needs to be careful to not require every piece of their content to go through brand review or force alignment with key launches. Open source developer relations team’s accountability is to the community first. That doesn’t mean they work against the company’s interests. It means they build the credibility that makes everything else the company does in open source land better. The same things should be taken into consideration if they’re reporting into a product-focussed function. Although in product, the open source team is more empowered to influence product direction in favor of open source, the team should be careful not to optimize only for proprietary features else they’ll see a tension pulling them away from the work that actually builds trust. And finally, placing a developer relations motion under engineering can be a natural fit, but the entire organization should be careful to ensure that the team still has agency over and support for its external-facing activities that may be more aligned with, say, marketing.
At the same time, hiring matters, too. The skill overlap between product developer relations and open source developer relations is real, but the orientation is different. Someone who’s great at driving product adoption may struggle in an open source context where there’s nothing to sell and the community is inherently skeptical of commercial motivations. Hire for community credibility, technical depth in the relevant ecosystem, and comfort with ambiguity—not for content production volume or funnel thinking.
It’s not just a developer relations problem
None of this is something a developer relations team can solve on its own. An open source developer relations team can do everything right—build presence, earn credibility, advocate in both directions—and still fail if the company around them doesn’t understand what they’re doing or why it takes time.
That’s the piece I keep coming back to. Open source developer relations isn’t a team you hire and then leave alone to produce results. It’s a function that requires the company to show up alongside it with engineering time, strategic clarity, patience, and metrics that actually reflect what community credibility looks like. Without that, you’re asking a small team to represent a commitment the rest of the organization hasn’t made.
I’m fortunate to be at a company that’s genuinely investing in this, that has the appetite to get open source engagement right, and that is building the supporting structure to make it work. That context is part of why I feel equipped to write about it. Not every open source developer relations practitioner has that, and I don’t take it for granted.
I’m still thinking through parts of this. But if there’s one thing I’m certain of, it’s that open source developer relations fails at companies that treat it as “just another developer relations team.” It’s not. And the difference matters.
If you’re working in or building an open source developer relations function, I’d genuinely love to hear how you’re thinking about it. What’s working? What’s not? Where does your company get it right, and where does it fall short? I’m still forming these ideas, and other perspectives make them sharper.
Interested in more writing on open source engagement—how companies show up in communities, what works, what doesn’t, and how to build the functions that make it sustainable? I write about it here. Subscribe to follow along.