On-screen

Narration

Anna: Now that we’ve wrapped the Te Hiku kōrero, let’s switch lenses to the mainstream open-source world. Governance in open source isn’t just paperwork; it’s how communities decide who shows up, who has a vote and how funding gets spent. Most projects start with one person saying “I’ll just share this script,” then suddenly hundreds of organisations rely on it. The structures we put around that growth determine whether the maintainer burns out or builds a sustainable ecosystem.
Greg: Treat this as a fresh thread, not a continuation of the Indigenous practice section. Think about governance as progressive scaffolding. You don’t pour concrete foundations for a garden shed, but you also don’t balance a skyscraper on a folding chair. For the coworking-sized projects in the middle, you need modular beams—enough structure to host dozens of teams without locking down every desk. As usage and contributions scale, the project needs sturdier guardrails, documented decision-making and support for the humans keeping the lights on.

On-screen

Narration

Anna: In the solo maintainer phase, governance is basically the maintainer’s judgment plus whatever norms they capture in the README. That works because decisions are fast, but it concentrates risk. If they get sick or start a new job, issues and security patches stall. I like asking solo maintainers to publish a roadmap and contributor expectations so the community knows how to help.
Greg: Another practical step is to recruit lieutenants. Give a few trusted contributors triage or release permissions, even on a trial basis. Speaking of lieutenants, how do you actually identify who to trust? Start with the folks who reliably follow contribution guidelines, communicate edge cases and respect boundaries. It lowers the bus factor and gives the maintainer a support network before stress turns into burnout. And by “stress” we mean the 3am “the server is down and only I know the deployment password” kind of stress.

On-screen

Narration

Anna: Once you have three to ten maintainers, things shift to a core team model. That’s where you add deliberate roles—reviewers, release leads, community moderators—and rotate them so nobody becomes the bottleneck. It also helps to document how decisions get recorded. Lazy consensus, for example, means proposals pass unless someone objects within a set timeframe.
Greg: The key is transparency. Publish decision logs in GitHub Discussions or a public Notion space so contributors can follow the reasoning. Before the restructure, Eugen was juggling everything from code reviews to harassment reports—there was no sustainable separation of duties. Projects like Mastodon grew healthier when they defined working groups for moderation, infrastructure and community, instead of relying on late-night DMs with the founder.

On-screen

Narration

Anna: When projects hit enterprise scale, they often seek a foundation or fiscal sponsor. That legal wrapper handles trademarks, bank accounts and insurance while letting maintainers stay focused on the code. Foundations typically set up a board plus a technical steering committee, which keeps roadmap authority with engineers but adds accountability and succession planning.
Greg: Membership tiers and contributor licence agreements might feel bureaucratic, yet they unlock grants, corporate dues and formal code of conduct enforcement. Think about the CNCF or Apache—they provide neutral infrastructure, security audits and marketing muscle, which are hard to sustain as volunteers once Fortune 500 companies depend on your project.

On-screen

Narration

Anna: How do you know it’s time to formalise governance? Look for pain signals: unresolved security issues piling up, companies asking for roadmaps, or maintainers cancelling holidays because no one else can cut a release. A short community health survey and retrospective can surface exactly where decisions or support structures are breaking down.
Greg: From there you can choose the right scaffolding. Maybe you just need a fiscal sponsor like Open Collective Foundation to handle money, or maybe incorporating a nonprofit makes sense. Include survey questions such as “How long do security patches typically take?” or “Do you feel comfortable challenging technical decisions?” so you track change over time. The important part is to document the decision criteria and invite feedback so people understand the “why” behind the change.

On-screen

Narration

Anna: Governance anti-patterns focuses attention on a concrete part of the work. Watch for failure modes. BDFL burnout happens when a founder clings to every decision; rotate authority and document delegation triggers. Committee paralysis emerges when every choice requires consensus from a dozen people—set quorum rules, empower working groups and time-box debates. Corporate capture looms if a single vendor funds more than ~40% of budget or staff; diversify revenue, publish conflict-of-interest disclosures and ensure board seats reflect community demographics. Fork wars escalate when communication breaks; invest in mediation channels, transparent decision logs and cultural competency training so disagreements stay technical rather than personal. Use incident reviews to turn anti-patterns into learning moments instead of repeating cycles.
Greg: In practice, ask who owns the work, what evidence proves it happened, and what handoff comes next.

On-screen

Narration

Anna: Governance work opens up real career paths: community managers, release engineers, program officers inside foundations, even policy advisors specialising in Indigenous data sovereignty. Ratios help with planning—aim for roughly one community manager per two hundred active contributors, otherwise moderation and onboarding slip.
Greg: These roles suit people who can facilitate debate, document decisions and build inclusive processes across time zones. Many start with a contributor streak, a Google Summer of Code placement or a rotation through an open-source program office. Hit that 200-contributor mark and, sure, your side project headaches multiply—but they’re the good kind that signal your impact. Over time you might chair the technical steering committee or move into an OSPO leadership role. The takeaway is simple: intentional governance lets projects grow without sacrificing their values.

On-screen

Narration

Anna: Practical playbook focuses attention on a concrete part of the work. Document governance so newcomers can self-serve. Create a GOVERNANCE.md describing decision rights, a CODEOWNERS file for reviews, and an RFC template outlining proposal stages. Provide onboarding kits with buddy assignments, office hours in multiple languages and primers on inclusive communication. Track community health metrics—median PR review time, ratio of first-time contributors merged, moderation response within 24 hours—and share dashboards publicly. Adopt decision frameworks that fit your culture: consensus-seeking for technical design, majority vote for budget approvals, and veto powers reserved for safety issues. Pair transparent funding reports with conflict resolution channels facilitated by trained moderators or ombudspeople.
Greg: In practice, ask who owns the work, what evidence proves it happened, and what handoff comes next.

On-screen

Narration

Anna: The key takeaway is this: Intentional governance choices—paired with documentation, mentorship and cultural humility—let projects scale participation without losing their values.
Greg: Use that takeaway to name the owner, evidence, and next action that should be visible after the work is done.