Open source is built on community.
That’s not a feel-good platitude. It’s baked into the structure of open source as a whole. The code lives in public. The roadmap is shaped by contributors. The project’s health depends on people outside your company showing up, engaging, and investing their time. Which means that, if your company is participating in open source in any capacity, community engagement isn’t just some nice-to-have. It’s a requirement for doing open source at all.
Every company that does open source needs some form of developer advocacy—whether they have a formal DevRel team or not. The question isn’t ’Should we engage with this community?’ It’s ’How should we engage, given our specific situation?’
And if you’re anything like most companies I’ve seen and worked with, you’ve probably looked at what other companies do in open source and tried to replicate their approach. I’m here to tell you that’s probably not working. And I think I know why.
The standard playbook doesn't apply here
There’s a well-established developer relations playbook that works great for products: drive awareness, drive adoption, measure signups, measure conversion, grow usage. Profit. Rinse and repeat.
But open source isn’t a product. Open source is a living, breathing thing based on a community. And that community isn’t necessarily your funnel.
So if the standard product developer relations playbook doesn’t apply in this case, what does?
Looking back, I’ve actually spent quite a bit of my career wrestling with this question—at Bloomberg as a software engineer where I found myself advocating for Apache Kafka®, at Confluent as a developer advocate for both Kafka and Apache Flink®, and now at Snowflake where I lead Open Source Developer Relations, working across and setting strategies for more open source projects than I ever dreamed possible.
And honestly, the answer isn’t one playbook.
Instead, what you do is defined by your specific circumstances. Your company’s current situation and how they view a project dictates everything about how you should show up. And what works in one configuration often fails in another.
A diagnostic tool: four factors
Before I introduce the engagement models themselves (those come in the following posts of this series), I want to give you a diagnostic tool. In my experience, there are four main factors that determine where your company sits in its relationship to any given open source project.
As you read through these, think about your own organization and the open source projects you interact with.
1. Commercial dependency
How dependent is your business on the project?
Is this open source project something your company’s revenue depends on? Are you building a product around it? Or could your business exist perfectly well without it?
It’s a popular model to build a company around an open source technology, offering a managed version of it—the Confluents or the ClickHouses of the world. That’s one end of the spectrum. But for so many other companies, their goal isn’t to monetize the open source technology directly. Instead, they’re building on top of it and using it somewhere internally. As such, they have a vested interest in that project continuing to exist and evolving in a healthy way. That’s the other end of the spectrum.
Where you sit here fundamentally changes what you need from the community and what the community expects from you.
2. Project and community maturity
How mature is the open source project and its community?
Are you engaging with a project that has thousands of contributors, years of history, established governance, and strong Opinions™ about how things should work? Or are you starting something new where none of that exists yet?
This changes how you’ll engage with the technology and even how you’ll talk about it. With a mature project, your job is to figure out how this community operates and find your place in it—in the least disruptive way possible. With a new project, there’s nothing to discover. Instead, you have to design it and usher it along.
3. Level of ownership
What is your level of ownership over the project?
Are you an end-user who happens to talk about the project externally? A regular contributor? A maintainer or PMC member shaping the project’s direction? Or did your company literally create this thing and donate it?
Each level comes with different credibility, different expectations from the community, and different responsibilities.
4. Strategic intent
What is your intent in engaging with this project?
Why is your company investing in engaging with this community? Is it to recruit engineers? To grow a product? To build reputation? To demonstrate commitment to a project because your customers are demanding it? ... or something else entirely?
There’s no wrong answer here. But it’s critical that you answer this question honestly and that you know exactly why your company is choosing to get involved. Keep in mind that the community will figure it out whether you tell them or not.
Four factors, four archetypes
Most of these factors—commercial dependency, project maturity, ownership level, strategic intent—are more of a spectrum, meaning there are infinite combinations. But, in my experience, there are four common engagement archetypes that companies tend to align with. Each has distinct tactics, metrics, and pitfalls.
The Adopter A company that uses an open source project and advocates for it externally. They’re not trying to run the project. They’re not selling something based on it. They’re users who have chosen to be vocal.
The Champion A company that serves as a major contributor to a project, and whose core business doesn’t necessarily depend on it. They’re investing heavily because their customers or their ecosystem strategy demands it.
The Business A company that has built a commercial offering around an open source project. Their revenue is directly tied to the project’s success, and every move they make is scrutinized.
The Founder A company that has open-sourced a new project and is building its community from zero. No existing users. No existing contributors. No established norms. Just code and a vision.
These aren’t rigid categories, but they’re common patterns. Some companies shift between them over time (more on that in the final post in this series). Some companies can be in multiple archetypes simultaneously for different projects—and that’s key.
The core thesis
What works in one archetype will not transfer cleanly to another. An Adopter measuring themselves like a Business will waste resources. A Founder engaging like a Champion will wonder why nobody shows up.
The playbook is non-transferrable. But the framework for diagnosing where you are and building your own playbook—that’s what this series is about.
What's coming next
In the rest of this series, I'll deep-dive into each archetype. You'll learn the tactics that work, the metrics that matter (grounded in the CHAOSS project's community health metrics), and the pitfalls to avoid:
- Part 2: The Adopter Advocating for OSS you use but don't own
- Part 3: The Champion Investing in OSS your business doesn't depend on
- Part 4: The Business Building a company around open source
- Part 5: The Founder Building an OSS community from zero
- Part 6: Model Drift Why it all breaks when you switch contexts
Before you read on, think about one open source project your company engages with. Where does it sit on each of the four factors? Hold onto those as we go deeper into each model in the posts ahead.
