The Adopter: Advocating for OSS You Use (But Don't Own)

The Adopter is a company that uses an open source project as a core part of its infrastructure but does not own or control the project. These organizations engage with the community by giving talks, writing about their experiences, and participating in channels, primarily to gain recruiting visibility and build their reputation. Their motivations are a mix of selfishness (recruiting, protecting a dependency) and community benefit (sharing real-world production use cases).

The Adopter is a company that uses an open source technology—it may very likely be a core part of their internal infrastructure—and they engage externally with that project's community. 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. If you've ever been to a conference and seen a talk titled something like "How ${BIG COMPANY} Uses ${OSS PROJECT} at Scale," you've seen the Adopter model in action. Most consumer companies that show up at open source conferences fall into this category. Where does the Adopter sit on the four diagnostic factors? For the most part, the Adopter's revenue doesn't come from this project. In many cases, if they so choose, they could likely replace this component of their infrastructure without any of their customers noticing. Adopters typically engage with more established, known projects rather than emerging ones. If they’re trusting a project enough to be embedded in their infrastructure, they want to know it’s stable. The Adopter is an end-user. Occasionally, they will engage with the project directly; for example, they might file issues, submit the occasional PR, or participate in community channels. But they're not maintainers. They're not steering the ship. And they don't intend to. They want the community to know who they are, what they're building, and, frankly, they want talented engineers who are familiar with the open source project to want to come join their engineering teams. The Adopter model often starts as a grassroots effort. It's not a top-down strategic initiative from the C-suite. It's a team of engineers who bet on a technology, built something meaningful with it, and realized their team could benefit from being visible in that project's community. And it grows from there. The motivations are usually some combination of: This is an archetype I lived during my time as a software engineer at Bloomberg. After extensive research, my team had made the decision to use Kafka Streams for processing market data, and so began our foray into the Apache Kafka® community. Our manager encouraged us to give talks—for visibility in the community, for recruiting, and to build Bloomberg’s reputation as a company doing cutting-edge work with streaming technologies. That grassroots, team-driven origin is typical of the Adopter model. The Adopter's playbook is the most straightforward of the four archetypes: Attend and present at community events. Show up to the conferences, meetups, and community days for the project you use. Don't just attend—submit talks. Share what you're building. The bar isn't "we did something nobody else has done." The bar is "here's what we learned using this thing in production." Write about your experiences. Blog posts, case studies, architecture breakdowns. Technical content that shares the patterns, challenges, and decisions you've made with the technology. This content is genuinely valuable to the community—it helps other users, validates the project's approach, and sometimes surfaces edge cases the maintainers hadn't considered. Engage in community channels. Answer questions in Slack, comment on GitHub issues with your real-world experience, provide feedback on proposals. You don't need to contribute code to be a valuable community member. Showing up with production context is a contribution in itself. Optional Provide financial support. Some Adopters sponsor the project’s foundation or events. This is legitimate and often appreciated—but a note of caution: once money enters the picture, internal stakeholders may start asking about ROI in ways that push the engagement from genuine to performative. Be aware of that pressure. I'll be honest—there's a degree of selfishness in the Adopter model. You're doing this for recruiting. For reputation. For protecting a dependency you rely on. And that's okay. Because the community benefits too. Real-world production use cases are gold for an open source project. When you stand up at a conference and say "we run this at scale and here's what we learned," that's valuable to everyone. It validates the project. It helps other users avoid pitfalls. It gives maintainers signal about how the software is actually used. The selfishness and the community benefit aren't in tension. They're aligned. That's what makes this model work. You get what you need visibility, hires, dependency health and the community gets what it needs production feedback, real use cases, engaged participants . How do you know your Adopter engagement is working? There are two layers here. Since the Adopter's goals are often self-interested, many companies in this position track their own internal signals: If you’re not familiar, the CHAOSS project is an effort to better understand open source projects and communities through rigorous, standardized metrics models for measuring community health. For the Adopter, two models are particularly relevant: Business Readiness. This model helps you assess whether the project you depend on is healthy enough to keep relying on: Project Awareness. This model tracks how well-known and actively engaged-with a project is: Key Insight For the Adopter, these metrics are about monitoring risk and validating your choice. You're asking "Is this project healthy enough to rely on?" not "Are we growing the community?" That distinction matters because the same metric can mean something very different in other archetypes. Even in the most straightforward archetype, things can go wrong: Talking without contributing. If your company only takes the stage but never participates, e.g. files issues, provides feedback, or engages in community channels, you'll eventually be seen as a tourist. You don't need to commit code, but you do need to participate beyond the spotlight moments. Treating it purely as marketing. The moment your “community engagement” starts feeling like a brand campaign—messaging that’s too polished, product placement, no genuine technical depth—the community sees through it as inauthentic. Adopter advocacy works because it’s engineers sharing engineering work. The second it becomes marketing-driven, it loses credibility. Ignoring project health. If you benefit from the project but never check on its sustainability—never look at whether maintainers are burning out, whether the bus factor is dangerously low, whether the project is losing contributors—you're freeloading. That dependency risk will catch up with you. Expecting influence without earning it. Being a high-profile user doesn’t automatically give you a seat at the governance table. Some Adopters get frustrated that their “big company voice” doesn’t translate into immediate bug fixes or project direction. That’s not how this works. Influence is earned through contribution, not brand weight. The Adopter model is often undervalued because it looks simple: show up, talk about your stuff, go home. But done well, it serves a critical function in the open source ecosystem by providing social proof, real-world validation, and production signal that projects need to grow. And for the company doing it? It’s one of the highest-ROI forms of developer engagement you can do. The investment is relatively low engineers sharing work they already did , the alignment between self-interest and community benefit is natural, and the risks are minimal compared to the other archetypes. Just remember: the playbook is non-transferrable. What works here—showing up as a user, sharing experience, recruiting through visibility—will not work if your company’s situation changes. If you start contributing heavily enough to become a steward, or if your commercial relationship to the project deepens, you’ve drifted into a different archetype. And you’ll need a different approach to continue showing up credibly. More on that in the final post of this series. Next up: The Champion—what happens when your company invests heavily in a project that isn’t core to its main business. Follow along so you don’t miss it.