Becoming an Open Source Champion

Every successful open source adoption has a champion — someone who pushed past organizational inertia to make it happen.

I've been that person multiple times. Here's what I've learned.

What Champions Actually Do

It's not just about using open source yourself. Champions:

1. Identify high-value opportunities — Where would OSS solve real problems?
2. Build internal coalitions — Find allies across teams
3. Manage risk perception — Address security, licensing, and support concerns
4. Create success stories — Document wins to build momentum
5. Establish sustainable practices — Move from ad-hoc adoption to institutional capacity

Starting Points

Find the Pain

Don't start with "we should use more open source." Start with "this proprietary tool is costing us $X and limiting us in Y ways."

Open source adoption follows pain points. Find the pain first.

Build a Small Win

Pick a project where:

• The OSS alternative is clearly superior
• The risk of failure is low
• Success will be visible to others

One successful deployment teaches more than ten slide decks.

Document Everything

Write down what you did, why it worked, and what you'd do differently. This becomes ammunition for the next project.

Talking to Executives

Executives care about:

• Cost — How much does this save vs. the alternative?
• Risk — What's the downside? How do we mitigate it?
• Speed — Will this make us faster or slower?
• Talent — Does this help us attract or retain engineers?

Frame every conversation in these terms.

Avoid:

• "The community is great" (they don't care)
• "It's the right thing to do" (they need business justification)
• Technical details (keep it outcome-focused)

The TODO Group provides excellent resources for establishing Open Source Program Offices.^[1] For the philosophical foundation, Eric Raymond's The Cathedral and the Bazaar remains essential reading.^[2]

Sustaining Momentum

One project is a fluke. Two is a pattern. Three is a strategy.

Your goal is to move from "Ry convinced us to try this" to "we have a process for evaluating and adopting OSS."

That means:

• Guidelines — When is OSS appropriate? What's the evaluation criteria?
• Resources — Who owns the relationship with key projects?
• Contribution policy — Can we contribute back? Under what terms?

The Long Game

The best champions work themselves out of a job. Success looks like:

• OSS is a default consideration, not an exception
• Multiple people can evaluate and champion projects
• The organization contributes back, not just consumes

That's when you've built real capacity.

---

Being an OSS champion at Astronomer is what led me to Tembo. The pattern repeats: find technology that changes the game, then build a company that makes it accessible.