oss_governance v1.0.0

name: oss_governance description: Choose and document an open source project governance model: decision rights, maintainer promotion and removal, voting rules, conflict escalation, succession when a maintainer leaves, trademark control, and when a foundation helps or hurts. Use when starting a project, writing or fixing a GOVERNANCE.md, adding a steering committee or elections, handling a stuck decision or a departing maintainer, or deciding whether to join a foundation.

Open Source Governance

Purpose

Give a project a written answer to five questions before it needs one under pressure: who decides what, how a contributor earns decision rights, how a decision gets made when people disagree, who holds the name and the accounts, and what happens when a key person leaves.

The output is a GOVERNANCE.md the project actually follows, plus a succession plan that has been tested, not just written. Governance that only exists in chat threads or in one person's head is not governance, it is a future argument.

For the fill-in document, read references/governance-template.md. For three finished examples, read references/worked-models.md. For the succession drill, read references/succession-drill.md.

Workflow

1. Take stock before choosing a model. Write down: number of active maintainers in the last 90 days, number of organizations they work for, who holds admin rights on the repo, package indexes, domain, chat, and social accounts, who owns the project name and logo, whether money comes in or goes out, and which decisions caused friction in the last year. A model chosen without this inventory copies someone else's project.

1. Pick the base model, and name it plainly. Use the six models Red Hat documents, alone or combined:

• Do-ocracy: whoever does the work in an area decides that area. Fast and common in small projects. Weakness: authority is invisible to newcomers, and whoever has free time wins by default.
• Founder-leader, also called BDFL: one founder is the final decision maker. Clear and fast while the project is small. Weakness: the founder becomes a bottleneck, and non-founders can feel locked out of any change the founder dislikes. Karl Fogel's test for a working BDFL is restraint: delegate to area maintainers, join discussions as a regular developer, and decide by fiat only when consensus has failed and the group wants a call made.
• Self-appointing council or board: a steering committee, technical council, or committer council picks its own successors and sets its own rules. Works when running elections is too heavy and there is no foundation. Weakness: the group can become self-reinforcing, and contributors wait to be chosen instead of stepping up.
• Electoral: contributors elect role holders on a documented cycle. Kubernetes uses a seven seat steering committee with two year staggered terms. Python uses a five member steering council elected by the core team after each feature release, with no term limits. Weakness: elections take time, can turn contentious, and guarantee no turnover unless term limits are written in.
• Corporate-backed: one company or consortium governs, and may limit outside contributions or require a contributor license agreement. Honest version: say so in the README. Dishonest version, claiming open governance while one company decides everything, is what creates mismatched expectations and forks.
• Foundation-backed: a nonprofit or trade association holds assets and sets ground rules while project leaders usually keep code approval and the roadmap. See step 8 before choosing this one. Most growing projects end up as a hybrid: for example, do-ocracy for day to day code, a council for releases and conduct, and a foundation holding only the trademark.

1. Write the decision rights table first, not last. For each decision class, name who proposes, who must be consulted, who decides, and who can block. Cover at least: routine code changes, breaking API changes, releases, new maintainers, removing a maintainer, changing governance itself, spending money, security response and embargoed fixes, code of conduct enforcement, using the trademark, and adding or removing a subproject. If a row has no decider, that is the finding.

1. Define the contributor ladder with entry and exit for every rung. A workable ladder is user, contributor, reviewer or triager, committer or maintainer, and council or PMC member. For each rung state: the evidence that earns it (sustained, welcome contributions, and count non-code work such as review, triage, docs, support, and release help), who approves it, and what access comes with it. Apache practice is invitation approved by lazy consensus of active PMC members, and that pattern transfers well. Keep the current maintainer list public with name, contact, area of responsibility, and employer affiliation, as CNCF governance reviews require.

1. Set voting rules per decision class, not one rule for everything. Copy the distinctions that have held up in Apache projects:

• Routine and procedural items: simple majority, or lazy consensus with a stated deadline.
• Code changes: consensus approval. Apache requires three +1 votes and no veto, and a veto is only valid with a technical justification attached. A veto without reasons has no weight, and a veto stands until its author withdraws it.
• Releases: majority approval, at least three binding +1 votes and more +1 than -1. Apache releases may not be vetoed. Serious problems stop a release by discussion, not by a single blocking vote.
• Big or irreversible items (new codebase, governance changes, removing a maintainer): a higher bar, commonly two thirds. The CNCF distribution project uses at least 66 percent of current maintainers with a five business day voting period for maintainer removal and for adding subprojects.
• State who casts binding votes and who casts advisory votes, the quorum, and the minimum open period. Apache voting periods generally run at least 72 hours so time zones get a real chance to take part.
• Lazy consensus wording, ready to paste: "If no one objects within three days, I will take silence as assent and go ahead." Never use lazy consensus for conduct sanctions, trademark grants, or spending.

