Governance Journeys =================== Slide 1: Governance Journeys 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 text Governance Journeys How open-source projects evolve from a single maintainer to community institutions We’re zooming out from the Te Hiku example now to examine mainstream open-source communities. Projects rarely jump from hobby repo to nonprofit overnight. Healthy governance grows in layers: early contributors document norms alongside code; mid-stage teams add facilitation rituals; mature foundations balance budgets, legal protection and public accountability. Each step should lower individual load and widen community agency rather than calcify power. Remember governance is people-work across cultures and time zones—stewardship means designing decision paths that are legible to newcomers, respectful of marginalised voices and responsive when circumstances change. Slide 2: Solo stewardship 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 text Solo stewardship Single maintainers juggle vision, releases and community tone-setting while also guarding their personal energy. Consider Sindre Sorhus shepherding 1,000+ npm packages solo or Daniel Stenberg steering curl for 25 years—the pace is fast but fragile. Governance here lives in CONTRIBUTING.md checklists, publish-once-a-week issue triage streams and an explicit roadmap so users know what will not be built. Risk: burnout, unreviewed security fixes, bus factor of one. The “bus factor” is shorthand for how many people can get hit by a bus before the project dies—spoiler: aim higher than one. Mitigate by inviting trusted lieutenants for triage, delegating release tokens, documenting deployment passwords and scheduling real vacations before 3am pager stress arrives. Slide 3: Core team collectives 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 text Core team collectives When three to ten maintainers coordinate, clarity beats charisma. Codify onboarding playbooks that explain code review expectations, decision timelines and how to escalate conflict. Rotate roles—review captain, release manager, community moderator—so knowledge spreads. Before Mastodon restructured, founder Eugen Rochko was handling code reviews, harassment reports and server bills alone. The shift created squads for iOS/Android clients, server administration and community moderation, each with two to three maintainers plus shared decision logs in public forums. Conflict resolution can move from private DMs to a published process using lazy consensus with fallback votes. Pair this with mentorship cohorts for diverse regions so contributors in Latin America or South Asia know how to surface blockers despite time zone gaps. Slide 4: Foundation-backed projects 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 text Foundation-backed projects Foundations add legal, fiscal and reputational scaffolding once a project becomes critical infrastructure. The Linux Foundation now stewards 750+ projects with a $177M annual budget, funding security audits, conformance programs and marketing. Apache hosts 350+ volunteer-led projects, offering neutral trademarks and a proven meritocratic ladder. Umbrella groups like the CNCF or Software Freedom Conservancy provide insurance, contract staff and cross-project working groups on topics like accessibility or inclusive language. Expect contributor licence agreements, governance charters and codes of conduct to become formal documents rather than wiki pages. In exchange, maintainers gain vendor-neutral roadmaps, multi-year funding commitments and a buffer when commercial or geopolitical interests collide with community priorities. Slide 5: Deciding when to formalise 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 text Deciding when to formalise Look for leading indicators: unresolved security patches aging past 30 days, Fortune 100 adopters requesting SLA-like assurances, or maintainers skipping parental leave because no one else can ship. Run community health surveys asking, “How long do security fixes usually take?” and “Do you feel comfortable challenging technical decisions?” React, for example, spent three years moving from a Facebook tool to a more open governance model as enterprises demanded neutrality; the hand-off included drafting an RFC process and escalating final authority to a cross-company steering group. Publish timelines, decision criteria and retrospective notes so stakeholders understand why a fiscal sponsor, incorporated nonprofit or foundation membership best matches current risk. Slide 6: Governance anti-patterns 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 text Governance anti-patterns 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. Slide 7: Roles, pathways and traits 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 text Roles, pathways and traits Sustainable governance blends paid and volunteer roles: maintainers, release engineers, program managers, community stewards, translators, legal counsel and accessibility reviewers. Aim for roughly one community manager per 200 active contributors—if you reach that headcount, your “side project” problems have officially become good problems. Map geographic distribution to avoid North America-only leadership; dedicate budget for stipend-supported maintainers in underrepresented regions and ensure meetings rotate time zones. Pathways include contributor streaks, Google Summer of Code alumni, corporate OSPO rotations and fellowship programs centring historically excluded communities. Effective leaders communicate transparently, mediate cross-cultural tension, and respect Indigenous data sovereignty where relevant. Career arcs can move from maintainer to technical steering chair to foundation executive or policy advisor. Slide 8: Practical playbook 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 text Practical playbook 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. Slide 9: Key takeaway 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. On-screen text Key takeaway Intentional governance choices—paired with documentation, mentorship and cultural humility—let projects scale participation without losing their values.