Minimum Viable Governance: lightweight community structure to grow your FOSS projects

In my role on the policy team, I hear a lot from developers that drafting project governance is a pain point. For that reason, we made Minimum Viable Governance (MVG), a simple, easy-to-implement governance framework for your free and open source projects. It should work as-is for all projects—those among a few friends or a few mega-corporate rivals. It is open source, so you can modify it to fit your needs.

The 1+N problem

Things get complicated when you move from 1 maintainer to 1+N maintainers of your project. Suddenly, you need to figure out how you’ll make decisions, how you’ll add other maintainers, how you’ll divide work and agree on a vision, as well as who owns the trademark.

There is often either too little or too much negotiation over these decisions. For volunteer-run projects, people often do nothing until there are problems, and those problems can strain or break the community. For projects with large corporate contributors, lawyers get involved and spend months negotiating heavyweight legal governance structures that slow down real work.

The MVG Solution

MVG is an agreement between maintainers that is signed and stored in the repository. MVG provides a two-tier structure for a set of open source projects. At the top level (called an “organization” on GitHub), you choose a group of people to serve as the technical steering committee, making decisions about the overall direction and coordination between all of the organization’s projects. Underneath that top level are the individual projects, with lightweight, consensus-based governance among the maintainers.

The agreement covers five things, with the defaults set out below. Since MVG is open source, you can of course modify the docs to suit your needs.

1. Decision making. MVG defaults to a consensus-based decision making process at the organization level. Consensus does not mean no objection – it means loose agreement by the stakeholders based on their dominant view, and taking outstanding objections into consideration. This is the approach that built the net. In our experience, striving for consensus reduces friction and reduces hostile project forks. At the organization/steering committee level, decisions that can’t be made by consensus fall back to majority vote. Individual repositories are consensus-only, so if a decision can’t be made by consensus, it’s appealed to the steering committee.
2. Trademark policy. Neutral trademark ownership is a strong indicator of a truly open collaboration process. When projects have a non-profit corporate home, that corporate home owns the trademarks—like the project name and logo—so that they are managed for the benefit of the broader community. Without a corporate home, trademark ownership is complicated. MVG hacks these complications by having everyone associated with the project agree to be bound by the same trademark policy as those not associated with the project. The MVG default trademark policy is based on the Model Trademark Guidelines.
3. Antitrust policy. This policy makes clear that participants collaborating on projects using MVG will not engage in activities that would violate antitrust or competition laws. This is good legal hygiene, particularly if there are maintainers from corporations.
4. Code of conduct. MVG defaults to the Contributor Covenant. This is the code of conduct most widely used by GitHub’s open source communities.
5. Project criteria. MVG is meant for open source software, open standards, open hardware, and open data projects on GitHub. By default, MVG includes a policy that projects must select from a limited list of open source licenses. For open source projects, these are Open Source Initiative’s list of popular licenses, and MVG’s template project license is MIT—the most widely used open source license. MVG defaults to the Community Specification or Open Web Foundation Agreements for standards and the Open Knowledge Foundation’s list of Recommended Conformant Licenses for data.

Some details

MVG is designed to be simple, yet robust. Once you review and make sure it’s right for you, fork a copy, fill in the blanks, and get to work. MVG is open source, under a CC-BY license, so you can modify the docs to suit your needs and reshare them. Remember these are contracts, so you should make sure they’re right for you.

MVG is meant to be an on-ramp. If your project takes off and needs to hold money for meetups, conference talks, hosting fees, or anything else, it’s easy to take this structure to a free and open source software foundation or other corporate form.

Feedback

MVG is still in beta. We want your feedback! There are a few alpha versions in use, but like all things, there is room for improvement. We’ll be accepting feedback from anyone over the next few months in the MVG repo before we release a 1.0 version.

Thanks!

Finally, thanks to the many GitHub teammates and other folks who reviewed and provided feedback prior to this beta release, particularly Pam Chestek and Aaron Williamson.

Follow GitHub Policy on Twitter for updates about the laws and regulations that impact developers.

Written by

Justin Colannino

@royaljust