1. Write the conflict path as a ladder with time boxes. Step 1: discussion in the open thread or issue, with a deadline. Step 2: the area maintainer decides and writes the reason in the thread. Step 3: appeal to the council or PMC, which votes under the rules in step 5. Step 4: the named final appeal body decides (the council in Python's model is the court of final appeal) and that decision closes the matter. Keep conduct cases on a separate private path run by the code of conduct team, not by the technical council, and never litigate a person's performance in a public pull request. Private discussion first, then a clean public record of the outcome.

1. Plan succession as a skills pipeline, not a hero pipeline. For every critical function (release manager, security contact, repo admin, package publishing, domain and DNS, chat moderation, trademark contact, bank or fiscal account) list a primary and a backup who has actually done the job once. Bus factor is the number of people whose loss would put the project at risk, and 1 is the worst value. Then:

• Move the project off personal accounts into an organization and add at least one backup admin, as the GitHub Open Source Guides advise.
• Define emeritus status: Apache projects move a committer to emeritus on their own declaration or after no contribution in any form for over six months, and an emeritus member can return by request approved by lazy consensus. Define inactivity the same concrete way, with a neutral person making contact before any removal, and a waiting period after that contact.
• Define removal for cause separately from inactivity, with a high bar. Apache commit access can be revoked only by a unanimous vote of active PMC members other than the person in question. Python's council can replace a member who has been out of contact for a month or longer, and can appoint a replacement for a vacancy for the rest of the term.
• Separate operational access from recognition when someone leaves. Remove repo, package, and security list access, and at the same time thank them by name in release notes or a maintainers history page. Contact the person before removing anything, even if no reply comes.
• Run the drill in references/succession-drill.md once a year and after any maintainer departure.

1. Decide trademark control explicitly. An open source copyright license grants no trademark rights. Whoever owns the name and logo controls who may present a fork, a hosted service, or a conference as the official project. Options, in order of neutrality: a foundation holds the mark, a company holds it with a published trademark policy, or the founder holds it personally (the weakest option, and a common hidden control point). If a company in the community owns the mark, say so and publish the policy that limits its use. The Linux Foundation position is that neutral trademark ownership is a prerequisite for open governance, because the owner must actively control use of the mark or lose the right to do so, and that control sits uneasily in one competitor's hands.

1. Decide the foundation question with a checklist, not a feeling. A foundation tends to help when: two or more competing companies contribute and none will accept another holding the assets, the project needs to hold money, sign venue or vendor contracts, or employ someone, trademark neutrality is disputed, or users need a legal home that outlives any one company. It tends to hurt or waste effort when: the project has one maintainer and no outside money, the main problem is code review capacity rather than asset ownership, or the project cannot meet the foundation's reporting and governance requirements. Cheaper middle paths exist: a fiscal sponsor such as Software Freedom Conservancy, Eclipse Foundation, or Open Collective holds donations for a fee without a full foundation move, and an umbrella foundation hosts smaller projects for an administrative fee. Note the real costs either way: application and due diligence work, documented governance kept current, maintainer lists and elections run on schedule, and decisions that must stay vendor neutral in fact, not only on paper. CNCF graduation, for example, requires maintainers from at least two organizations and a documented way to keep governance decisions balanced across organizations.

1. Write it down, ratify it, and version it. Put the result in GOVERNANCE.md at the repo root using references/governance-template.md, link it from the README and CONTRIBUTING.md, and adopt it by the voting rule it describes for governance changes. Record the adoption vote and date in the file. Amendments follow the same rule, never a quiet edit. Review the document once a year against reality: any place where practice and document disagree is a bug in one of them, and the fix goes in the open.

1. Run the checker on the finished document. Run python3 bin/governance_check.py GOVERNANCE.md from this skill directory against the project's file. It reports missing sections, decision classes never mentioned, missing emeritus or lazy consensus language, and template placeholders still unfilled, and it flags a document with no bus factor or single holder statement. It reads text only: it cannot tell whether the project follows its own document. Treat a failed check as a draft, not a published governance model.

Output Contract

Deliver, every time:

• The inventory from step 1, short and factual.
• The model chosen, in one sentence, with the hybrid parts named and the models rejected with a one line reason each.
• A completed GOVERNANCE.md based on the template, with no placeholder brackets left in it.
• The decision rights table covering every class listed in step 3.
• The contributor ladder with entry evidence, approver, access, inactivity rule, emeritus rule, and removal rule for each rung.
• The voting table: decision class, approval type, quorum, minimum open period, who votes binding.
• The conflict ladder with time boxes, and the separate conduct path.
• A succession table: function, primary, backup, and the date the backup last performed the function, plus the next drill date.
• The trademark statement: owner of the name and logo, where the policy lives, and what a fork may and may not call itself.
• The foundation verdict: join, use a fiscal sponsor, or stay independent, with the checklist answers behind it.
• The checker output, with every failure either fixed or recorded as an accepted gap with an owner.

Operating Rules

• Write governance before a crisis needs it. A rule written during a dispute about a specific person reads as a weapon, and usually is one.
• Count non-code work as merit. Review, triage, documentation, support, and release work are how projects survive, and a ladder that only counts commits builds a council of people who only write code.
• Cap single organization control where the body is elected. Python caps steering council seats at two per employer and disqualifies the lowest ranked excess candidate. Use a cap, a disclosure rule, or both, and publish affiliations either way.
• Never let one person be the only holder of an account, a key, a domain, or a payout method. Shared ownership in an organization account is the minimum, two admins is the standard.
• Keep decisions in the open by default, in the repo or the public list. Private channels are for conduct cases, security embargoes, and personnel matters, and even those end with a public record of the outcome.
• Forkability is the backstop, not the plan. Anyone may copy the code under its license, so governance that ignores the community will lose it. Do not use the threat of a fork as a negotiating move inside the process.
• Do not copy a large project's full machinery into a small one. A solo project needs one honest page, a named backup admin, and a succession note. Bureaucracy that nobody follows teaches people to ignore the document.
• When governance and practice drift, fix one of them in public. Quiet drift is how a council ends up ruling by custom that newcomers cannot see.
• This skill gives process guidance, not legal advice. Trademark transfers, fiscal sponsorship, contributor agreements, and foundation applications go to a lawyer or the foundation's own staff with the facts written down.