When One Maintainer Becomes Many
Governance rarely crosses a developer’s mind until it becomes a problem. A project starts with a single maintainer setting direction, merging pull requests, and shipping releases. Growth, however, introduces the “1+N” problem: once additional maintainers join, questions arise around decision-making, adding new collaborators, workload division, shared vision, and even trademark ownership.
Project teams often react in one of two ways. Volunteer-driven projects tend to defer these conversations until a dispute surfaces, at which point the friction can fracture the community. On the other side, projects backed by large corporations may overcorrect, with legal teams spending months negotiating heavyweight governance frameworks that slow down actual development work.
GitHub’s policy team developed Minimum Viable Governance (MVG) to address this gap: a lightweight, directly implementable governance template for free and open source projects. It is designed to work both for a handful of friends and for projects with competing corporate stakeholders, and is open source itself, allowing teams to adapt it as needed.
A Two-Tier Structure
MVG is an agreement among maintainers, signed and stored directly in the repository. It introduces a two-tier governance model. At the organization level—the umbrella under which multiple projects live—a technical steering committee guides overall direction and coordination. Below that, individual projects operate with lightweight, consensus-based governance among their maintainers.
The agreement specifies five core policy areas, each with a sensible default out of the box:
- Decision-making. MVG defaults to consensus-based decision-making at the organization level. This is a loose agreement based on the stakeholders’ dominant view, taking outstanding objections into consideration—not unanimity. This is the approach that built the net, and it reduces friction and hostile project forks in practice. Organization-level decisions that cannot reach consensus fall back to a majority vote. Individual repositories are consensus-only; if no consensus is reached, the decision is appealed to the steering committee.
- Trademark policy. Neutral ownership of the project’s trademarks is a strong signal of an open collaboration. When a project has a non-profit corporate home, that entity owns the name and logo for the community’s benefit. Without such a home, MVG solves the problem by binding everyone associated with the project to the same trademark policy that governs outsiders. The default policy is drawn from the Model Trademark Guidelines.
- Antitrust policy. The policy states explicitly that participants will not engage in activities violating antitrust or competition laws. This is good legal hygiene, particularly for projects with corporate maintainers.
- Code of conduct. The default is the Contributor Covenant, the most widely adopted code of conduct across GitHub’s open source communities.
- Project criteria. MVG covers open source software, open standards, open hardware, and open data on GitHub. Projects must choose from a limited license list: the Open Source Initiative’s popular licenses for software—with MIT as the default template—the Community Specification or Open Web Foundation Agreements for standards, and the Open Knowledge Foundation’s Recommended Conformant Licenses for data.
Implementation and Growth Path
MVG is intended as a starting point, not a final destination. Teams review the policies, fork the template, fill in the blanks, and get to work. The framework is released under a CC-BY license, so customization and redistribution are permitted—though, as these are contracts, they should be validated before adoption.
It is built as an on-ramp. If a project later needs to hold funds for meetups, conference talks, or hosting fees, the structure can easily be brought to a free and open source software foundation or another corporate form.
MVG is currently in beta. Several alpha versions are already in use, and GitHub is accepting public feedback in the MVG repository over the next few months before a 1.0 release.



