oss-governance

{
  "skill_name": "oss-governance",
  "evals": [
    {
      "id": 1,
      "prompt": "I maintain Quillrope, a Rust crate for streaming CSV parsing. About 41,000 crates depend on it directly or transitively, we get roughly 120 issues a month, and there are three of us with merge rights: me, Dara and Sasha. Almost nobody sends patches. Last year we had 9 external contributors and 6 of them sent a single typo fix. I've been reading Python's PEP 13 and the Kubernetes election docs and I want to set up a five-seat steering council with two-year staggered terms and an election officer, in place before the 2.0 release in March. Can you draft the structure?",
      "expected_output": "A refusal to install the requested elected body, a diagnosis of the project as a many-users/few-contributors shape, two ranked models with monthly hours and reversibility, a maintainer council recommended, and succession plus scope defence named as the real work.",
      "files": [],
      "expectations": [
        "Classifies the project as the 'stadium' shape (many users, very few contributors) using the two-axis Working in Public / Eghbal taxonomy, named rather than presented as a generic observation.",
        "States that for this shape the scarce resource is maintainer attention, and names curation, scope defence and succession as the actual work.",
        "Does not deliver the requested five-seat elected steering committee as the recommendation.",
        "States that an elected steering committee carries the highest value and the highest effort, and therefore loses on the value-per-maintainer-hour ordering.",
        "Recommends a maintainer council, naming it the default at three or more maintainers.",
        "Presents exactly two models with trade-offs plus one recommendation, rather than a single option or a long menu.",
        "Attaches a monthly effort figure to each presented model, next to what those hours buy.",
        "States how easily each presented model can be reversed or undone.",
        "Names at least one of the four conditions that would promote an elected steering committee anyway (maintainers on more than one payroll, a visible founder departure, a contributor base outgrowing the maintainer set, a foundation application with a stated governance bar) and states that none of them holds here.",
        "States that the March 2.0 date favours models that install in an afternoon and works against an elected body, because an election's legitimacy cannot be compressed.",
        "Produces an as-is statement of who decides today, and by what implicit rule, before proposing any model.",
        "Computes or asks for the contributor absence factor before ranking shared models.",
        "Warns that a governance document describing elections the project never holds reads as theatre to contributors and is treated as a defect by reviewers."
      ]
    },
    {
      "id": 2,
      "prompt": "Numbers for Halyard, our open-source feature-flag SDK, over the last 12 months straight out of git shortlog -sn: renovate[bot] 1240, Priya 980, Tomas 430, Ines 350, Karl 310, Wen 190, then four people at 60, 40, 30 and 20. Priya runs the merge queue, so 610 of her 980 are merge commits. Karl is the only person who has touched the Windows backend in two years. Priya holds the npm token and the release signing key and nobody else does. Our board deck says our bus factor is 4. Is that right?",
      "expected_output": "A recomputed contributor absence factor with bots and merge commits stripped out, per-area figures, a separate credential inventory, and the correction of the claimed number.",
      "files": [],
      "expectations": [
        "Uses the term 'contributor absence factor' and attributes the metric definition to CHAOSS, or notes it was formerly called bus factor.",
        "States the definition as the smallest number of contributors responsible for 50% of contributions.",
        "Excludes the bot author from the calculation and says why.",
        "Excludes Priya's 610 merge commits and says why, namely that the integrator otherwise looks like the author.",
        "Reports a corrected project-wide absence factor of 3.",
        "Rejects the claimed figure of 4.",
        "Shows the arithmetic: the corrected total, the 50% threshold, and the accumulation that crosses it.",
        "States that the factor must be computed per governed area as well as project-wide.",
        "Reports the Windows backend as an area with an absence factor of 1, and names a single-owner subsystem as what actually breaks on a departure.",
        "States that the measure should also run on reviews, issue responses and documentation, not commits alone.",
        "Produces a separate inventory of privileged credentials rather than treating code access as the binding constraint.",
        "Flags Priya alone holding the npm token and the signing key as a single point of failure, and calls for two current holders on every credential row.",
        "Labels the 'at least 2, and two holders per credential' figure as a self-set baseline rather than a published standard.",
        "Warns against publishing per-person contribution league tables and recommends reporting aggregates."
      ]
    },
    {
      "id": 3,
      "prompt": "I'm the only maintainer of Brightsea, a Python library for parsing scientific instrument files. Around 900 projects depend on it. I've done this alone for six years and I'm cooked: no release in five months, 340 open issues. Someone going by 'ferrous_owl' showed up seven months ago, has 34 merged PRs, is unbelievably responsive, and has offered to take over releases entirely. They've asked twice this week for PyPI publish rights and the GPG key so they can ship 4.0 before the SciPy conference. Honestly I want to hand them everything and walk away. What do I do?",
      "expected_output": "Load relief first, merge rights granted quickly, keys withheld behind a supervised release cycle, and the urgency treated as a signal to slow down.",
      "files": [],
      "expectations": [
        "States that promotion is not a treatment for burnout, and that load relief comes first.",
        "Names concrete relief moves before any grant: triage help, scope cuts, funding, or pausing releases.",
        "Separates merge and review rights from privileged credentials as two distinct grants.",
        "Recommends granting merge rights quickly, on the grounds that they are cheap to grant and cheap to revoke.",
        "Withholds PyPI publish rights and the signing key until at least one supervised release cycle has happened.",
        "States that key-holder rights are never granted in the same act as merge rights.",
        "Treats the repeated urgency and the conference deadline as a reason to slow down rather than to accelerate.",
        "States that a legitimate co-maintainer can wait a release cycle.",
        "References the 2024 xz-utils takeover (or CVE-2024-3094), including the multi-year credibility build and the pressure applied to an exhausted solo maintainer.",
        "Presents the conflict between the liberal-commit-access position attributed to @felixge via opensource.guide and the post-xz staged-grant position, and resolves it as generous with the ladder, slow with the keys, rather than silently picking one side.",
        "Says the governance document should state that the staging pause is policy rather than distrust.",
        "Recommends a second key holder rather than transferring sole custody from one person to another.",
        "Recommends counting reviews given, not only pull requests merged, as promotion evidence.",
        "For key-holder roles, prefers a verifiable identity or an established public track record, and says the requirement belongs in the document rather than being applied silently."
      ]
    },
    {
      "id": 4,
      "prompt": "Context: Vantablock is our stream-processing engine, Apache-2.0 since day one, built at Corvid Systems where I run the platform team. Marketing wants to publish 'Vantablock is now a vendor-neutral open project' next month ahead of our user conference. Current state: five maintainers, all Corvid employees; the trademark and vantablock.io are registered to Corvid; we require a CLA that assigns us broad rights; we run a maintainers' sync every Tuesday, internal, no minutes. Two large banks are evaluating us and one has asked procurement to check governance. Can you help me write the announcement?",
      "expected_output": "A refusal to announce first, the four neutrality signals audited with a verdict each, and the ordered sequence a real move to neutrality has to follow.",
      "files": [],
      "expectations": [
        "Declines to lead with the announcement, stating that neutrality is transferred rather than announced.",
        "Runs the four checkable signals in order of weight: trademark, domains and registry accounts; maintainer-affiliation ratio; contribution-agreement shape; published minutes.",
        "Returns a per-signal verdict rather than prose impressions.",
        "States that the Apache-2.0 licence passes the licence row and fixes nothing on the other four.",
        "States explicitly that code-license openness and governance openness are two separate audits.",
        "Reports the five-of-five single-employer maintainer ratio as the signal that classifies the project as single-vendor.",
        "Cites the pre-fork Redis position, where only two of five maintainers worked outside the controlling company, as a case where the affiliation ratio preceded a fork.",
        "Gives the sequence in the right order: maintainers from a second organization first, then vote or seat caps, then the trademark and asset transfer.",
        "States that announcing before the maintainer pool changes reads as marketing and is checked as marketing.",
        "Cites the Istio trademark episode and the read that partners judge where the asset landed, not the sincerity of the arrangement.",
        "States that a company CLA with a broad grant is what makes a later unilateral relicense possible, and names it as the lever procurement will look for.",
        "Routes the trademark transfer and the contribution agreement to legal counsel instead of advising on their terms.",
        "Recommends published, versioned minutes on a real cadence, with private categories enumerated and a visible marker left where content was withheld."
      ]
    },
    {
      "id": 5,
      "prompt": "We're submitting Kerrigold Mesh to a foundation's sandbox intake in about six weeks. Four maintainers, all at Northgate Labs, no governance file at all right now. I've drafted a GOVERNANCE.md with a five-seat technical steering committee, staggered two-year terms, an appointed election officer, a contribution-based electorate and three working groups (security, docs, release). Can you review it and tighten the language before we submit?",
      "expected_output": "A refusal to polish the over-engineered draft, the smaller honest model recommended with a revisit trigger, and the readiness gaps listed in fix order with the slow ones called out.",
      "files": [],
      "expectations": [
        "Declines to tighten the drafted structure as-is, and names it as over-engineered for four maintainers at a single employer.",
        "States that governance documented but never exercised is a review-blocking defect, not a neutral omission.",
        "Names adopting a complex structure shortly before a foundation application as a recognized anti-pattern.",
        "Names the concrete costs of the draft: elections that never happen, expired terms, working groups with one member, and a reviewer distrusting the whole document because one part is false.",
        "Recommends writing the smaller, honest model instead, and recording a revisit trigger such as maintainers exceeding eight or a second organization holding two seats.",
        "Identifies the single-employer maintainer pool as one of the two slow readiness gaps that take quarters rather than days.",
        "Identifies governance never exercised as the other slow gap.",
        "Lists the remaining readiness gaps in fix order: repository permissions contradicting documented roles, unclear ownership of the name, domains or registry accounts, missing community-health files or a stale maintainers list, and no adopters willing to be named publicly.",
        "States that what a graduation gate certifies is that no single company can walk away and kill the project, rather than code quality.",
        "Quotes any foundation threshold with the foundation named as its owner, rather than as a generic standard.",
        "Marks which requirements are legal gates for counsel (IP clearance, software grant, trademark, membership or sponsorship agreement) rather than ranking them alongside choices.",
        "Advises confirming the target foundation's published criteria as currently stated rather than relying on remembered figures.",
        "Recommends producing evidence that the rules have actually run at least once, such as a maintainer added or moved to emeritus, a vote held, or an escalation resolved under the written path."
      ]
    },
    {
      "id": 6,
      "prompt": "Quick one. I'm writing the decision-making section of our GOVERNANCE.md for Tinpot, a small Go HTTP router with 4 maintainers spread across Lisbon, Bangalore and Vancouver. What are the industry-standard numbers for: the comment period before a breaking change, the threshold to remove a maintainer, how long before someone counts as inactive, and how many approvals to merge? Just give me the standard values so I can paste them in.",
      "expected_output": "Every figure quoted with its owning project attached, published values separated from self-set baselines, and a warning against pasting any of them unchanged.",
      "files": [],
      "expectations": [
        "Declines to present any figure as an industry standard, stating that the field has conventions rather than standards.",
        "Attributes every quoted figure to its owning project or body, in the shape 'Node.js waits 72 hours' rather than 'the standard is 72 hours'.",
        "Quotes the pattern of two approvals to land a change, dropping to one once the change has sat 7 days, attributed to Node.js.",
        "Quotes a minimum 72-hour voting period with its stated reason of letting other time zones take part, attributed to Apache.",
        "Quotes a final comment period of 10 days with a minimum of 5 business days, attributed to the Rust RFC process.",
        "Labels the two-thirds removal and amendment threshold as a common template value with a named source, not as a standard.",
        "Labels the 6-to-12-month inactivity definition as a common convention rather than a standard.",
        "Separates published figures from self-set baselines explicitly, and says which of its own recommendations are which.",
        "Recommends the aging-approval rule as the single most useful import for a small maintainer team, because it stops the repository stalling when one maintainer is away.",
        "Advises adjusting every window for community size and timezone spread rather than pasting the numbers unchanged.",
        "Warns that a named project's published thresholds change, and that the project's own governance file should be re-checked before the number is quoted.",
        "Notes that a team split across three widely separated timezones changes whether a given voting window actually buys the participation it was meant to buy."
      ]
    },
    {
      "id": 7,
      "prompt": "Rough month. Marrowfen, our self-hosted photo library, had a blow-up: our moderation lead resigned publicly after a thread about a corporate sponsor, two other maintainers quit in solidarity, and there are now three competing Matrix rooms arguing about it. People keep saying we need 'real governance'. I want to run a constitutional assembly, elect a steering committee in December, and publish a full governance charter to settle this. Where do I start?",
      "expected_output": "A recommendation to repair the conflict before publishing any structure, the conduct dimension routed out of the governance ladder, and concentration recomputed after the departures.",
      "files": [],
      "expectations": [
        "States that writing new governance during a live trust conflict relocates the fight rather than settling it.",
        "Cites the precedent of a major project that produced an elected steering committee and two forks in the same year.",
        "Recommends addressing the conflict first and publishing the structure afterwards, in that order.",
        "Declines to schedule the December election as the opening move.",
        "Routes the conduct dimension to the code-of-conduct process rather than through the governance escalation ladder.",
        "States that conduct cases are handled in private, with the accused excluded from deliberation.",
        "Specifies that where a maintainer is the subject, others handle it, escalating outside the project if the whole group is implicated.",
        "Names recusal for anyone employed by a party to the dispute, with a named fallback for when recusal leaves no quorum.",
        "Warns that the resignations have probably moved the contributor absence factor, and calls for recomputing concentration and credential holders now.",
        "Treats the sponsorship dimension as a money-governance question (conflict-of-interest policy, who authorizes spending) distinct from the choice of governance model.",
        "Does not present an elected steering committee as the remedy for the trust conflict.",
        "Advises that when structure is eventually published, the simplest workable ladder is what sticks, not the most sophisticated one."
      ]
    },
    {
      "id": 8,
      "prompt": "Here is the entire decision section of our GOVERNANCE.md for Pallasite, an embedded database with two maintainers, me and Jonas: 'Significant changes are discussed by the community until consensus is reached. The maintainers will consider all feedback and make the best decision for the project. Maintainers are added when the existing maintainers feel someone is ready.' A contributor opened an issue last week saying this is meaningless. Jonas thinks it's fine. Who's right?",
      "expected_output": "The contributor's objection upheld with specific defects named, a bounded and escalatable rewrite, self-assessable promotion criteria, and the missing decision classes enumerated.",
      "files": [],
      "expectations": [
        "Sides with the contributor and names the specific defects: 'significant' undefined, 'consensus' with no test, no clock, and nobody named as decider.",
        "States that a rule that cannot be violated cannot be relied on.",
        "Rewrites the clause into a bounded, testable, escalatable form carrying a named decider, a threshold, a stated window and an escalation path.",
        "Names a specific escalation body or tiebreaker, since a two-person project cannot reach a majority.",
        "Requires any blocking objection to carry a technical justification, so that a veto is an argument rather than a mood.",
        "Puts a timer on every decision path, naming the unbounded thread as the failure mode of consensus-seeking.",
        "States what happens when the timer expires: the proposal is explicitly declined or held, or defaults to the status quo, rather than the issue staying open forever.",
        "Replaces the promotion sentence with self-assessable criteria combining a time period, a count of non-trivial merged contributions, and a count of substantive reviews.",
        "Explains that the original promotion wording leaves a contributor nothing to act on, so nobody applies and the maintainer pool never grows.",
        "Enumerates the decision classes the section is missing, at minimum routine change, breaking change, new maintainer, removal, scope change, release, security response and amendment.",
        "Specifies quorum, minimum open period, and whether abstentions count in the denominator for any vote it defines.",
        "Names lazy consensus as the default for routine work, and excludes it from irreversible actions such as a release, a key rotation or a removal.",
        "Labels any threshold it proposes as a self-set baseline the project may move, rather than as a standard."
      ]
    },
    {
      "id": 9,
      "prompt": "Two of us run Sandglass, a date-formatting library with roughly 6,000 weekly downloads. My co-maintainer Nadia goes on parental leave for five months starting in January, and I travel for work a lot. We've never had a governance file. I want one page that actually helps us, not a constitution. What goes in it and what do we leave out?",
      "expected_output": "A roughly one-page GOVERNANCE.md in the standard section order, every clause passing the has-done-or-will-plausibly-do test, with the absence, emeritus and end-state clauses carrying the value.",
      "files": [],
      "expectations": [
        "Produces a GOVERNANCE.md of roughly one page rather than a multi-section constitution.",
        "Applies the clause test explicitly: every clause must describe something the project has done or will plausibly do this year.",
        "Follows the template section order for the sections it keeps, and skips the ones the project does not need rather than reordering.",
        "Lists merge rights separately from privileged credentials such as signing, publishing and organization ownership in the roles section.",
        "Includes an aging-approval or single-approver rule so that routine changes can still land while one of the two maintainers is away.",
        "Includes a scope sentence stating what the project refuses to become, so that features can be declined impersonally.",
        "Includes an inactivity definition in months and an emeritus clause with rights removed, credit retained, and reinstatement stated.",
        "Includes a named end state: a successor named, or an archive announced publicly, rather than the project going silent.",
        "States that an archive announcement marks the repository read-only, states the last supported version and the security policy, and points at a successor fork if one exists.",
        "Says explicitly that the project holds no meetings, rather than inventing a meeting cadence.",
        "Links the neighbouring files (contribution mechanics, code of conduct, people file, security policy) rather than absorbing their content, so that a process tweak is not a governance amendment.",
        "Includes an amendments clause with a threshold and a window, plus a line stating that changing the document is expected rather than a crisis.",
        "Recommends publishing the reduced-availability period, and treats a stated weekly time budget as a legitimate governance clause rather than something to keep quiet about."
      ]
    },
    {
      "id": 10,
      "prompt": "Thornfield is a monorepo: core runtime, CLI, web dashboard, Terraform provider, Helm charts and a VS Code extension. Six top-level directories, six maintainers. Everything is slow because every change seems to need everyone's attention. I want to split it into six subprojects, each with its own SIG, its own charter and its own maintainer list, with a small top-level council above them, like Kubernetes does. Here's the thing though: all six of us work across all six directories, we have maybe four regular outside contributors total, and nobody has more than about two hours a week for process. Plan it out?",
      "expected_output": "Federation ruled out by gate rather than ranked low, delegation and review rules offered as the real fix for throughput, and a maintainer council recommended.",
      "files": [],
      "expectations": [
        "Rules federated subprojects out rather than ranking it low or parking it at the bottom of a menu.",
        "Names the gate that rules it out: components without their own contributor communities make federation unadoptable.",
        "Says explicitly that the model was deleted from consideration and why, rather than leaving it listed.",
        "States that the stated effort ceiling of roughly two hours a week each independently removes federation from consideration.",
        "States that federation buys cross-component deadlock resolution and little else, which is not the problem described.",
        "Notes that federation is wrong as a starting point because it multiplies process before there is anyone to govern.",
        "Names the real cost shape: roughly a week per charter, then a standing job for each subproject, with diverged cadences resisting re-merging.",
        "Recommends delegation, meaning named per-area owners or working groups with a written scope and a report-back expectation, as the cheaper answer to the review bottleneck.",
        "Recommends a maintainer council as the model that fits six maintainers working in one shared area.",
        "States that if federation is ever pursued, the first subproject is chartered as an experiment with explicit scope and a review date.",
        "Gives the premature-split test: if the council still makes all of the subprojects' decisions, the split was premature.",
        "Distinguishes the review-throughput complaint from a governance-model problem, and addresses throughput with approval and review rules rather than a structural change."
      ]
    },
    {
      "id": 11,
      "prompt": "Cinderpath, our infrastructure testing tool, is BUSL-1.1 licensed. A fintech wants to sponsor us at $48,000 a year and a European bank wants to pay for two features. Right now the money would land in my personal bank account, which my accountant hates. I've been told to apply to Software Freedom Conservancy. I also read somewhere that 15-20% of sandbox projects get archived within three years, so I want to factor that risk in. Three maintainers, two of us at the same consultancy. What's the path?",
      "expected_output": "The named sponsor ruled out on its licence requirement, the unverified archival statistic refused as a planning input, host types distinguished, and the money-governance components specified.",
      "files": [],
      "expectations": [
        "Reports that the named fiscal sponsor requires a licence that is both OSI-approved and DFSG-free, and that BUSL-1.1 does not meet it, so that route is closed as things stand.",
        "Refuses to use the 15-20% archival figure as a planning input, and states that it is unverified against any foundation's own data.",
        "Distinguishes lightweight fiscal hosting (donation handling, no governance imposed, a percentage of donations) from a fiscal sponsor with legal services (around 10% of processed revenue, written decision-making required, asset assignment optional).",
        "States that a fiscal host removes the need to incorporate, and that a legal entity is unnecessary until money is involved.",
        "Runs the join-or-not test on all three axes: money, neutrality, and the autonomy budget.",
        "Names the money-governance components required once funds exist: a written conflict-of-interest policy, a budget approved by the governing body rather than by whoever holds the payment credentials, spending-authorization thresholds, a reserve target, and a transparency mechanism.",
        "Names paid maintainers as the recurring friction once some contributors draw project funds and others do not.",
        "Recommends funding a defined administrative or triage role rather than feature development, separating paying for upkeep from paying to decide direction.",
        "Flags the two-of-three same-employer maintainer ratio as a neutrality signal the sponsor and the bank will read.",
        "Tells the user to confirm which legal entity actually holds the funds, and to write the exit plan while nothing is wrong, citing the 2024 staged dissolution of a charitable fiscal host that affected more than 600 collectives with roughly seven months to spend down or transfer.",
        "Notes that a fiscal sponsor holding assigned assets typically cannot later transfer them to an individual or a for-profit, and that the irreversibility is what an adopter reads.",
        "Routes any licence change, the sponsorship or membership agreement, and contributor agreements to legal counsel rather than advising on their terms.",
        "Warns that a US charitable-status application is not a formality, citing a denial that arrived after roughly four and a half years."
      ]
    },
    {
      "id": 12,
      "prompt": "Our GOVERNANCE.md for Ravenbrook, an observability agent, says: four maintainers (Ash, Bo, Colm, Dee), three area owners for collector, exporters and docs, and that 'release authority rests with the maintainer group'. Reality check I just ran on the org: nine accounts have admin on the repo, including two people who left the company in 2025; branch protection is off on main; CODEOWNERS routes everything to @ravenbrook/core, which contains Ash and someone who hasn't committed in 19 months; and only Bo can publish to the registry. A prospective customer's open-source office is doing a review next month. The doc reads fine, so what else should we do?",
      "expected_output": "A line-by-line diff of the repository and organization settings against the document, with divergence named as the review-blocking finding and each contradiction assigned a fix.",
      "files": [],
      "expectations": [
        "States that documented roles contradicted by repository permissions is a named review-blocking anti-pattern that reviewers check for.",
        "Rejects the premise that the document reading fine is sufficient.",
        "Produces a diff of the actual repository and organization settings against the document, item by item.",
        "Flags the nine admin accounts, including the two departed people, as the roles-versus-permissions contradiction to fix first.",
        "Treats a departed person retaining access as a security matter rather than a tidiness matter.",
        "Flags branch protection being off as contradicting any documented review requirement.",
        "States that code-owner routing must match both the areas named in governance and who actually touches them in the commit history, and calls this a computable diff rather than an opinion.",
        "Flags the 19-month-inactive code owner and ties it to a written inactivity definition and an emeritus path.",
        "Flags Bo as the sole registry publisher, and requires more than one holder for registry publishing, release signing and organization ownership.",
        "Requires a people file listing current affiliations plus a separate emeritus section.",
        "States that zero contradictions between documented roles and repository permissions is binary and not a threshold the project can adjust downward.",
        "States that where the forge exposes no setting for a documented rule, the manual convention replacing it must be written down."
      ]
    },
    {
      "id": 13,
      "prompt": "Sablewire is our workflow engine. I'm VP Engineering at Kestrel Data, where it started. Two companies that use it heavily, Munro Freight and Alto Health, have each put an engineer on it full time, so we're now seven maintainers: five Kestrel, two external. Kestrel sells a hosted Sablewire Cloud, owns the trademark, and honestly we do need to control when releases go out because our cloud rollouts are tied to them. Our roadmap is still decided in a Kestrel planning meeting. The two new maintainers are great but I can tell they're wary. Draft us something.",
      "expected_output": "Reserved rights stated in writing, per-organization caps adopted now while uncontroversial, the roadmap moved into public issues, and asset separation flagged as urgent.",
      "files": [],
      "expectations": [
        "States that more than one company now employing maintainers makes asset separation urgent now, while moving the trademark and domains is still uncontroversial.",
        "Writes out explicitly what the company reserves - brand, hosted product, release timing - as a stated clause rather than leaving it implicit.",
        "States that what triggers a maintainer revolt is an assurance that drifts, not a limit that was stated up front.",
        "Recommends per-organization seat or vote caps, and says to adopt them while the seat count is still small enough for the cap to be uncontroversial.",
        "Describes organization-balanced voting correctly: one vote per employer, independents counting as their own, applied to listed decision types, while day-to-day merges stay on lazy consensus.",
        "Moves roadmap decisions out of the internal planning meeting and into public issues.",
        "Names invisible control - an internal roadmap meeting, a trademark on a company balance sheet, one shared employer - as the specific risk of a company-backed project.",
        "Adds that maintainer nominations are judged without prejudice to employer, plus a cap on nominations from an organization already employing half the maintainers.",
        "Reports the five-of-seven affiliation ratio as still classifying the project as single-vendor by the measure adopters and researchers use.",
        "Cites the .NET Foundation episode, or its read that creating a foundation does not by itself remove the founder's authority: only the asset transfer and the bylaw amendment rule do.",
        "Names 'maintainers on more than one payroll' as one of the conditions that promotes an elected steering committee, and states that it is now met.",
        "Routes the trademark arrangement and any contributor agreement to legal counsel rather than drafting terms.",
        "Recommends published, versioned minutes on a real cadence, with the categories that may be decided privately enumerated."
      ]
    }
  ],
  "trigger_queries": [
    { "query": "Write a GOVERNANCE.md for my library", "should_trigger": true },
    { "query": "who actually decides what gets merged in our project?", "should_trigger": true },
    { "query": "we have no rules and it's starting to hurt", "should_trigger": true },
    { "query": "how do we add a new maintainer without it being vibes-based", "should_trigger": true },
    { "query": "one of our maintainers has been inactive for a year, how do we remove him", "should_trigger": true },
    { "query": "our bus factor is 1 and it terrifies me", "should_trigger": true },
    { "query": "an enterprise customer asked who controls the project", "should_trigger": true },
    { "query": "we're applying to the CNCF sandbox next quarter, are we ready", "should_trigger": true },
    { "query": "should we move our project under a foundation", "should_trigger": true },
    { "query": "do we need a fiscal host to accept donations", "should_trigger": true },
    { "query": "two of us maintain this and I'm burning out", "should_trigger": true },
    { "query": "someone keeps blocking every PR and there's no way to overrule them", "should_trigger": true },
    { "query": "our project is deadlocked on a breaking change and nobody can settle it", "should_trigger": true },
    { "query": "I want to step back from the project, how do I hand it over", "should_trigger": true },
    { "query": "how do I hand over the release signing key safely", "should_trigger": true },
    { "query": "who should hold the npm publish token", "should_trigger": true },
    { "query": "we want to prove we're not controlled by one company", "should_trigger": true },
    { "query": "the trademark is registered to my employer, is that a problem", "should_trigger": true },
    { "query": "design a contributor ladder from triager to maintainer", "should_trigger": true },
    { "query": "what threshold should we use to remove a maintainer", "should_trigger": true },
    { "query": "how long should the comment period be before a breaking change", "should_trigger": true },
    { "query": "should we set up a steering committee", "should_trigger": true },
    { "query": "elected committee or maintainer council for a project our size?", "should_trigger": true },
    { "query": "we're four maintainers at the same company, what should we fix", "should_trigger": true },
    { "query": "a competitor forked us and says our project is closed-governance", "should_trigger": true },
    { "query": "write the escalation path for when maintainers disagree", "should_trigger": true },
    { "query": "what happens when there's a tie between two maintainers", "should_trigger": true },
    { "query": "define what counts as inactive for a maintainer", "should_trigger": true },
    { "query": "our GOVERNANCE.md says things that aren't true anymore", "should_trigger": true },
    { "query": "the repo permissions don't match what our governance doc claims", "should_trigger": true },
    { "query": "we need an emeritus policy", "should_trigger": true },
    { "query": "how do I announce that a project is no longer maintained", "should_trigger": true },
    { "query": "is archiving the project a legitimate thing to do", "should_trigger": true },
    { "query": "my co-maintainer disappeared and I can't publish releases", "should_trigger": true },
    { "query": "calculate our contributor absence factor", "should_trigger": true },
    { "query": "what's our bus factor from this git shortlog output", "should_trigger": true },
    { "query": "should releases need a vote or just lazy consensus", "should_trigger": true },
    { "query": "explain lazy consensus and when not to use it", "should_trigger": true },
    { "query": "write the amendment clause for our governance file", "should_trigger": true },
    { "query": "our sponsor wants a board seat, how do we handle that", "should_trigger": true },
    { "query": "how should we govern the money now that donations are coming in", "should_trigger": true },
    { "query": "who approves spending from the project fund", "should_trigger": true },
    { "query": "a new contributor wants commit access after two PRs, should I give it", "should_trigger": true },
    { "query": "someone very eager wants release rights immediately and my gut says wait", "should_trigger": true },
    { "query": "what did the xz backdoor teach maintainers about granting access", "should_trigger": true },
    { "query": "should we adopt organization-balanced voting", "should_trigger": true },
    { "query": "can we cap how many maintainers one employer is allowed", "should_trigger": true },
    { "query": "we want to donate the project but keep control of the roadmap", "should_trigger": true },
    { "query": "how do foundations decide whether a project has graduated", "should_trigger": true },
    { "query": "do we actually need published meeting minutes", "should_trigger": true },
    { "query": "can we keep some decisions private without looking shady", "should_trigger": true },
    { "query": "all our decisions happen in a private Slack and people are annoyed", "should_trigger": true },
    { "query": "the same argument keeps coming back and there's no appeal path", "should_trigger": true },
    { "query": "write the security response section of our governance file", "should_trigger": true },
    { "query": "who gets to declare a release", "should_trigger": true },
    { "query": "should maintainers be able to veto each other", "should_trigger": true },
    { "query": "what makes a veto legitimate", "should_trigger": true },
    { "query": "we want to split the repo into subprojects with their own SIGs", "should_trigger": true },
    { "query": "federated subprojects, is that overkill for us", "should_trigger": true },
    { "query": "what does BDFL actually mean and should we say it in our docs", "should_trigger": true },
    { "query": "is meritocracy an acceptable word to use in our project docs", "should_trigger": true },
    { "query": "we grew from 3 to 20 maintainers and it's chaos", "should_trigger": true },
    { "query": "our project has tons of users but almost no contributors, what now", "should_trigger": true },
    { "query": "how do I stop being the only person who can ship a release", "should_trigger": true },
    { "query": "review our decision-making rules", "should_trigger": true },
    { "query": "the founder is leaving in three months and nothing is written down", "should_trigger": true },
    { "query": "our maintainers are now split across three employers, what changes", "should_trigger": true },
    { "query": "what should we put in MAINTAINERS.md", "should_trigger": true },
    { "query": "how do we make sure the project survives if my company drops it", "should_trigger": true },
    { "query": "adopters keep asking if we're single-vendor, what do I show them", "should_trigger": true },
    { "query": "we need something written down before the procurement review next month", "should_trigger": true },
    { "query": "can you sanity check our steering council design", "should_trigger": true },
    { "query": "what's a reasonable quorum for a nine-person committee", "should_trigger": true },
    { "query": "do abstentions count when we vote", "should_trigger": true },
    { "query": "the project is run entirely by me and I'd like that to change", "should_trigger": true },
    { "query": "should we go AGPL or Apache 2.0", "should_trigger": false },
    { "query": "do we need a CLA or is a DCO enough", "should_trigger": false },
    { "query": "is BUSL still considered open source", "should_trigger": false },
    { "query": "our dependency is GPL, what does that force us into", "should_trigger": false },
    { "query": "relicense from MIT to the Elastic License, walk me through it", "should_trigger": false },
    { "query": "dual licensing vs open core, which fits us", "should_trigger": false },
    { "query": "pick a license for a new Rust crate", "should_trigger": false },
    { "query": "write our CONTRIBUTING.md", "should_trigger": false },
    { "query": "nobody ever sends a second pull request, why", "should_trigger": false },
    { "query": "set up good-first-issue labels that actually get picked up", "should_trigger": false },
    { "query": "make our clone-to-tests-passing setup work on a cold machine", "should_trigger": false },
    { "query": "how should we review a first-time contributor's pull request", "should_trigger": false },
    { "query": "our issue backlog is 900 and growing", "should_trigger": false },
    { "query": "design a label taxonomy for our issue tracker", "should_trigger": false },
    { "query": "should we auto-close stale issues", "should_trigger": false },
    { "query": "set response time targets for incoming issues", "should_trigger": false },
    { "query": "write an issue template that stops low-quality bug reports", "should_trigger": false },
    { "query": "write our CODE_OF_CONDUCT.md", "should_trigger": false },
    { "query": "someone is being abusive in our Discord, what do we do", "should_trigger": false },
    { "query": "design a moderation enforcement ladder for our community", "should_trigger": false },
    { "query": "how many moderators do we need for a 4,000-person Slack", "should_trigger": false },
    { "query": "set up GitHub Sponsors tiers for my project", "should_trigger": false },
    { "query": "what perks should corporate sponsors get", "should_trigger": false },
    { "query": "write a sponsorship pitch deck for our open-source project", "should_trigger": false },
    { "query": "which open-source projects should our company fund", "should_trigger": false },
    { "query": "how do we prove our OSS sponsorship budget worked", "should_trigger": false },
    { "query": "should we open source our scheduler or keep it proprietary", "should_trigger": false },
    { "query": "what parts of the product do we commit to never closing", "should_trigger": false },
    { "query": "we're launching on Hacker News next Tuesday", "should_trigger": false },
    { "query": "how do we get onto GitHub Trending on launch day", "should_trigger": false },
    { "query": "name and license clearance before we go public", "should_trigger": false },
    { "query": "get our package into Homebrew and apt", "should_trigger": false },
    { "query": "which curated awesome lists should we be on", "should_trigger": false },
    { "query": "rewrite our README so people understand it in ten seconds", "should_trigger": false },
    { "query": "what should the first command in our README be", "should_trigger": false },
    { "query": "should we take our protocol to the IETF", "should_trigger": false },
    { "query": "is it worth certifying conformance to this spec", "should_trigger": false },
    { "query": "open core or hosted open source as a business model", "should_trigger": false },
    { "query": "how should we price our developer tool", "should_trigger": false },
    { "query": "how do we measure our community's health", "should_trigger": false },
    { "query": "should we start a Discord or a forum", "should_trigger": false },
    { "query": "seed the first 50 members of our developer community", "should_trigger": false },
    { "query": "design an ambassador program with perks and terms", "should_trigger": false },
    { "query": "how do I measure DevRel impact", "should_trigger": false },
    { "query": "who should the DevRel team report to", "should_trigger": false },
    { "query": "split our DevRel budget across events and content", "should_trigger": false },
    { "query": "write a job posting for a developer advocate", "should_trigger": false },
    { "query": "write release notes for 3.0", "should_trigger": false },
    { "query": "write the migration guide for our breaking change", "should_trigger": false },
    { "query": "what's a good deprecation timeline for a removed API", "should_trigger": false },
    { "query": "audit our docs structure against Diataxis", "should_trigger": false },
    { "query": "write a quickstart that gets to hello world in five minutes", "should_trigger": false },
    { "query": "our documentation code samples don't compile anymore", "should_trigger": false },
    { "query": "should we sponsor KubeCon at the silver tier", "should_trigger": false },
    { "query": "start a monthly developer meetup in Porto", "should_trigger": false },
    { "query": "write my conference CFP abstract", "should_trigger": false },
    { "query": "outline my 25-minute conference talk", "should_trigger": false },
    { "query": "optimize my GitHub profile README", "should_trigger": false },
    { "query": "which six repositories should I pin on my profile", "should_trigger": false },
    { "query": "set up data governance for our warehouse", "should_trigger": false },
    { "query": "write an AI governance policy for our company", "should_trigger": false },
    { "query": "API governance standards across our microservices", "should_trigger": false },
    { "query": "governance rules for the agent skills in our internal repo", "should_trigger": false },
    { "query": "corporate governance for our startup's board of directors", "should_trigger": false },
    { "query": "IT governance framework, COBIT or ITIL", "should_trigger": false },
    { "query": "Terraform module governance and naming standards", "should_trigger": false },
    { "query": "design Kubernetes RBAC policy for our cluster", "should_trigger": false },
    { "query": "who approves architecture decisions in our engineering org", "should_trigger": false },
    { "query": "write an ADR for our database choice", "should_trigger": false },
    { "query": "our company wants to start an OSPO, what does it actually do", "should_trigger": false },
    { "query": "GDPR data processing agreement with our vendor", "should_trigger": false },
    { "query": "SOC 2 access review process for our production systems", "should_trigger": false },
    { "query": "board resolution template for our nonprofit", "should_trigger": false },
    { "query": "who owns the on-call rotation and how do escalations work", "should_trigger": false },
    { "query": "migrate our repository from GitLab to GitHub", "should_trigger": false }
  ]
}

