Why "On Purpose"?

I just got back from Open Source Summit North America where I gave a talk called “The Non-Transferrable Playbook: Advocacy Models for Open Source.” And the response kind of blew me away. Folks immediately followed up questions about their own companies and projects. They’re eager to see the slides, share the video. Some asked to schedule deeper follow-up conversations.

The thing that struck me wasn’t just that they liked the talk. It was that so many folks told me they’d never seen anyone try to put structure around how companies engage with open source. They knew that engaging with open source was important, but they had been feeling the pain of mismatched strategies—copying what other companies do, measuring the wrong things, showing up in communities without understanding their role—but didn’t have a framework to diagnose what might be going wrong.

That’s what convinced me this needed a longer-form home. Thirty minutes on stage isn’t enough to go deep. And the conversations I had afterward made it clear that there’s an appetite for more.

What this is

“Open Source, On Purpose” is a newsletter about the intentional work of engaging with open source—whether that’s as a company, as a team, or as an individual.

It’s not a tutorial blog. It’s not project release notes. It’s the strategic and human layer underneath. In it, we’ll explore how to show up in a community authentically, how to measure what you’re doing and know what’s working, and how to avoid the traps that make companies look clueless (or worse, extractive) in open source spaces.

I’ll write about engagement strategy, community dynamics, contribution approaches, and the real challenges of doing this work well. Sometimes that’ll be frameworks and models. Sometimes it’ll be practical guidance on how to get started contributing to a project. Sometimes it’ll just be observations from doing this work every day.

Who I am

I’m Danica Fine. I lead Open Source Developer Relations at Snowflake, where I set the strategy for how we engage with open source communities and projects.

Before Snowflake, I started my developer advocacy journey at Confluent, championing Apache Kafka® and then navigating their expansion into the Apache Flink® community— which turned out to be a completely different playbook. Before that, I was a software engineer at Bloomberg, building Kafka Streams and Kafka Connect pipelines and accidentally falling into advocacy when our team started giving talks to recruit engineers and build visibility.

That career arc—engineer to advocate to strategist, across four different engagement models—is what led me to the framework I’ll be writing about here. I’ve lived the problem of trying to apply one playbook to a different context and watching it fail.

Who this is for

Anyone whose company participates in open source and wants to do it well. That includes:

• Developer Relations practitioners and advocates trying to figure out the right strategy for their situation

• Engineers who already contribute to or maintain open source projects and want to think more deliberately about engagement as well as those who want to get involved

• Engineering leaders and OSPO folks deciding where and how to invest in open source

• Anyone who’s ever felt like their company’s open source engagement is unfocused or performative and wants to fix that

What’s coming first

I’m kicking things off with a series called “The Non-Transferrable OSS Playbook”—a deep dive into four open source engagement archetypes, the tactics and metrics that matter for each, and why success in one model can’t be blindly copied to another. It’s an expansion of my Open Source Summit talk with significantly more depth than thirty minutes allows.

After that? We’ll see where it goes. I have a lot of thoughts, and I hope you’ll come along.