The Founder is a company that has open-sourced a new project and is now responsible for building a community around it from zero.
Maybe the project started as an internal tool. Maybe it was built specifically to be open-sourced. Either way, the situation is the same: no existing users, no existing contributors, and no established norms. Just code and a vision.
Of the four archetypes, this one is the most effort—and the most rewarding when it works.
The factor profile
Where does the Founder sit on the four diagnostic factors?
Commercial dependency: Varies
Some Founders have a clear commercial angle—the open source project feeds a product pipeline or ecosystem strategy. Others are open-sourcing for strategic, reputational, or ecosystem reasons without direct monetization. But generally speaking, commercial dependency should be low-to-mid. If it’s too high, we’re bordering on the territory of the Business.
Project maturity: Nascent
This is the defining characteristic. The project is new. There is no community or user base yet—or it’s so small that it may as well not exist. Everything about the community has to be built deliberately.
Ownership: Owner… for now
The founding company created the project. They have the highest possible ownership at the outset. But the entire challenge of this archetype is figuring out how to responsibly transfer that ownership to a broader community over time.
Strategic intent: Adoption, independence, and sustainability
As a reminder, “strategic intent” here refers to the why behind a company’s engagement with an open source project. But for the Founder, that question is more complex, and the why of engaging with the community is closely intertwined with the why of open-sourcing the project in the first place.
And the honest answer to that second question is often commercial. A company might open-source a project to attract adoption, to build ecosystem lock-in, to serve customers who are asking for it, or to establish presence in a new community. Those are all legitimate motivations.
But those motivations work best when they’re in service of a larger goal: building something that is genuinely useful, widely-adopted, and self-sustaining. A project open-sourced purely to serve a short-term commercial purpose, without real investment in its long-term independence, will eventually be recognized as such by the community.
So, if the founding company has the project’s best interests at heart, their strategic intent—underneath whatever commercial motivations exist—is to build something that can stand on its own. Remember that a project that can’t survive without the founding company isn’t truly open source. It’s a corporate project with a permissive license.
And, at the risk of going on a tangent here, this isn’t a judgment on companies that choose not to build a community around their code. There are legitimate reasons to release source code publicly without the goal of growing an independent contributor ecosystem—for transparency, for customer trust, for developer familiarity, or what-have-you. But that’s a different thing. Call it source-available. Call it an open-core reference implementation. Call it public source. Be transparent about what it is and what your intentions are.
What’s damaging to the ecosystem—and to your reputation—is presenting a project as an open source community initiative when it’s not. The community will figure it out. And when they do, the trust you needed to grow that project will be gone.
Please pause for a moment of reflection. If you find yourself in the Founder archetype and your strategic intent does not involve growing project adoption and building a sustainable long-term vision for this project, then please, please, please ask yourself why you open-sourced this project in the first place.
What makes this archetype fundamentally different
In every other model, there’s an existing community. Your job is to figure out how that community operates. Learn what channels they use, what norms they follow, how decisions get made… and then you find your place within it—ideally, in the least disruptive way possible.
As a Founder, none of that exists. There’s no community to discover. You have to design it from scratch.
What does governance look like? How do people contribute? What does the decision-making process look like? Where does the community gather? How do you handle conflicts? What counts as a meaningful contribution? You’re not just writing code—you’re architecting a social system.
This is harder than it sounds. It’s also one of the most important decisions you’ll make, because the governance model you choose in the early days will shape the community’s culture for years.
The governance bet
Every Founder is making a bet that they have designed a governance model that’s strong enough to create genuine independence—where external contributors feel real ownership and the community can make real decisions—but structured enough that the project doesn’t lose coherence or drift in a direction that no longer serves anyone.
And that’s a hard line to walk.
Too much control, and the community never develops real ownership. Everything runs through the founding company. New contributors feel like guests rather than participants. The project can’t attract the independent stewards it needs to survive long-term.
Too little structure, and the project fragments. Without clear governance, decision-making becomes chaotic, conflicts go unresolved, and contributors don’t know what’s expected of them. The community either splinters or stagnates.
You’re betting that the system you design can hold together as the project grows beyond you.
Open source foundations as governance partners
This is where open source foundations become genuinely valuable—not as a marketing move or a badge of legitimacy, but as a practical resource for Founders who are building governance for the first time.
Organizations like the Linux Foundation, the Apache Software Foundation, and the Cloud Native Computing Foundation have spent years developing governance models, contributor agreements, decision-making frameworks, and community norms. They’ve seen what works and what breaks. Donating a project to one of these foundations or using their governance frameworks as a starting point gives you a proven structure rather than asking you to invent one from scratch.
It’s not the only way. Some projects govern themselves successfully outside of foundations. But for most Founders, especially those without prior experience building open source communities, a foundation partnership is one of the highest-leverage decisions you can make early on.
Personal Aside I joined Snowflake’s open source team after Apache Polaris™ had already made its initial debut as an open source project, so I didn’t experience the “day one” of the Founder model firsthand. But I came in at an early stage, when the community was still nascent and the work was very much about growing it from that initial state toward something self-sustaining.
What struck me was how much deliberate effort it takes—and how different it is from every other form of community engagement I’d done. (And that’s not say that other forms of open source advocacy aren’t deliberate and full of effort!) With the advocacy that I’d done for Apache Kafka® and Apache Iceberg™, there was already a community to learn from and participate in. With Polaris, we were writing the norms as we went. Thankfully we had adjacent communities to look to for support and reference. But the release materials, the contributor experience, how we brought the community together—all of it required intentionality that you don’t have to apply in the same way when you’re joining an established project.
Tactics: what the work actually looks like
The Founder’s primary job is community-building. Everything else is secondary.
Create contributor onramps. Write the first-contribution guides. Tag issues as good-first-issue. Document the contribution process clearly and keep it up-to-date. Lower the barrier to participation as much as possible, because, for a new project, the cost of a confusing onramp is a permanently lost contributor. And then once you’ve drafted new contributor guides, be deliberate and look for potential future contributors starting with your user base.
On that note…
Grow the user base through technical content. Nobody knows this project exists yet. Your job is to change that. Write blog posts, give talks, publish tutorials, share benchmarks. Make it easy for potential users to evaluate the project and understand what problem it solves. Then figure out where those potential users already are and post the content there. Look at where this new project is situated in the ecosystem, find a similar project, work tangentially to garner interest.
Be obsessively responsive to early contributors. I cannot emphasize this one enough. This is non-negotiable. Someone who submits their first PR and waits two weeks for a review likely isn’t coming back. You get one shot with early contributors. Responsiveness in the early days directly determines whether you build a community or a graveyard of stale PRs.
Run community meetings. Don’t wait for the community to organize itself—create the spaces. Schedule regular sync calls, governance discussions, and/or office hours. Consider hosting meetups once you have a user base. Make participation visible and accessible.
And again, because it’s important…
Actively reach out to potential adopters. You’re not waiting for people to find you. You’re going to them. Identify companies that would benefit from this project, engage with them, bring them into the community. The early adopters who show up and invest are often the ones who become your first external maintainers.
Nurture the broader ecosystem. Make the project sticky. Support integrations, encourage tooling, celebrate companies that build on top of the project, because a healthy ecosystem is what turns an interesting project into one that companies depend on—which is what makes community growth self-sustaining.
Measuring success
The core question for the Founder is simple: are we moving from “just us” to “genuinely community-driven”? Everything else flows from that.
CHAOSS metrics for the Founder
Project Engagement. This model measures the sustainability of a project based on developer activity:
The D0 → D1 → D2 funnel. This is the most important metric for a new project. It looks at interested people who’ve starred or forked the project (D0), active people filing issues, commenting, doing code reviews (D1), and engaged people who’ve actually committed code (D2). For the Founder, it’s important to see people moving through this funnel. If you have a thousand stars but zero external PRs, you don’t have a community—you have an audience. The goal is progression, not just awareness.
Organizational Diversity. Are companies beyond the founding company showing up? If after a year it’s still 95% your engineers, you haven’t built a community. You’ve built a corporate project with a permissive license.
Community Welcomingness. This helps to evaluate whether a community is welcoming to newcomers:
New Contributors. For a new project, this is existential. If new contributors aren’t showing up, the community isn’t growing. Track this monthly and take it seriously when it stalls.
Time to First Response. Watch this obsessively. The CHAOSS Development Responsiveness model makes clear that slow response times kill new contributor relationships permanently. Responsiveness isn’t just good manners—it’s the single biggest lever you have for retaining early contributors.
Contributor Absence Factor. How many people make up 50% of contributions? If that number is very low—or if those people all work for the founding company—the project is fragile. Watch this grow over time as a signal that the community is developing real depth.
The long-term test
The metrics above give you signals. But the question that ties them all together is:
Would this project survive if the founding company stepped back?
No single dashboard number captures it. It’s a judgment call you have to make by looking at the full picture. Ask it regularly. Take the answer seriously.
If the answer is no and the project depends entirely on the founding company’s engineers, roadmap, and resources—then you haven’t yet built a community. You’ve built a dependency.
The key insight: For the Founder, success looks different than it does for any other archetype. You’re asking a much more difficult, much squishier question: Is this project becoming independent of us? If the answer keeps moving toward yes, you’re doing it right.
Anti-patterns to watch for
Assuming people will show up because the code is good. Code quality gets you downloads. Community gets you contributors. They’re different things, and they require different investments. Don’t confuse one for the other.
Treating governance as an afterthought. “We’ll figure it out when we’re bigger” is how projects fragment. The governance decisions you make (or avoid making) in the early days set cultural precedents that are hard to undo. Do it deliberately, do it early.
And taking it a step further…
Designing governance that looks open but is functionally controlled. A governance structure where the founding company has effective veto power over all decisions, even if it’s not written that way, is still a controlled project. The community will figure this out. Design governance that is genuinely open, not just open-appearing.
Not responding to early contributors fast enough. Said above but worth repeating—this one failure mode kills more early communities than anything else.
Keeping all maintainer roles internal. If only employees of the founding company can merge code or make governance decisions, external contributors will correctly perceive the project as not truly open—or worse, “open-washed.” Elevating external contributors to maintainer roles is one of the most important signals you can send.
Examples in the wild
Snowflake + Apache Polaris™: Open-sourced as an open catalog implementation for Apache Iceberg™ and donated to the Apache Software Foundation where it successfully graduated from the Apache Incubator. Now gaining genuine community traction with external contributors and broad vendor adoption.
Meta + React: Open-sourced in 2013, built the community deliberately, and now React has a contributor base and ecosystem far larger than Meta’s direct investment. A textbook Founder success story.
Uber + Jaeger: Built internally for distributed tracing, open sourced, donated to the CNCF, and graduated as a CNCF project—meaning it achieved the level of maturity and community independence the CNCF requires.
The Founder in context
The Founder model is the most labor-intensive of the four archetypes—and the most fragile in the early stages. You’re building community from nothing, which means every early contributor matters, every governance decision compounds, and every slow response to a PR costs you more than it would in an established project.
But when it works, it’s one of the most valuable things a company can contribute to the open source ecosystem. Creating a new project that becomes genuinely community-driven, that attracts contributors from competing companies, that develops governance independent of its founding organization—that’s rare. And it creates lasting value for the ecosystem that outlives any individual company’s commercial interests.
The key is remembering that “Founder” is a phase, not a permanent identity. The goal is to build something that eventually no longer needs you to lead it. That’s not a loss—that’s the whole point.
Next up: the final post in the series—when things change, why you need to know your archetype, and why trust doesn’t transfer between communities. Subscribe so you don’t miss it.