# Decision rules

Turning a governance model into rules with numbers: decision classes, mechanisms, thresholds, timers, and clauses to paste and edit.

## Decision classes

Define rules per class, not per situation. The minimum set:

| Class                          | Typical decider           | Typical mechanism                        |
| ------------------------------ | ------------------------- | ---------------------------------------- |
| Routine change                 | any maintainer            | lazy consensus + review requirement      |
| Breaking change / scope change | maintainers               | consensus-seeking, written proposal      |
| New maintainer                 | maintainers               | nomination + vote or no-objection window |
| Maintainer removal             | maintainers               | supermajority vote                       |
| Release                        | release owner             | majority approval, no veto               |
| Security response              | security responders       | private, delegated authority             |
| Money and brand                | council / committee       | vote, minutes published                  |
| Governance amendment           | maintainers or electorate | supermajority + long window              |

A class the project cannot assign a decider to is the finding - write that rule before anything else.

## Mechanisms

**Lazy consensus** - announce the intent, state the window, proceed if nobody objects. The cheapest mechanism that still leaves a record, and the right default for most decisions. Not for decisions where review is mandatory before merging, and never for irreversible actions (a release, a key rotation, a removal).

**Consensus-seeking** - pursue agreement, accept that unanimity is not required, let a reasoned objection block until it is addressed or overridden. Its failure mode is the unbounded thread, so every consensus-seeking rule needs a timer and a named body that can end the discussion.

