If you’ve read this far in the series, you now have four engagement archetypes—the Adopter, the Champion, the Business, and the Founder—each with distinct tactics, metrics, and anti-patterns. But there’s one more thing this framework needs to address, and it’s arguably the most important insight of all:
Your archetype is not permanent.
When it changes, your playbook has to change with it.
This is what I call model drift. It’s where most companies get into trouble—not because they chose the wrong archetype initially, but because they didn’t notice when the ground shifted beneath them.
Model drift: two forms
Model drift comes in two flavors, and they break things in different ways.
1. Your engagement model shifts within a project
The four diagnostic factors—commercial dependency, project maturity, ownership, and strategic intent—are probably not going to be static. They will change as your company evolves, as the project matures, and as the market shifts around you. When enough factors change, your archetype changes too. Whether you acknowledge it or not.
Here are some patterns I’ve seen:
Adopter → Champion
A company starts as a vocal user to build their reputation in the project. Over time, maybe they hire maintainers, start contributing code, or participate in governance. In this case, their commercial dependency hasn’t changed, but their ownership and strategic intent have deepened. They’ve drifted from Adopter to Champion—and if they don’t update their tactics accordingly, the community will expect more from them than they’re delivering.
What does that mismatch look like in practice? As an Adopter, the tactics are about visibility: attending events, presenting talks, writing blog posts about your usage, and engaging in community channels with production feedback. That was enough. But once you’ve hired maintainers and are actively shaping the project, the community expects Champion-level engagement: reviewing PRs from other contributors, mentoring newcomers, participating in governance discussions, co-authoring proposals, and investing in the project’s infrastructure—not just telling stories about how you use it. If you’re operating at Champion-level ownership but still showing up with Adopter-level tactics, the community will notice the gap between your influence and your contribution.
Champion → Business
A company starts by championing a project—investing in its health, contributing engineering resources, building customer confidence around it. Then they start monetizing it directly. Maybe they offer a managed version. Maybe it becomes a core part of their commercial product rather than a complementary integration.
What changes tactically? As a Champion, your engagement was about stewardship: contributing code, reviewing PRs, growing the contributor base, showing up in governance—all without the community needing to worry about your commercial motivations. But once you’re monetizing the project, the expectations shift. The community now expects transparency about what’s proprietary versus what’s upstream.
If you’re operating with Business-level commercial dependency but still showing up with Champion-level tactics—contributing and stewarding but not addressing the elephant in the room that you’re now making money from this—the community will fill in the gaps with assumptions. And those assumptions are rarely generous.
Personal Aside. The Champion to Business shift is one that I’m watching in real time. Snowflake’s engagement with Apache Iceberg™ started as the Champion model—customer-driven, focused on open standards, demonstrating commitment to the project’s health. But as we’ve begun offering managed Iceberg tables directly within our platform, the commercial dependency is increasing. The factors are shifting. I don’t think we’ve fully crossed into Business territory yet, but the direction is clear. I’m acknowledging that shift and actively adjusting how we engage with the community so that we don’t risk a credibility gap.
Founder → Champion (or Business)
A company open-sources a project, builds the initial community, and eventually the project matures enough that the company’s role naturally evolves. They’re no longer building from zero—they’re stewarding something established. The Founder phase ends. What comes next depends on whether they monetize it (Business) or support it without direct revenue dependency (Champion).
What changes tactically? As a Founder, your engagement was about bootstrapping: creating contributor onramps, writing documentation, being obsessively responsive to every early contributor, running community meetings, and actively recruiting adopters. You were doing everything because nobody else was there to do it.
But once the project has matured and there are external maintainers, an active contributor base, and established governance, the community no longer needs you to do everything. They need you to step back and let others lead. Your tactics shift from building to sustaining: supporting the governance structures rather than driving them, mentoring new maintainers rather than being the only reviewer, and investing in community health rather than community creation. If you’re still operating in Founder mode when the project has outgrown that phase, you’re holding the community back rather than enabling it, plus you may be doing more work than is necessary.
2. Same archetype, different project
Lifting and shifting a strategy that works with one project to another will fail. Almost every time.
Every open source community has its own norms, its own communication patterns, its own established leaders, and its own history with commercial players. The meetup format that works in one community may feel completely foreign in another. The relationship-building patterns that earned trust in one ecosystem may not even register in the next. A community’s expectations for how a company in your archetype should show up are shaped by their history—not yours.
The assumption that credibility earned in one community carries over to another is one of the most common mistakes in open source engagement. It doesn’t. Trust is earned project-by-project and community-by-community. You start from zero every time.
This is what I mean when I say the playbook is non-transferrable. It’s not just that archetypes are different from each other. It’s that even the same archetype, applied to a different community, requires starting over.
And on a more personal note, I’d say that you owe it to the community to learn how they want to be engaged with before you show up with a pre-built plan. Listen first. Observe how decisions get made, where conversations happen, what the community values. Your playbook from the last project can serve as a starting point for your own thinking. It just can’t be a template you impose.
Personal Aside. This is the form of drift that hit me hardest personally. When Confluent expanded from Apache Kafka® into Apache Flink®, we were entering a new project’s community in the same archetype (The Business). There was an implicit assumption that our standing and credibility in the Kafka ecosystem would carry over.
It didn’t. The Flink community had different geographic centers, different communication norms, different meeting cultures. The approach to meetups, the rhythm of engagement, even the relationship-building patterns were entirely different from what had worked in Kafka’s community. None of that cared about what Confluent had built in the Kafka world.
I had to start from zero. Build relationships one by one. Learn the norms before trying to influence anything. It was a hard reset—and the clearest proof I have that trust doesn’t transfer.
Warning signs that drift is happening
Model drift tends to creep in over time. But there are signals, and if you’re paying attention, you can catch it before the community does
Your existing tactics stop producing results. The meetup format that used to draw 50 people now draws 15. The blog posts that used to generate engagement get crickets. The conference talks that used to land don’t resonate. You haven’t changed anything, but something external has shifted. Has the project matured beyond what you’re offering? Is someone else serving the community differently?
Internal stakeholders start asking questions your current model can’t answer. If you’re engaging as a Champion—where direct revenue isn’t the point—and leadership starts asking pointed questions about ROI and monetization, that’s a signal that internal priorities are drifting toward the Business model. Or if you started as a Founder, but the project has matured to the point where it doesn’t need hand-holding, internally the company may start asking why so many resources are still dedicated. Listen to the questions being asked. They reveal where the company is heading, even if nobody has said it out loud yet.
Community expectations shift. In every engagement model, it’s critical to keep tabs on what the community actually needs. A project might reach critical mass where they don’t need more contributors—they need better tooling, governance reform, or financial support. Or if you’re an Adopter, the project you’re championing might be getting sunsetted. Check in. Be ready to pivot. Community needs evolve, and your engagement needs to evolve with them.
The competitive landscape changes around you. A competitor acquiring key maintainers. A new company entering the ecosystem with deep pockets. A foundation restructuring governance. These external shifts can change the dynamics of your engagement even if nothing about your company has changed. The landscape you built your playbook for no longer exists.
A strategic decision forces it. An acquisition. A new product launch. A donation to a foundation. A license change. These are the most obvious triggers, and they’re sudden and visible. But they’re often the result of drift that’s been happening quietly for months. By the time a strategic event makes the shift official, the community has usually already noticed.
Same metric, different meaning
There’s one more concept I want to leave you with, because it ties everything in this series together.
Throughout these posts, I’ve referenced CHAOSS metrics—organizational diversity, contributor counts, time to first response, elephant factor, and others. These are standardized, well-defined metrics. But, critically, the same metric means something fundamentally different depending on which archetype you’re operating in.
Take organizational diversity—the metric that measures how many different organizations contribute to a project.
The Adopter tracks organizational diversity to monitor the health of a dependency. They’re asking, “Is this project I depend on dangerously reliant on one company? Is my dependency at risk?”
The Champion tracks organizational diversity to measure their own strategic impact. They’re asking questions like, “Are we growing the project’s contributor base? Are more companies showing up? Are we successfully diversifying contributions away from any single dominant player—including ourselves?”
The Business tracks organizational diversity as a dominance warning signal. Their concerns sound more like, “Are we too dominant?” and “Are competitors growing their influence in ways we should be aware of?”
The Founder tracks organizational diversity as the existential question. They want to know, “Has anyone beyond our company shown up yet? Is this project sustainable.”
Same metric. Same data. Four completely different types of questions being asked.
This is why you can’t just copy another company’s dashboard. Their metrics might be identical to yours, but what those metrics mean for their engagement model is entirely different from what they mean for yours. And the actions each individual company takes to try to influence that metric will be wildly different.
Why “non-transferrable”
I chose the name of this series deliberately. The playbook is non-transferrable in three dimensions:
Between archetypes. What works for the Adopter doesn’t work for the Business. The tactics, metrics, and expectations are fundamentally different.
Between projects within the same archetype. Even if your company has an established playbook in one project, trust is earned per-community, not per-company.
Over time within the same project. What worked last year may not work next year if your factors have shifted. Model drift is real, and the community notices before you do.
If there’s one thing I hope this series has given you, it’s a diagnostic. A way to look at your company’s relationship to any open source project and ask: What archetype are we actually operating in? Are our tactics aligned with that reality? And are the factors still what we think they are?
If you can answer those questions honestly, you’re already ahead of most companies engaging with open source.
A closing thought
I’ve spent a lot of my career navigating these models—sometimes intentionally, sometimes by stumbling into them and learning from what went wrong. From Bloomberg to Confluent to Snowflake, across Kafka, Flink, Iceberg, and Polaris, the one constant has been this: the moment you assume your playbook transfers, you’re about to lose the community’s trust.
Open source engagement isn’t something you can systematize once and forget. It requires ongoing attention, honest self-assessment, and the humility to start over when the context changes.
If you’re reading this and recognizing your own situation in these pages, you’re already off to a good start. That awareness is the hardest part. The framework exists now. Use it.
Thank you for coming along and reading the series. I’d love to hear which archetype you think your company is operating in—and whether you’ve experienced model drift yourself. Drop a comment below or reach out!
And if you found this valuable, please subscribe for more and share it with someone whose company is engaging with open source and might benefit from thinking about it more deliberately.