**Voting** - rarer than most drafts assume (Fogel's last-resort position is in the evidence base). Write the thresholds anyway, since they make the last resort usable, but specify them precisely:

- Who is binding.
- The threshold (simple majority, two-thirds of _all_ existing maintainers, or consensus approval).
- Quorum.
- Minimum open period.
- Whether abstentions count in the denominator - that last ambiguity is where governance arguments actually happen.

**Justified veto** - a blocking objection must carry a technical justification. An unjustified veto carries no weight. The single most useful clause to import: it converts "I don't like it" into an argument that can be answered.

**Delegation** - an area owner, working group or security team decides inside a named scope without returning to the full body. Write the scope and the report-back expectation, or delegation is indistinguishable from drift.

## Reference numbers

Published windows, thresholds and terms are listed with their owners in the evidence base. Quote them from there rather than restating them as a standard, and adjust every one for community size and timezone spread. The aging rule on approvals - two approvals to merge, dropping to one once a change has sat a week - is the single most useful import for a small project, because it stops a two-maintainer repository stalling when one is away.

## Example clauses

**Good - bounded, testable, escalatable**

> Changes to public API behaviour require a design proposal, a 10-day comment period, and approval by two maintainers with no unresolved objection. An objection must state a technical reason. If an objection remains unresolved after 30 days, any maintainer may refer the proposal to the maintainer council, which decides by simple majority.

**Bad - unbounded and unenforceable**

> Significant changes are discussed by the community until consensus is reached. The maintainers will consider all feedback and make the best decision for the project.

"Significant" is undefined, "consensus" has no test, there is no clock, nobody is named. It cannot be violated, so it cannot be relied on.

**Good - promotion criteria a candidate can self-assess**

> A contributor may be nominated as maintainer after six months of sustained participation, including at least ten merged non-trivial pull requests and at least twenty substantive reviews. Any maintainer may nominate; the nomination passes if no maintainer objects within seven days, otherwise it goes to a simple-majority vote.

**Bad** - "Maintainers are added when the existing maintainers feel someone is ready." A contributor cannot act on this, so nobody applies and the pool never grows.

## Written proposal processes

Adopt one when decisions get re-litigated or knowledge lives in calls and chat. Keep it cheap:

- A template with motivation, goals and non-goals, design, alternatives and open questions.
- A status vocabulary (`proposed`, `accepted`, `deferred`, `rejected`, `withdrawn`, `replaced`).
- A comment period.
- A stated disposition from the deciding body.

Two properties matter more than the format: the artefact is public and durable, and acceptance is explicit rather than inferred from silence.

Set the trigger narrowly: proposals for substantial changes only (semantics, removals, new public surface) keeps the process alive; requiring them for everything kills it in a month. An accepted proposal is a decision, not a commitment that anyone will implement it.

## Escalation and deadlock

Beyond step 3's rule that escalation costs a label rather than a confrontation, name the escalation body: a council, a committee, or a named tiebreaker on a two-person project. Bound it, so it decides within a stated period; a decision not taken by then defaults to the status quo. Record the outcome where the discussion happened.

Handle conflicts of interest up front: anyone employed by a party to the dispute recuses, with a named fallback for when that leaves no quorum. Conduct cases never travel this path: they belong to the code-of-conduct process, in private, with the accused excluded.

Six projects publish ladders that get used. Each names who holds the final call and what it excludes. Pick the one whose shape matches the project rather than assembling a hybrid.

| Project | Final authority                                         | Threshold or mechanism                                                                                                                        | Explicitly out of scope                                        |
| ------- | ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| Apache  | the project management committee                        | a justified -1 vetoes a code change and cannot be overridden; the committee judges whether the justification is technical                     | releases and procedural votes cannot be vetoed                 |
| Node.js | the technical steering committee                        | consensus-seeking; a member may call a closing vote, which itself needs majority approval to happen; a label puts a stuck issue on the agenda | anything already settled by consensus                          |
| Rust    | per-team decision, council above it                     | a registered concern during the final comment period blocks the merge until resolved                                                          | most technical calls stay with teams                           |
| Python  | the steering council                                    | court of final appeal once every other route has failed                                                                                       | anything a delegate can still decide                           |
| Debian  | the technical committee, then a project-wide resolution | the committee may direct a developer against their wishes on a 3:1 majority                                                                   | disputes the parties have not first tried to settle themselves |
| Go      | a named individual arbiter                              | proposals with no consensus are declined; unresolved ones sit in a hold state rather than being force-closed                                  | nothing - the arbiter is the ceiling                           |

One rule underlies all six: a proposal that cannot reach agreement gets _declined_ or _held_ explicitly, because an issue left open forever is a decision nobody can appeal.

The prompt to formalize is behavioural: when the same dispute recurs and nobody can point to a written appeal path, write one. Every ecosystem that built its ladder only after the crisis reports the same thing afterwards - the structure that stuck was the simplest workable one, not the most sophisticated.

# Foundations and fiscal hosts

What each type requires, what it provides, and how to decide whether to join at all.

- [The join-or-not test](#the-join-or-not-test)
- [Host types](#host-types)
- [Entity types, if the project incorporates itself](#entity-types-if-the-project-incorporates-itself)
- [Two failure cases worth knowing before filing](#two-failure-cases-worth-knowing-before-filing)
- [What gets traded away](#what-gets-traded-away)
- [Graduation mechanics](#graduation-mechanics)
- [Governing the money once it exists](#governing-the-money-once-it-exists)
- [Readiness gaps to fix first](#readiness-gaps-to-fix-first)
- [Where counsel is required](#where-counsel-is-required)

## The join-or-not test

Check all three before recommending a direction:

1. **Money.** Does the project need to receive donations, hold funds, pay contractors or reimburse travel? A legal entity is unnecessary until money is involved; a fiscal host removes the need to incorporate.
2. **Neutrality.** Do adopters need proof no single vendor controls the project? Enterprise procurement and other open-source projects ask; individual users do not. Foundation membership is the cheapest credible proof, a vendor-held trademark the cheapest way to lose the claim.
3. **Autonomy budget.** How much control over process, brand and reporting is the project willing to give up?

If money and neutrality are both "no", stay independent and revisit on a trigger - the first sponsorship offer, the first adopter asking about control, or the first time a maintainer pays for infrastructure personally.

## Host types

| Host type                          | What it requires                                                                                                                                         | What it provides                                                                                   | Cost                                                                                                                             |
| ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| Lightweight fiscal host            | nothing beyond an open project and a public ledger                                                                                                       | donation handling, transparency, no governance imposed                                             | a percentage of donations                                                                                                        |
| Fiscal sponsor with legal services | a licence that is both OSI-approved and DFSG-free; written decision-making, which the sponsor formalizes rather than replaces; asset assignment optional | financial administration, licensing and legal consultation, infrastructure - but no direct funding | around 10% of processed revenue                                                                                                  |
| Incubator-style foundation         | a champion and mentors, IP clearance and a software grant, a trademark check, monthly then quarterly reporting, releases voted twice                     | a durable neutral home, a dispute venue, an established brand                                      | the project adopts the foundation's committees, vote rules and release process wholesale, and the foundation holds the trademark |
| Level-gated technical foundation   | documented governance and a code of conduct at entry, exercised governance at the next level, organizational diversity at the top                        | staged onboarding, marketing reach, a strong neutrality signal                                     | rising process obligations at each level, plus the trademark                                                                     |
| Ecosystem or language foundation   | varies; narrower scope                                                                                                                                   | community fit and existing relationships                                                           | usually lighter than the two above                                                                                               |

Two easily missed details:

- A fiscal sponsor holding assigned assets typically cannot later transfer them to an individual or a for-profit; that irreversibility is what an adopter reads.
- A level-gated foundation checks the community-health files during review (licence, readme, contributing, code of conduct, maintainers, governance, security policy), plus a public adopters list before a level change.

## Entity types, if the project incorporates itself

Most projects should join something rather than incorporate. When incorporation is genuinely on the table, the split below is the decision underneath the host choice.

| Structure                                  | Money treatment                                                                                   | Governance shape                                                       | Typical users                                                |
| ------------------------------------------ | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------ |
| US public charity                          | donations deductible; must serve a public, charitable or educational purpose; lobbying restricted | community mission, board-led                                           | language and tooling foundations with individual-donor bases |
| US trade association                       | dues generally deductible as a business expense, not as charity                                   | corporate members, dues tiers, board seats attached to the upper tiers | most multi-vendor infrastructure foundations                 |
| European registered association            | member dues; can obtain tax-privileged status                                                     | member-driven and democratic; assets held on behalf of members         | community forges and desktop projects                        |
| European foundation (Stiftung / stichting) | endowment or donations                                                                            | board-governed, no members, self-perpetuating                          | large single-product projects                                |
| Fiscal host                                | host holds the funds for many projects                                                            | project keeps its own governance under the host's rules                | anything that needs plumbing, not an entity                  |

Two things to weigh:

- A trade association serves its corporate members' common business interests: legitimate, but a different mission from a charity's, and adopters read the difference.
- The member-association form alone holds assets for the members, so they structurally cannot be sold to a for-profit - exactly the failure that has produced forks elsewhere.

## Two failure cases worth knowing before filing

- **Charity status is not a formality.** One project's US charitable-status application was denied after roughly four and a half years, on the reasoning that open-source software authorizes use by anyone for any purpose, including commercial ones. One examiner's opinion, not binding precedent - but the multi-year denial risk is why risk-averse projects route through an existing sponsor instead of filing.
- **A fiscal host can dissolve.** In 2024 a charitable fiscal host announced a staged dissolution affecting more than 600 collectives, giving roughly seven months to spend down or transfer funds. A similarly named host serving open-source projects was legally distinct and unaffected - telling the two apart mattered enormously to anyone whose money sat in one. Know which legal entity holds the funds, and write the exit plan while nothing is wrong.

## What gets traded away

Roughly in the order projects regret them:

- The trademark and brand, held or licensed by the host with commercial use subject to its policy.
- The release process, since a host with its own release votes adds days and a licensing review to every artefact.
- The decision rules, which some hosts impose and others freeze into an agreement that takes work to change.
- A reporting cadence that becomes an ongoing maintainer cost.
- Exit friction, since leaving is slow and assigned assets do not always come back.

The gain is symmetric: neutrality adopters believe, financial and legal infrastructure, a venue for disputes larger than the maintainer group, and continuity if the founding maintainers leave.

## Graduation mechanics

The gate is a community-maturity test, not a code-quality test: what is certified is that no single company can walk away and kill the project.

At a level-gated foundation, full due diligence happens when a sandbox project applies to incubate rather than when it enters:

- Documented production use by at least three independent adopters.
- A healthy committer body.
- A two-thirds supermajority of the technical oversight committee.
- At least three months from a committee member's sponsorship.

A failed vote can fall back a level. An incubator-style foundation instead runs a mentored provisional project, completes IP clearance before graduation, and decides on a self-assessment, a discussion thread and a board resolution - lighter and more discretionary.

Map to the target's published criteria early and fix the two slow gaps first - a single-employer maintainer pool and governance never exercised - because those take quarters, and adopting a complex structure shortly before applying is itself a recognized anti-pattern.

## Governing the money once it exists

Money arrives with governance questions the code never raised. Components that cover most of it:

- A written conflict-of-interest policy.
- A budget approved by the governing body rather than whoever holds the payment credentials.
- Spending-authorization thresholds.
- An explicit reserve target, so a deficit year reads as a planned drawdown.
- A transparency mechanism: a legally mandated annual filing beats any voluntary practice precisely because it is not voluntary, and a public real-time ledger gets a smaller project most of the same effect.

The recurring friction is paid maintainers. When some draw project funds and others do not, disputes follow over who authorizes spending and whether paid contributors gain disproportionate influence.

The best-tracked mitigation is funding a defined role for administrative and triage work rather than feature development, separating "paid to keep the lights on" from "paid to decide direction". A public ledger also exposes individual compensation to scrutiny; make that trade deliberately.

## Readiness gaps to fix first

Most rejections and delays come from the same causes, in fix order:

- Maintainers from only one organization.
- Governance documented but never exercised.
- Repository permissions contradicting documented roles.
- Unclear ownership of the name, domains or registry accounts.
- Missing community-health files or a stale maintainers list.
- No adopters willing to be named publicly where the host requires it.

The first two take quarters, the rest days.

## Where counsel is required

Say this plainly rather than answering it:

- Licence changes and relicensing.
- Contributor agreements and copyright assignment.
- Trademark registration and transfer.
- The sponsorship or membership agreement.
- Export control and sanctions.
- Anything touching employment status.

Prepare the decision - what the project wants, what the host requires, what it will trade - and let a lawyer paper it.

# GOVERNANCE.md template

Section order, fill-in guidance, and two worked examples showing right-sized versus over-engineered.

- [Section order](#section-order)
- [Transparency of meetings and minutes](#transparency-of-meetings-and-minutes)
- [Right-sized example: two-maintainer project](#right-sized-example-two-maintainer-project)
- [Over-engineered example and what it costs](#over-engineered-example-and-what-it-costs)
- [Neighbouring files](#neighbouring-files)

## Section order

Converged from GitHub's Minimum Viable Governance and the Cloud Native Computing Foundation templates, in the order listed in the table below. Skip any section the project does not need, but keep the order for the ones it does. Code-of-conduct enforcement and security response are pointers to their own files plus a statement of who acts.

| Section                       | What has to be in it                                                                                                                                                                                                                                                                                                                                                            |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Values and scope              | three to six lines, only values the project would enforce, plus what it refuses to become - the sentence that lets maintainers decline features impersonally                                                                                                                                                                                                                    |
| Roles                         | per role: what it may do, what it is expected to do, how it is granted. List merge rights separately from privileged credentials (signing, publishing, org ownership) - different grants                                                                                                                                                                                        |
| Becoming a maintainer         | self-assessable criteria (a time period, a count of non-trivial contributions, a count of reviews), who nominates, what approves it, what rights follow. With more than one employer represented, add that nominations are judged without prejudice to employer - and near a neutrality claim, a cap on nominations from an organization already employing half the maintainers |
| Removing a maintainer         | resignation, inactivity defined in months, conduct violations, and the threshold - commonly two-thirds of remaining maintainers. Writing it before it is needed makes it survivable                                                                                                                                                                                             |
| Emeritus                      | recognition kept, rights removed, listed separately, reinstatement by simple majority. The humane alternative to a stale maintainer list or an ugly removal                                                                                                                                                                                                                     |
| Meetings and communication    | cadence, public by default, explicit exceptions (security reports, conduct cases, personnel matters), where notes are published. With no meetings, say so rather than inventing them                                                                                                                                                                                            |
| Decision-making and voting    | one line per decision class - who decides, threshold, timer, escalation - plus who may demand a vote, quorum, minimum open period, whether abstentions count in the denominator                                                                                                                                                                                                 |
| Code-of-conduct enforcement   | who acts, and what happens when the subject is a maintainer: excluded from deliberation, two others handle it, escalate outside the project if the whole group is implicated. The standard lives in its own file                                                                                                                                                                |
| Security response             | a named group of at least two, a pointer to the reporting process, a review cadence for who is on it                                                                                                                                                                                                                                                                            |
| Appeals and escalation        | how a decision gets reconsidered - open an issue, get a written answer within a stated period, escalate if denied. No appeal path pushes disagreement into public conflict or forks                                                                                                                                                                                             |
| Trademarks and project assets | who controls the name, logo, domains and registry accounts, and what happens to a departing maintainer's rights. This clause decides whether "vendor-neutral" is true; keep it factual, route the contract to counsel                                                                                                                                                           |
| Amendments                    | threshold, window, who may propose - plus a line saying the document is expected to change as the project grows, so amending it is normal rather than a crisis                                                                                                                                                                                                                  |

## Transparency of meetings and minutes

The pattern separating real transparency from the performative kind is **public by default, privacy by enumerated exception, with a visible marker where something was withheld**.

The strongest published versions list exhaustively which categories may be decided in private, and instruct the body to avoid private decisions otherwise:

- Contract negotiations.
- Interpersonal disputes.
- Personal-safety matters.
- Commitments made under confidentiality.

```
✓ Good - a project strikes private sections from its minutes and leaves a marker; a reader can tell something is missing
✗ Bad - an executive session with no marker and no policy for when the content becomes public; omission then looks identical to there being nothing to omit
```

Minutes committed to the repository, or tracked as labelled issues, also make the record versioned and searchable.

## Right-sized example: two-maintainer project

```markdown
# Governance

## Scope

Alice Ng and Ben Torres maintain <project>. It stays a single-purpose library;
storage backends and a plugin system are out of scope.

## Roles

- Maintainers: Alice, Ben. Merge, release, and decide direction.
- Release keys: Alice and Ben both hold signing keys and registry publish rights.
- Contributors: anyone with a merged change.

## Decisions

Routine changes: one maintainer approves; either may merge.
Anything that changes public API behaviour, scope, or the license: both maintainers
must agree, in a public issue, with a 7-day comment window first.
Disagreement that survives one week: the change is not made, and the issue records why.

## Adding a maintainer

Three months of sustained review activity, then both current maintainers agree.
New maintainers get merge rights immediately and release keys after one release cycle.

## Stepping back

A maintainer inactive for six months with no return date moves to emeritus and keeps
credit in MAINTAINERS.md; credentials are rotated within 30 days.
If both maintainers step back, we will name a successor or archive the repository
publicly rather than leave it unmaintained.

## Changing this document

Both maintainers agree, in a pull request open for at least 7 days.
```

Roughly a page. Every clause describes something the project has done or will plausibly do this year; the last two sections carry most of the value.

## Over-engineered example and what it costs

The failure: a five-seat steering committee with staggered two-year terms, appointed election officers, a contribution-based electorate, three working groups and a two-thirds amendment rule - on a project with four maintainers, all at one employer, that has never held an election. Costs:

- Elections that never happen (expired terms, a visibly false governance file).
- Working groups with one member.
- A review that distrusts the whole document because one part is false.

The fix is to write the smaller model honestly and record the revisit trigger - "revisit when maintainers exceed eight or a second organization holds two seats".

## Neighbouring files

Link, do not absorb:

- Contribution mechanics (`CONTRIBUTING.md`).
- Behaviour standard (`CODE_OF_CONDUCT.md`).
- People and affiliations plus emeritus (`MAINTAINERS.md`).
- Vulnerability reporting (`SECURITY.md`).
- Role progression (`CONTRIBUTOR_LADDER.md`).
- Release process, review guidelines, code-owner routing.

Governance defines authority, those files define practice; mixing them makes every process tweak a governance amendment.

# Governance models

Catalogue, fit criteria, real implementations, and how projects move between models.

## The four implementable shapes

Catalogued below by project size, which is not a recommendation order - the efficiency ranking that decides what to adopt lives in step 2 of the skill.

**1. Single-maintainer authority.** One person decides; contributions welcome, direction not negotiated. Only acceptable alongside a written succession plan and a stated response expectation ("I work on this 2-5 hours a week").

**2. Maintainer council.** Everyone with merge rights also decides: lazy consensus by default, simple majority when a vote is called, two-thirds for removals and amendments. Assumes no gap between who writes the code and who decides - the natural first written governance at three to eight maintainers.

**3. Elected steering committee.** A body elected by the contributor base owns direction, policy, budget and final escalation, technical authority delegated to per-area maintainers. Its overhead - election officers, terms, eligibility, vacancies - buys legitimacy a self-selecting group cannot claim once the community outgrows the maintainer set.

**4. Federated subprojects.** A thin council charters subprojects with their own maintainers, cadence and scope. Right when parts of the project have grown separate contributor communities; wrong as a starting point, because it multiplies process before there is anyone to govern.

Translate rather than adopt two older labels:

- **BDFL** is shape 1 with a founder's aura.
- **Meritocracy** is any shape where roles are earned by contribution - a term some communities reject, so prefer "earned roles".

**Liberal contribution** is a policy layered on 2 or 3, not a fifth shape: influence follows current work rather than historic status. It widens the maintainer pool fastest and suits projects needing contributor growth more than stability.

## Fit table

Fit only - the effort, value and reversibility of each model, and the order to consider them in, are in step 2 of the skill.

| Project shape                                 | Model                                  | Main risk it addresses              |
| --------------------------------------------- | -------------------------------------- | ----------------------------------- |
| 1-2 maintainers, any user base                | Single-maintainer authority            | none - it addresses cost, not risk  |
| 3-8 maintainers, one shared area              | Maintainer council                     | ad-hoc decisions, unclear promotion |
| Many contributors, several stakeholder groups | Elected steering committee             | legitimacy, capture by one group    |
| Several components with distinct communities  | Federated subprojects                  | cross-component deadlock            |
| Single vendor, external adopters              | Council + organization-balanced voting | invisible vendor control            |

Two modifiers stack onto any row:

- **Organization-balanced voting** gives each employer one vote (independents count as their own) on listed decision types, while day-to-day merges stay on lazy consensus; it also expresses as a seat cap.
- **Delegation** gives working groups or per-area owners a named scope, which is how a council survives growth without becoming a committee.

## Reference implementations

Read the source documents before copying any of them - each is tuned to a community far larger than most projects.

| Project         | Shape it implements                         | What to take from it                                                                                        |
| --------------- | ------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| Jaeger          | maintainer council                          | a self-selecting maintainer group, lazy consensus, majority vote on demand                                  |
| Node.js         | council plus a technical steering committee | consensus-seeking with concrete fallbacks and a label as the escalation path                                |
| Python          | elected steering council                    | a bounded no-confidence procedure and a supermajority to amend the governance document itself               |
| Kubernetes      | elected committee                           | staggered terms, impartial election officers, contribution-based eligibility, company representation limits |
| Apache projects | committee with binding votes                | justified vetoes on code, majority approval on releases which cannot be vetoed                              |

Ready-to-fill templates for the council, election and federated shapes, plus an organization-balanced voting module, come from the CNCF contributor-strategy group. The smallest legally-reviewed council version is GitHub's Minimum Viable Governance. Both are permissively licensed and meant to be renamed and edited.

## Migration paths

Governance changes are themselves governance decisions - run them through the current rules, announce with a comment window, record who approved.

- **Solo → council**: the hard part is not the document, it is having a second maintainer. Recruit from reviewers, grant staged rights, then write the council rules once two people have actually been deciding together.
- **Council → elected committee**: define the electorate before the seats (contribution-based eligibility over 12 months, counting reviews, issues and docs, not just commits). Run one election before claiming the model.
- **Anything → federated**: charter the first subproject as an experiment with explicit scope and a review date; if the council still makes all its decisions, the split was premature.
- **Vendor-led → neutral**: sequence matters; the order and reasoning are in the neutrality reference.

## The constraint behind every model

Forkability is what limits authority: contributors can copy the code and leave, so deference is voluntary and permanent. Fogel's formulation is that the _possibility_ of forks matters far more than actual forks. A model surviving only because exit is expensive is a lock-in, and the audience most likely to notice is the one whose adoption you want.

## Choosing by project shape, not by ambition

Nadia Eghbal's _Working in Public_ taxonomy sorts projects on two independent axes - users and contributors - and is the fastest sanity check on a proposed model:

|                | Few contributors                                                                                 | Many contributors                                         |
| -------------- | ------------------------------------------------------------------------------------------------ | --------------------------------------------------------- |
| **Many users** | **Stadium** - the dominant modern shape: a large dependent user base served by one or two people | **Federation** - needs delegation, elections, subprojects |
| **Few users**  | **Club** - informal governance is genuinely fine                                                 | **Toy** - many hands, little dependency                   |

The consequence matters for stadiums, which most widely-depended-on libraries are: a stadium adopting an elected committee has solved a problem it does not have and left its real one - maintainer attention - untouched.

# Neutrality, trademarks and project assets

How a project earns or loses the claim that no single company controls it, and what happens when it loses it.

## Neutrality is transferred, not announced

The consistent finding across every documented case: a press release claiming open governance is worth nothing next to an irreversible transfer of control. **Code-license openness and governance openness are orthogonal** - two separate audits.

Sequence matters when moving from vendor-led to neutral: maintainers from a second organization first, then vote or seat caps, then the trademark and asset transfer. Announcing neutrality before the maintainer pool changes reads as marketing and is checked as marketing.

## The four checkable signals

Evaluated in roughly this order of weight:

1. **Who holds the trademark, domains and registry accounts.** Transfer to a neutral foundation is the strongest lever a vendor can give up - CNCF membership requires organizations to give up control of the project's trademarks. A company-held mark is the cheapest way to lose a neutrality claim.
2. **Maintainer-affiliation ratio** - how many maintainers are employed by more than one company. The metric researchers and foundations use to classify a project as single-vendor, computable from public data.
3. **Contribution agreement shape.** A CLA assigning broad rights to one company is what makes a unilateral relicense possible later; a DCO model (inbound equals outbound) does not concentrate that power. Re-opening a licence while keeping the company CLA does not restore trust - the lever is still in place.
4. **Published, versioned meeting minutes** with a real cadence, not a static page.

## Case: a trademark parked outside a neutral foundation

In 2020 Google placed Istio's trademark in its own Open Usage Commons rather than a neutral foundation, drawing public protest from IBM and Oracle and from the CNCF. The CNCF's CTO said Google had "set up an organization with no details claiming to be solving a 'trademark issue' in open source that doesn't exist given the 100+ open source foundations". IBM said it had taken Google "at good faith that our agreement to take the project to the CNCF would be honored," which "turned out to not be the case".

The dispute closed only when Google donated Istio to the CNCF in 2022 and moved the trademark to the Linux Foundation. **Read**: partners judge the destination of the asset, not the sincerity of the arrangement.

## Case: a vendor-founded foundation keeps latent control

The .NET Foundation is a trade association founded by Microsoft in 2014. In October 2021 its executive director resigned after merging a pull request to a member project using foundation permissions without consulting its active maintainers, triggering a maintainer revolt.

One maintainer's framing: "the real issue is fundamentally who owns the projects in the Foundation?" Maintainers had been assured they would be left to run themselves, and what that meant had drifted. Bylaw changes toward independence would still have needed the founding vendor's agreement.

**Read**: creating a foundation does not by itself remove the founder's authority. Only the asset transfer and the bylaw amendment rule do.

## Case: the maintainer ratio that predicted a fork

Before its 2024 licence change, only two of Redis's five maintainers worked outside the controlling company - the ratio that classified it as single-vendor. When the licence moved to non-OSI-approved terms, the Linux Foundation announced a neutral BSD-3 fork built in about eight days by engineers from six companies, with a neutral technical steering committee from day one.

When the original later re-added a copyleft option, fork contributors noted it "still lacks open governance and includes a CLA allowing future license changes". **Read**: the affiliation ratio is a leading indicator, measurable years before the event it predicted.

## What forks teach about prevention

Nearly every high-profile 2021-2024 fork followed a governance-or-licence lever pulled unilaterally by one controlling entity - a relicense, a trademark transfer to a for-profit, a redirection of purpose. Four patterns worth carrying into a design:

- **Gitea → Forgejo (2022).** The domain and trademark were transferred to a new for-profit without community consultation; contributors forked under a German registered association that structurally _cannot sell_ the mark. An entity that cannot alienate the asset is the direct antidote to name capture.
- **Nix/NixOS (2023-24).** A moderation-team resignation and a sponsorship controversy produced a constitutional assembly, an elected steering committee - and two forks anyway. **Structure without repaired trust just relocates the fight**; never sell a governance rewrite as the remedy for a live trust conflict.
- **Terraform → OpenTofu (2023-24) and Elasticsearch → OpenSearch (2021).** Both followed a relicense, both ended up foundation-hosted. Two transferable details: accused of copying code, OpenTofu answered within days with a public line-by-line provenance analysis rather than a statement, and Elastic eventually re-added an OSI-approved licence under sustained pressure, so a fork can win the argument without winning the market.

Later reporting on the Nix situation indicates continuing instability; treat post-2024 specifics here as evolving and re-verify before quoting a current state.

## Worked audit

The four signals applied as an adopter would, using the pre-fork Redis position:

| Signal                 | Finding                         | Verdict                                     |
| ---------------------- | ------------------------------- | ------------------------------------------- |
| Trademark and domains  | held by the controlling company | fails                                       |
| Maintainer affiliation | 2 of 5 outside the company      | fails - majority single-employer            |
| Contribution agreement | company CLA with broad grant    | fails - relicensing lever intact            |
| Minutes                | no public governance minutes    | fails                                       |
| Licence at the time    | OSI-approved                    | passes, and is irrelevant to the other four |

Four negative signals against one positive licence is exactly the configuration that makes a fork survivable for the forkers and expensive for the vendor. Run this table before claiming neutrality: every row is a specific, cheap fix, and the licence row fixes nothing on its own.

# Published governance figures and baselines

Which numbers come from a published source and which are self-set baselines. Cite the first group with its owner; present the second as a starting point the project may move.

## Published figures

Each is published by the named project or body. Quote it with its owner attached - "Node.js uses 72 hours", not "the standard is 72 hours".

| Figure                                                                                                                                                                                                                                                                                                             | Source                                                                            |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------- |
| Two approvals to land a change, one after it has sat 7 days; a public committee issue passes after 72 hours with two approvals and no opposition; in-meeting decisions confirmed after 48 hours                                                                                                                    | Node.js `GOVERNANCE.md`                                                           |
| Voting periods run at least 72 hours so other time zones can take part; code changes need consensus approval (three binding +1, no -1); releases need majority approval and cannot be vetoed; a veto without technical justification is invalid                                                                    | Apache Software Foundation voting guide                                           |
| Final comment period of 10 days, at least 5 business days                                                                                                                                                                                                                                                          | Rust RFC process                                                                  |
| Five-seat steering council; two-thirds core-team supermajority to remove it or amend the governance document; two-week amendment vote. The vote that adopted it drew 62 of 96 eligible voters                                                                                                                      | Python PEP 13 and governance retrospectives                                       |
| A technical committee may direct a developer against their wishes on a 3:1 majority; larger questions escalate to a project-wide resolution                                                                                                                                                                        | Debian constitution, section 6                                                    |
| Contributor absence factor = smallest number of contributors responsible for 50% of contributions; worked example gives 2                                                                                                                                                                                          | CHAOSS metric definition                                                          |
| Graduation expects maintainers from at least two organizations and survival of any single organization's withdrawal; incubation requires documented production use by at least three independent adopters, a two-thirds supermajority of the technical oversight committee, and at least 3 months from sponsorship | CNCF maturity levels and project-progression process                              |
| Graduation expects at least three legally independent committers and no single entity vital to the project                                                                                                                                                                                                         | Apache Incubator graduation guide                                                 |
| Fiscal sponsor fee of 10% of processed revenue; asset assignment optional; licence must be both OSI-approved and DFSG-free                                                                                                                                                                                         | Software Freedom Conservancy application terms                                    |
| Expired committee seats convert to vacancies with a special election within 30 days; inactivity commonly defined as 6-12 months of very low activity; removal and amendment commonly two-thirds                                                                                                                    | CNCF elections and maintainer-council templates, GitHub Minimum Viable Governance |
| Only two of five maintainers worked outside the controlling company before the 2024 Redis relicense                                                                                                                                                                                                                | Valkey co-founder, press interviews                                               |
| Documented-but-never-used governance, cosmetic diversity, governance/code divergence and practice-period shortcuts block level transitions                                                                                                                                                                         | CNCF project reviews                                                              |
| "Taking a vote should be very rare - a last resort for when all other options have failed"                                                                                                                                                                                                                         | Karl Fogel, _Producing Open Source Software_                                      |
| "There is no right time to write down your project's governance, but it's much easier to define once you've seen your community dynamics play out"                                                                                                                                                                 | opensource.guide                                                                  |
| "Whenever somebody sends you a pull request, give them commit access to your project"                                                                                                                                                                                                                              | @felixge, quoted in opensource.guide                                              |
| A pseudonymous contributor built credibility from 2021 while sock puppets pressured a burned-out maintainer; the backdoor shipped in signed releases in February 2024, disclosed 29 March 2024                                                                                                                     | xz-utils / CVE-2024-3094 timeline                                                 |

## Self-set baselines

These are self-set defaults, chosen to be defensible and easy to move - not published standards. Say so when you use them.

| Baseline                                                                                                                      | Why this value                                                                                                                                                                                            | When to move it                                                                                |
| ----------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| Contributor absence factor of at least 2, and at least two holders of every privileged credential                             | The smallest value at which no single departure stops releases; derived from the CHAOSS metric plus the foundation "survives one withdrawal" test, applied to a project that has no formal governance yet | Raise to 3+ once the project has paying adopters or is a dependency of other projects          |
| 100% rule coverage - every hard decision of the last 12 months maps to a written rule                                         | A completeness test, not a benchmark; it makes gaps visible without demanding a large document                                                                                                            | Never lower it; lower the number of decision classes instead                                   |
| Evidence the rules ran at least once within two quarters                                                                      | Puts a concrete interval behind the CNCF "demonstrably used" expectation                                                                                                                                  | Shorten for a project applying to a foundation on a schedule                                   |
| Zero contradictions between documented roles and repository permissions                                                       | Binary by nature                                                                                                                                                                                          | Not adjustable                                                                                 |
| Every decision class carries a stated clock                                                                                   | Prevents the unbounded-thread failure                                                                                                                                                                     | Not adjustable                                                                                 |
| Six months of sustained participation, ten non-trivial merged changes, twenty substantive reviews for a maintainer nomination | An illustrative, self-assessable shape; real projects vary widely                                                                                                                                         | Match to the project's actual traffic - on a low-volume project these numbers exclude everyone |
| Key-holder rights granted only after one supervised release cycle                                                             | The minimum separation that would have slowed the xz-utils takeover; the incident analysis recommends staging privileged access                                                                           | Lengthen for artefacts that run with elevated privilege                                        |

## Contested and unresolved

- **Liberal commit access versus staged keys.** Both positions are sourced and genuinely conflict; present both rather than picking one, resolved as step 7 resolves them.
- **Foundation archival rates.** The commonly repeated figure that roughly 15-20% of sandbox projects are archived within three years is unverified against any foundation's own data. Do not quote it as a planning input.

## Known staleness

Governance documents change. Before quoting a named project's threshold, open that project's governance file and confirm the number still reads as stated here - the structural lessons age far better than the integers.

# Succession playbook

Measuring concentration, granting trust safely, and writing the exits before they are needed.

## Measure concentration

**Contributor absence factor** (the CHAOSS metric formerly called bus factor): the smallest number of contributors responsible for 50% of contributions.

Sum contributions over a window (12 months is a reasonable default):

1. Take 50% of the total.
2. Sort contributors descending.
3. Accumulate until the threshold is crossed.
4. Count the contributors used.

Worked example: `1000, 433, 343, 332, 202, 90, 42, 33` totals 2,475, threshold 1,237.5. The top two (1,433) cross it, giving a factor of **2**.

Compute it on more than commits: reviews, issue responses and documentation reveal a different and usually smaller set of load-bearing people. Derive it from repository history where you can run commands; otherwise ask maintainers to rank themselves and treat it as an estimate.

Take two companions with it:

- **Employer spread**: how many distinct employers the top contributors have, since the graduation-grade test is survival of any single organization withdrawing.
- **Trend**: a factor of 2 that used to be 5 is a different story from a 2 that used to be 1.

Publish aggregates, not per-person league tables; contribution metrics attached to names create privacy and performance-review problems the project did not sign up for.

**Measurement hygiene.** A concentration number is only as credible as its filters, and every one of these changes the answer:

- Exclude merge commits, or the person who integrates looks like the person who writes.
- Exclude bot and automated-dependency authors, or the top contributor is a robot.
- Choose author or committer identity deliberately; they diverge wherever patches are relayed or rebased.
- Bound the window, or weight by recency, so people who left three years ago stop propping the number up.
- Drop contributors below a small share of the total rather than reporting a long tail.
- Compute it **per governed area as well as project-wide**. A project-level factor of 3 routinely hides a subsystem owned by exactly one person, and that subsystem is what actually breaks on a departure.

One incidental signal: if the top contributors' commit timestamps cluster in a single timezone, the project is more concentrated than the employer count suggests, and a 72-hour vote window is probably not buying the participation it was meant to buy. Where history is machine-readable this whole measurement is scriptable, and the same pass can diff the result against the code-owner file to surface ownership drift.

## Inventory the credentials

Code access is rarely the binding constraint - the credentials are. List each, with who holds it and who could recover it:

- Repository and organization ownership (who can add and remove people).
- Protected-branch and merge-policy administration.
- Release signing keys and any code-signing certificates.
- Package-registry publishing rights, per registry.
- Domain registration, DNS and site hosting.
- Continuous-integration secrets and deployment tokens.
- The security-report inbox and any embargo channels.
- Social, forum and chat administration.
- Funding and donation accounts.

A row with exactly one holder is a single point of failure; a row held by someone no longer active is a security incident waiting to be discovered. Aim for two current holders per row with recovery documented, and re-verify on a fixed cadence - this list rots silently.

## The staged trust ladder

Separate what someone can review from what they can ship, and grant in stages against evidence measured in months:

1. **Contributor** - merged changes.
2. **Triager** - labels, closes, reopens; no merge rights. Cheap to grant, immediately useful, and a real signal of judgement.
3. **Reviewer** - approvals count toward merge requirements in a named area.
4. **Maintainer** - merge rights across the project, a vote in governance decisions.
5. **Key holder** - release signing and registry publishing, granted after at least one supervised release cycle, never in the same act as merge rights.

The 2024 xz-utils takeover (step 7, evidence base) justifies the split. Nothing in that story is detectable by reviewing a single pull request, and everything in it is slowed by staged grants, a second key holder, and treating pressure to hand over control as a signal to pause. Practical rules that follow:

- Require reviews _given_, not only pull requests merged - reviewing is where judgement shows.
- For key-holder roles, prefer a verifiable identity or an established public track record, and say so in the document rather than applying it silently.
- Treat urgency as suspicious: a legitimate co-maintainer can wait a release cycle.
- When a maintainer is struggling, relieve load first (triage help, scope cuts, funding, a release pause). Promotion is not a burnout treatment.

## Exit paths

Write all four before any of them is needed:

- **Vacation / reduced availability** - publish it. Silence reads as abandonment and invites the pressure described above; a stated weekly budget ("2-5 hours") is a legitimate governance clause.
- **Emeritus** - credit retained, rights removed, listed separately, reinstatement by simple majority. Triggered by resignation or by the written inactivity definition, so it is procedural rather than personal.
- **Handover** - recruit from reviewers, run a joint period where both merge and release, transfer credentials one at a time with the old holder revoking only after the new one has used theirs successfully, then update the people file and announce. Document the project's direction first so a successor can honour it.
- **Archive** - a legitimate, honourable end state. Announce it, mark the repository read-only, state the last supported version and any security policy, point at a successor fork if one exists. An unmaintained project that never says so is the worst outcome for its users.

## Handover checklist

- [ ] Successor named and publicly announced, or archive announced.
- [ ] Every credential row has a new holder who has used it once; registry and domain ownership transferred with two holders each.
- [ ] Old holder's access revoked, keys rotated, recovery contacts and security inbox updated.
- [ ] Governance file, people file and funding accounts updated.
- [ ] Direction and known-hazards notes written down for the successor.
- [ ] Users told, in the release notes and on the project's main surface.

---
name: oss-governance
description: Chooses and documents an open-source project's governance model - decision rights, maintainer roles and promotion, voting and consensus rules, conflict escalation, succession, trademark and asset control, and whether to join a foundation or fiscal host. Use whenever someone asks who decides in their project, wants to write or fix a GOVERNANCE.md, is adding or removing maintainers, worries about bus factor or a single-vendor-controlled project, faces a deadlocked or contested decision, or is preparing a foundation donation - even if they only say the project has no rules. Covers solo, company-backed and multi-vendor projects. Not license, CLA or DCO choice - use samber/developer-relations-skills@oss-license-strategy. Never legal advice.
license: MIT
metadata:
  author: Samuel Berthe
  version: "1.0.1"
---

# OSS Governance

You are an open-source governance advisor. Your job:

- Work out how the project really makes decisions today.
- Choose the model that returns the most per maintainer hour.
- Write that model down as enforceable rules.
- Make sure the project survives losing any one person or company.

Every project already has governance, usually undocumented, living in one person's head. Surface it before designing anything. Write only what really happens: foundations treat unused governance as a review-blocking defect, and contributors read it as theatre.

Quote every figure with its owner attached; this field has conventions, not standards.

```
✓ Good - "Node.js waits 72 hours"
✗ Bad - "the standard is 72 hours"
```

See [references/published-findings.md](./references/published-findings.md) for published thresholds versus this skill's own baselines.

You are not a lawyer. Send these to counsel, never answer them here:

- Licensing.
- Contributor agreements.
- Trademark filings.
- Employment questions.

## Interview

Ask one question at a time, offering multiple-choice options where you can. Stop as soon as you can name who decides today, who is affected, and what triggered the request - infer the rest and confirm later.

**Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.**
1. What is the project, and what prompted this - a contested decision, a new maintainer, a departure, an adopter asking who controls it, or a foundation application?
2. Who can merge to the main branch today, and who can publish a release? (Often different people; name them.)
3. Who employs each of them, and would any stop contributing if they changed jobs?
4. What is the last decision that was genuinely hard, and how was it settled?
5. Is a company behind the project - and does it hold the trademark, the domain, the registry account, or the roadmap?
6. Which users would you be embarrassed to break: hobbyists, other open-source projects, or companies with procurement reviews?
7. How many contributors merged something in the last 90 days, and how many are new since last year?
8. Does the project receive or need money - donations, sponsorships, paid contractors, travel?
9. What must never change without a wider decision: scope, license, breaking-change policy, brand?
10. How much process will the maintainers actually tolerate - hours a month, standing meetings, and how easily they want to be able to undo it? The answer caps the design.
11. Is there a date this has to be settled by: a foundation deadline, a release, an adopter's review, a departure?
12. Do they want a one-off fix for the decision that triggered this, or a structure the project compounds on for years?

Record the answers. If the harness has persistent memory, store them: the model you choose now becomes the baseline the next review argues against.

Questions 10-12 move the step 2 ranking. Ask them before proposing anything, and say which answer moved which model:

- A hard date promotes the models that install in an afternoon (solo authority, a maintainer council) and demotes an elected committee, whose legitimacy comes from an election that cannot be compressed.
- A compounding mandate does the reverse.
- A low effort ceiling deletes federation outright, rather than parking it.

## Step 1 - Surface the governance that already exists

Before proposing anything, write down the current, real rules. Sources, in order of reliability:

- Repository permissions and code-owner files.
- The last ten contested pull requests or issues.
- Release history (who tagged and signed).
- Only then, what maintainers say happens.

Produce a short "as-is" statement: who decides what, by what implicit rule, where that rule has already failed. Expect these gaps:

- No rule for deadlock.
- None for adding or removing maintainers.
- One person holding every credential.

Then measure concentration: the contributor absence factor (the smallest number of people responsible for 50% of contributions), computed per governed area as well as project-wide. It constrains which models are available at all. Add a separate inventory of privileged credentials. See [references/succession-playbook.md](./references/succession-playbook.md) for method and defensibility filters.

## Step 2 - Rank the models by what they return per maintainer hour

Never pick the most impressive model, or the cheapest. See [references/governance-models.md](./references/governance-models.md) for the catalogue, fit criteria, examples and migration paths; read it before recommending.

Two gates run first, since they remove options instead of ordering them:

- An absence factor of 1 makes every shared model unadoptable. Recruit co-maintainers first (step 7), then rank again.
- Components without their own contributor communities make federation unadoptable.

Delete what a gate rules out and say you did: a ruled-out model parked at the bottom comes back as scope.

Then sort on two axes: how many depend on the project, how many contribute (Nadia Eghbal's _Working in Public_ taxonomy, in the reference). The most misdiagnosed case is many users and very few contributors, where the scarce resource is maintainer attention, so the work is curation, scope defence and succession.

Default order for what survives the gates, on a project with a handful of maintainers and far more users than contributors - `>` means more of that axis:

- efficiency: `maintainer council > written solo authority > federated subprojects > elected steering committee`
- value: `elected steering committee > maintainer council > federated subprojects > written solo authority`
- effort: `elected steering committee > federated subprojects > maintainer council > written solo authority`

| Model                                                   | Effort, and how easily undone                                                                                                                                                      | What the hours buy                                                                                                                            |
| ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| **1. Maintainer council** _(default at 3+ maintainers)_ | an hour a month, no standing meeting; reversed by one vote                                                                                                                         | the two rules ad-hoc projects most visibly lack: deadlock and promotion                                                                       |
| **2. Written solo authority + succession plan**         | near-zero, free to undo                                                                                                                                                            | no decision legitimacy at all - a stated response expectation and a named end state, the difference between a slow project and a stranded one |
| **3. Federated subprojects**                            | a week per charter, then a standing job each; diverged cadences resist re-merging                                                                                                  | cross-component deadlock resolution, and nothing else                                                                                         |
| **4. Elected steering committee**                       | a quarter to install (electorate, eligibility, officers, terms), then a standing job; least reversible, since an elected body is not quietly dissolved by the people it constrains | legitimacy a self-selecting group cannot claim, capture resistance via seat caps, continuity across a founder's departure                     |

Row 2 ranks second only because its denominator is almost nothing. Row 3 beats row 4 despite buying less, its effort being bounded by the subproject count rather than recurring forever. The order starves row 4: highest value, highest effort, so it loses every round.

Promote row 4 anyway when any of these hold, each one a case where the cheaper models do not produce the outcome at all:

- Maintainers on more than one payroll.
- A founder departure already visible.
- A contributor base outgrowing the maintainer set.
- A foundation application with a stated governance bar.

The order is a default, not a law. It moves with the project's shape and with who runs it. Re-rank against what the interview already told you:

- Maintainers who have run elections make the committee far cheaper than this assumes.
- A team that has never held a vote makes the council dearer than it looks.

Present the top two with trade-offs and one recommendation, never a single option, each with its monthly hours next to what those hours buy.

Watch for these outgrown-model signals:

- Decisions stall.
- The only path to influence is "become a maintainer".
- One organization holds a majority of seats.
- Subprojects develop their own cadence.

Treat these as growth, not failure; their absence is a reason to keep the current model.

## Step 3 - Set the decision rules and the escalation ladder

A model is only real once the rules have numbers. Fix who may decide, the threshold, the clock and the escalation path, for each decision class:

- Routine change.
- Breaking change.
- New maintainer.
- Removal.
- Scope change.
- Release.
- Security response.
- Amendment.

Defaults, with reasoning, are in [references/decision-rules.md](./references/decision-rules.md):

- **Lazy consensus** for routine work: announce, wait a stated window, proceed if nobody objects.
- **Consensus-seeking** for anything contested, with somewhere for a reasoned objection to go.
- **An explicit vote** only where a rule demands it - maintainer changes, amendments, money, brand. A last resort (Fogel: "after a compromise, everyone is a little bit unhappy, whereas after a vote, some people are unhappy while others are happy").
- **A written proposal process** for substantial changes, so the decision leaves an artefact instead of living in a call.

Two rules protect the project from its own procedure:

- Require any blocking objection to carry a technical justification, so a veto is an argument rather than a mood.
- Put a timer on every path, since an unbounded discussion is a silent veto for whoever benefits from the status quo.

Take an escalation ladder off the shelf rather than inventing one; the reference compares six by who holds the final call and what each excludes. Whichever you pick, escalation costs a label or an agenda item, never a confrontation, and a proposal nobody agrees on gets explicitly declined or held.

## Step 4 - Write the document

Write the smallest GOVERNANCE.md covering step 3's decision classes and nothing else. Follow the section order and fill-in guidance in [references/governance-doc-template.md](./references/governance-doc-template.md), which shows a right-sized version beside an over-engineered one. Keep the neighbouring concerns in their own files and link: governance says who holds authority, the neighbours say how work gets done.

Every clause passes one test - has this project done this, or will it plausibly do it this year? Cut anything else. Where maintainers hesitate on a threshold, write the rule they will actually follow and note the review date.

## Step 5 - Make it enforceable

Written roles the repository contradicts are fiction, and reviewers check. Align the mechanics in the same pass:

- Merge rights, review requirements and protected branches match the roles as written.
- Code-owner routing matches the areas named in governance - and who actually touches them in the commit history, a computable diff, not an opinion.
- Organization ownership, release signing and registry publishing rights sit with the people governance names, and with more than one person.
- The people file lists current affiliations plus an emeritus section.

Where a forge exposes these as settings, read them and diff against the document; where it lacks them, state the manual convention replacing them.

## Step 6 - Separate the assets from any single company

Neutrality is transferred, not announced: in the documented disputes, partners judged where the asset landed, not the sincerity of the arrangement. A project can be permissively licensed and still entirely vendor-controlled - the vendor holds the name, domains, CI and maintainer majority - so audit code-license openness and governance openness separately.

Adopters, foundation reviewers and competitors check these, in order of weight:

- Who holds the trademark, domains and registry accounts.
- How many maintainers share one employer.
- Whether the contribution agreement concentrates the right to relicense.
- Whether minutes are published and current.

Run all four against the worked audit in [references/neutrality-and-assets.md](./references/neutrality-and-assets.md), which also fixes the sequence a move toward neutrality must follow.

## Step 7 - Design succession before it is needed

Succession is the part every project defers and every incident punishes. Work through [references/succession-playbook.md](./references/succession-playbook.md) and produce:

- A target absence factor.
- A staged contributor-to-maintainer path separating review rights from privileged credentials.
- An inactivity definition.
- An emeritus path.
- A named end state.

Two sourced positions conflict here: @felixge's rule of giving commit access to whoever sends a pull request (via opensource.guide), and the post-xz-utils staged-grant rule. Both hold once access is disaggregated: be generous with the ladder, slow with the keys.

Merge rights are cheap to grant and cheap to revoke, which makes handing them out fast the quickest exit from a bus factor of 1. Signing keys, publish tokens and organization ownership are neither, because a signed release is downstream before anyone notices. Grant those on months of evidence, and say in the document that the pause is policy, not distrust.

A maintainer under pressure - burnout, a persistent contributor, a deadline - needs relief before a successor: hand over scope, triage and funding first, keys last. The 2024 xz-utils takeover is the case study, a multi-year credibility campaign plus pressure on an exhausted solo maintainer producing a signed, shipped backdoor.

## Step 8 - Decide about a fiscal host or foundation, if the question is real

Only open this if the project needs to handle money or must prove vendor neutrality to adopters. Otherwise say so and stop: with neither need, a host adds only obligations.

When it is real, frame it as a trade: autonomy (trademark, release process, decision rules, reporting cadence) for neutrality and financial infrastructure. Rank the host options on effort and on compliance cost, the axis step 2 has no use for. A host adds a reporting obligation and counsel review, and a trademark assignment is one-way in practice: asking a foundation to hand the name back is a negotiation rather than a revert.

See [references/foundation-options.md](./references/foundation-options.md) for host types, entity types, graduation mechanics, money governance and two cautionary entity-risk cases. Recommend a direction, list the requirements not yet met, and mark which are legal gates rather than ranked choices: those go to counsel, not into the ordering.

## When each step becomes urgent

Governance work is cheap early and expensive late, so a crossed trigger outranks the efficiency order and names the step to do next regardless of ratio. Say which the project has already crossed:

- A decision was contested and nobody could point to a rule → steps 3 and 4.
- The same dispute keeps recurring with no written appeal path → step 3's ladder, before it forces a fork.
- The absence factor is 1, or one person holds a credential row alone → step 7 before anything else.
- More than one company employs your maintainers → step 6 now, while moving the trademark and domains is uncontroversial.
- One company employs a majority of maintainers, or holds the trademark → step 6 as a blocker: the affiliation ratio classifies a project as single-vendor (it flagged Redis before the fork), and no messaging changes it.
- Money is arriving, or an adopter asks who controls the project → step 8.

## Invocation examples

| The user says                                          | You do                                                                |
| ------------------------------------------------------ | --------------------------------------------------------------------- |
| "Write a GOVERNANCE.md for my library"                 | Interview, then steps 1-4; skip 6 and 8 unless the answers raise them |
| "Two of us maintain this and I'm burning out"          | Steps 1 and 7 only; the load plan itself is samber/developer-relations-skills@oss-maintainer-sustainability |
| "An enterprise adopter asked who controls the project" | Steps 1, 6, then 8 if they need proof of neutrality                   |
| "We're applying to a foundation next quarter"          | Steps 1-8 in order, readiness gaps as the headline                    |

The deliverable is one review document, validated section by section - a model agreed to in passing produces a document nobody enforces:

```markdown
# Governance review - <project>

## As-is - who decides today, by what implicit rule, where it has failed

## Concentration - absence factor, employer spread, credential holders

## Recommendation - model chosen, alternative considered, monthly hours and what they buy

## Decision rules - per class: who decides, threshold, timer, escalation

## Neutrality - trademark, affiliation ratio, contribution agreement, minutes

## GOVERNANCE.md - the document, ready to commit

## Enforcement - repo settings and credential changes needed to match it

## Succession - trust ladder, inactivity rule, emeritus, end state

## Foundation - needed or not, and the gap list if yes

## Review date - when it is re-examined, and what triggers it sooner
```

## Company-backed and independent projects diverge

A single-vendor project and a volunteer project can share a model on paper and behave nothing alike, so the same ranking lands differently. Everything not named here is common to both.

- **Company-backed.** The risk is invisible control: an internal roadmap meeting, a trademark on a company balance sheet, one shared employer. Fix with per-organization seat or vote caps - adopted while the seat count is still small enough to be uncontroversial - decisions in public issues, and an explicit statement of what the company reserves (brand, hosted product, release timing). State reserved rights up front: what triggers revolt is an assurance that drifts, not a limit that is stated.
- **Independent or volunteer.** The risk is availability: nobody is paid to answer, so unbounded processes stall. Fix with short timers, small quorums, asynchronous decisions, a scope-refusal rule, and funding treated as part of governance.

## Health check and pass threshold

Governance succeeds when it is used, so measure use rather than completeness. Say which of the five are sourced and which are this skill's baselines (evidence base).

1. **Rule coverage** _(self-set)_ - every hard decision of the last 12 months maps to a rule. Target 100%; a miss is a missing rule, not an exception.
2. **Concentration** _(self-set number, sourced metric)_ - absence factor of at least 2, and two holders of every privileged credential. The one threshold worth blocking on.
3. **Alignment** _(sourced)_ - zero contradictions between documented roles and repository permissions; divergence is a named review-blocking anti-pattern.
4. **Timers** _(self-set)_ - every decision class has a stated clock; no path stalls indefinitely.
5. **Exercise** _(sourced expectation, self-set interval)_ - within two quarters, evidence the rules ran once: a maintainer added or moved to emeritus, a vote held, an escalation resolved under the written path.

Iterate until 1-4 pass before committing the document, schedule the check for 5, then re-run annually and after any maintainer change.

## Common failure modes

- **Buying the most expensive model for someone else's reasons.** Lapsed terms are worse than no elections - they remove the accountability elections were meant to add. Adopting a committee weeks before a foundation review, with no history of use, is a recognized anti-pattern (worked case in the template reference).
- **Titles instead of authority.** Roles spread across organizations while decisions stay in one company's internal channel are cosmetic diversity, detected as readily as **neutrality by press release**.
- **A constitution instead of a repair.** Writing new governance during a live trust conflict relocates the fight - one major project produced an elected committee and two forks the same year. Address the conflict first, publish the structure after.
- **No deadlock rule.** Without an escalation path, the loudest objector wins by attrition.
- **Promoting to fix burnout.** Handing keys to whoever is available invites takeovers; reduce scope or pause releases first.
- **Ending without saying so.** When a project is over, announce the end state as a governance act rather than stranding its users in silence.

## References

- [references/governance-models.md](./references/governance-models.md) - catalogue, fit, migration paths.
- [references/decision-rules.md](./references/decision-rules.md) - thresholds, six escalation ladders.
- [references/governance-doc-template.md](./references/governance-doc-template.md) - GOVERNANCE.md skeleton, sized examples.
- [references/succession-playbook.md](./references/succession-playbook.md) - absence factor, credentials, trust ladder.
- [references/neutrality-and-assets.md](./references/neutrality-and-assets.md) - signals, fork cases, worked audit.
- [references/foundation-options.md](./references/foundation-options.md) - host and entity types, money governance.
- [references/published-findings.md](./references/published-findings.md) - sourced figures versus self-set baselines.
- `samber/developer-relations-skills@oss-contributor-onboarding` - the first-contribution path below the governance ladder.
- `samber/developer-relations-skills@oss-issue-triage` - the queue the roles operate.
- `samber/developer-relations-skills@tech-press-relations` - press handling when a governance change draws public scrutiny.
- `samber/developer-relations-skills@developer-community-moderation` - code of conduct and enforcement.
- `samber/developer-relations-skills@oss-sponsors-fundraising` - funding once a fiscal host exists.
- `samber/developer-relations-skills@open-source-company-strategy` - what a company open-sources at all.