For context, Gov4Git is a platform for augmenting the standard collaborative development workflow — based on issues and pull requests (in GitHub parlance) — with a governance and economics mechanisms. From a software perspective, Gov4Git provides an SDK for building mechanisms, as well as a runtime and an app for deploying mechanisms to projects on GitHub, or other similar systems.

Governance and open source

Every collaborative project has governance. It is the set of rules and processes — be it explicit or implicit, ad-hoc or premeditated, written or unwritten — that determine prioritization of concerns, decision-making on proposals, and attribution of credit to individual collaborators.

At first glance, governance dictates how participants collaborate, and how they are compensated for their effort.

But, in fact, it is more than that.

Governance — indirectly — also determines whether participants are willing to collaborate, for how long, and to what degree of involvement. In this regard, collaborators judge the governance system itself to determine if it is able to nurture the type of community that they want to be a member of. They judge if the rules of governance reflect their values and whether their contributions will be acknowledged fairly.

Software development that happens within the context of a business entity — such as startups, corporations, or foundations — inherits the governance (also known as “management”) mechanisms and their enforcement from the business.

On the other hand open source — in its purest and most popular form — is practiced outside a business or organization. As a result, open source often defaults to a simple ad-hoc system of governance, which is typically influenced by the available tools for enforcement, rather than the needs of the community. For instance, most open source projects on GitHub are essentially forced to adopt a non-nuanced, two-tier hierarchical system of maintainers and contributors.

We believe that this inattention to the governance needs of open source communities is the main cause of well-known problems in open source — lack of sustainable maintainership and support, lack of funding, supply chain vulnerabilities, as well as community fragmentation upon commercialization or institutionalization of impactful projects.

We think that open source communities should have both tools and standard templates of governance, much like tech companies (from startups to large corporations) have tools and templates for all matters of business — management, finance, compensation, bookkeeping, HR, and so on.

The governance of any community must reflect its ethos, as well as the circumstances that brought members into the community.

While there is no one concept of an open source ethos, most varieties share a common core of tenets, which includes transparency, inclusivity, and fairness. Waimea is a governance mechanism which presents one possible formalization of these values:

• Transparency is provided by the Gov4Git protocol itself wherein, by design, the logic as well as the record of all operations of governance is kept in an always-accessible, immutable ledger
• Waimea embodies inclusivity by utilizing a flat organization whereby all collaborators are subject to the same rules and opportunities. (This is not to say that everybody is equal or undifferentiated within the community. Productive strategic behavior may award some with more effective power or stake than others.)
• Waimea embodies fairness by rewarding productive behavior that aligns with community preferences (and penalizing the opposite), in a quantified manner, using a market-inspired approach that leverages peer review.

Principle of operation

Central to the operation of Waimea is a virtual community currency, called credits. Credits represent stake in the community’s project, and they can be spent within the community to exercise influence on the development trajectory.

Credits are issued by the governance system, in a manner (described later) that ensures the total supply reflects the amount of work performed by the community since its inception. In other words, the community has an inflationary economy.

Credits are held by community members, or staked into issues and PRs in the course of the day-to-day collaborative workflow.

Waimea’s mechanism is centered on the relationship between issues and PRs. As usual, issues describe ideas or tasks or goals (such as bugs to fix, new features, requests for support, etc.) that the community may (or not) be interested in addressing. Whereas pull requests represent proposed solutions to one or more issues.

Issues and prioritization

Virtually every healthy project is perpetually in a state where there are more issues than there are community resources to address them. This is why the first key function of governance is to prioritize which issues are addressed first.

To do this, Waimea associates a priority poll to every project issue. For as long as an issue is open, community members can influence its priority (up or down) by staking a desired amount of their personal credits, expressing the intensity of their opinion. Eventually, when the issue is cancelled or resolved, staked credits are refunded in full. Nevertheless, participants are wise to stake their credits judiciously, as staked credits could not be used for anything else while weighing on priorities.

Besides providing visibility into the community’s preferences, the priority of issues plays a role in incentives to undertake work. The author of a successfully merged pull request that addresses a given issue is awarded a bounty, one of whose components is proportional to the priority of the issues that it resolves. The funds for such bounties are issued by the governance system. The key concept here is that the priority of an issue represents the community’s opinion about the value of resolving the issue, while the issuance of new funds ensures that the total supply of credits matches the total value of work that has been merged into the project.

Pull requests and approval

Pull requests are proposals to make long-lasting changes to a collaborative project. Short of small adjustments that reviewers can request during review, pull requests call for a binary decision whether to adopt (or not) the proposed changes. Arbitrating this decision is the second key role of governance.

As with issues, collaborators can create pull requests freely. Waimea automatically associates an approval poll with every pull request. Approval polls work similarly to priority polls — they provide a venue for community reviewers to express their opinion (for or against the adoption of a pull request) quantitatively and asynchronously, for as long as a pull request is open.

Like priority polls, approval polls require staking of credits, and therefore they involve similar strategic considerations on the part of participants.

Unlike priority polls, when a PR is closed (accepted or rejected) credits staked in the approval poll are awarded to the voters who predicted that outcome. Specifically, voters who predicted the outcome are refunded in full. Additionally, the total stake of voters who did not predict the outcome is distributed to the voters who predicted the outcome in proportion of the vote strengths of the latter. E.g. if a PR is accepted, all who voted “for” are refunded, and the stake of all who voted “against” is awarded to the “for” voters. This award mechanism is designed to encourage alignment amongst reviewers, as well as greater care and attention in the cases of controversial PRs.

In the event that a PR is accepted, its approval score also contributes to the bounty awarded to the contributing author — in addition to the contributions (described above) arising from resolved issues. The contribution to the bounty is proportional to the approval score and the funds for it are issued by the governance system.

Like the component of the bounty arising from resolved issues, the component arising from the approval score of a PR reflects the community’s opinion of the value of the work associated with reviewing the PR. In the same spirit, the funds issued to fulfill the PR component of the bounty ensure that the main economic invariant of the community holds true — i.e. that the total supply of credits in circulation is a reflection of the total amount of work absorbed by the project.

Credits as a form of ownership

As the reader has seen by now, our mechanism implements an inflationary economy, where new credits are issued upon successfully merging a PR. Furthermore, the amount issued aspires to represent the community’s opinion of the value that this PR brings, along with the associated value of review.

As a result, the total supply of credits in circulation could be viewed as a peer-reviewed measure of the total value of the project in its current state.

Consequently, the credits owned by individual collaborators have a natural interpretation as stake into the project. In this regard, credits are akin to the stock shares that startup companies use to compensate their employees.

While credits are a virtual device, they are not worthless. They provide a mechanism to reward its past and present contributors retro-actively in real terms. In the event that a community project interfaces with the real economy — such as being remunerated for its impact (e.g. through a charitable grant), or is commercialized (as a startup), or is institutionalized (into a foundation) — its contributors could and should be compensated proportionally to their holdings of community credits.

We should note, that the only other source of credit issuance is the capitalization table of the founding members of the community. The first members must elect an initial distribution of credits for themselves, in order to introduce credits in circulation and thereby spark the collaborative economy.

Waimea also leaves open a provision for issuing credits to participants who contribute to the community in ways other than collaboration — such as contributing monetary or other real benefits to the community. It is left to the community to decide how to value such non-collaboration contributions in terms of credits.

How things work in practice, on the ground

The playground for governed collaboration is the issue and pull request system that the community uses. We currently support GitHub, and are expecting to have integrations with other providers.

Waimea communities are permissionless — everyone is allowed to join a community by sending a join request from the desktop app. Upon joining, а new member begins with zero credits in their account. Members can earn credits by productive participation or by voluntary transfers from other members.

Participation in the community is based around the lifecycle of a code change, which begins with the creation of an issue describing a goal, and ends with the approval and merging of a PR that resolves the issue.

Issues

Every collaborator can create issues freely. Waimea associates each issue with a priority poll, which determines the priority score (a real number) of the issue and affects the bounty for the contributor who eventually resolves the issue through a pull request.

The priority poll is a mechanism which allows members to affect the priority score (up or down) by staking their credits to the issue. Polls are based on a quadratic design, whereby a stake of `P` credits affects the priority score by `SQRT(P)` points — up or down, as desired. Members are allowed to adjust their stakes asynchronously, as long as the issue is open and there is no eligible pull request claiming to resolve it.

The life of an issue terminates in one of two ways — it can be cancelled (triggered by closing it manually on GitHub), or it can be resolved (triggered by merging a PR that addresses it). In both cases, the credits staked by community members to the issue’s priority poll are refunded.

In the event that an issue is resolved by a PR, the community governance issues new credits — equal in quantity to the priority score, if it is positive; zero, otherwise — and contributes them to the bounty for the author of the PR.

Pull requests (PRs)

Similarly to issues, every collaborator can create pull requests freely. The contributor of the PR can make a claim that the PR resolves zero or more issues. To claim an issue, the description of the PR must include a claim statement of the form:

claims https://github.com/ORG/REPO/issues/ISSUE_NUMBER

Waimea associates each PR with an approval poll, which determines the approval score (a real number) of the PR. The approval score affects the bounty awarded to the PR contributor, if the PR is accepted and merged.

The approval poll is a mechanism which allows members to affect the approval score (up or down) by staking credits to the PR. Approval polls are based on the same asynchronous quadratic mechanism used by priority polls (described above).

The life of a PR terminates in one of two ways — it can be accepted (triggered by merging the PR on GitHub), or it can be rejected (triggered by closing the PR on GitHub).

If a PR is accepted:

• The issues it claims are resolved (and automatically closed on GitHub), and their bounties are awarded to the author of the PR
• Reviewers who voted for the PR are refunded their stakes
• The credits staked by reviewers who voted against the PR are distributed to the reviewers who voted for, proportionally to the strength of their votes
• The community governance issues new credits whose quantity equals the approval score of the PR, and awards them to the contributor of the PR

If a PR is rejected:

• Reviewers who voted against the PR are refunded their stakes
• The credits staked by reviewers who voted for the PR are distributed to the reviewers who voted against, proportionally to the strength of their votes

Frozen issues

A PR is said to make an eligible claim on an issue, if the PR claims the issue and the PR’s approval score — a number that can very dynamically — is bigger than zero.

Whenever an issue has eligible claims, it becomes frozen. Similarly, when there are no eligible claims it becomes unfrozen. Whenever an issue is frozen, votes or vote adjustments on its priority poll are not accepted.

Maintainer vs autopilot governance

Each community has a distinguished set of maintainer users. In the context of our integration with GitHub, the maintainers are the GitHub maintainers of the project repository.

Maintainers can have anywhere between a minimal and a full, hands-on involvement in the governance of the community.

At a minimum, maintainers are responsible for establishing who the first community members are, and issuing initial sums of credit to them.

On the other end of the spectrum, maintainers can exercise any of the following operations at their discretion, in a manner that is always transparent to the community:

• Accept new members to the community, or remove existing members
• Issue, burn, or transfer credits to, from, or between any accounts
• Cancel issues
• Accept or reject PRs regardless of the popular vote

Contact us and try our solution

We are actively looking for trial and early adopter communities. We think that the current release of Gov4Git, equipped with Waimea, is ideal for community managers and open-source communities of peers. Get in touch with us and briefly tell us your use case. We are looking forward to providing our trial users and early adopters with support and attention every step of the way.

In February of 2024, we released the first public preview of Gov4Git, versioned v2.1.1, and deployed it to the Plurality Book community.

We wish the plurality community happy and productive book editing!

Gov4Git supports multiple policies which can be activated on individual issues and pull requests by applying a policy-specific GitHub label to the issue or pull request.

In our latest release, v2.1.1, we introduced the Plural Management Protocol — described in our research paper — whose policy label is “gov4git:pmp-v1”.

Today the mechanics of team/collaborative software development are well-understood, settled and essentially standardized in software. Both open-source and enterprise use ticketing in combination with version control to capture the entire product development workflow.

On the other hand, the governance of collaboration is not aided by any software tool or known standard process.

Why the problem matters

Governance is the management of collaborators and their incentives within an enterprise.

In software product development, governance manifests in three day-to-day needs:

- Prioritization: Which issues are addressed first

- Decision-making: What code changes make it to the product

- Attribution: How are individual contributors (ICs) rewarded for their contributions relative to others

In businesses and institutions (startups, corporations, foundations) with rigid roles (leaders, managers, contributors), all three responsibilities of governance are performed by leaders and managers.

But in most non-institutional product collaboration — as well as in some collaboration layers within institutions (early startups, middle layer of enterprises) — clear roles are either absent or too inefficient to adopt. All of open-source falls within this category.

To put this differently, centralized collaborations (businesses, institutions) can implement roles, albeit at the cost of middle-management inefficiencies. Decentralized collaborations (organic open-source) have generally not been able to adopt rigid roles.

Lack of clear roles causes lack of clear responsibilities, lack of fair attribution and seniority, arbitration deadlocks, and ultimately low-velocity and low incentive to participate.

Approach: An open and fair algorithmic economy for peers

Gov4Git addresses the problem of governing initially-undifferentiated collaborators by engaging them in a community-scope market economy that enables and incentivizes individuals to maximize their stake by productive participation.

A community currency of “credits” quantifies the stake and influence of participants, and enables profitable behavior through productive contributions and peer-review.

Gov4Git equips all critical tasks in the product development cycle — regardless of their type (leadership, management, or contribution) with a market mechanism open to everyone, which arbitrates conflicts, rewards impactful participation retro-actively, and penalizes unproductive engagement of community attention.

Our market mechanisms integrate in the standard development cycle in the form of ticket (e.g. GitHub issue) prioritization and merge request (e.g. GitHub pull request) review and approval.

All collaborators can participate in all tasks. However, entering participation requires an investment, which can be profitable or unprofitable depending on its impact and alignment with the community’s opinions and peer-reviews.

Technology: Low-cost, decentralized, trusted computation

It is no insight that “trusted computation” — as embodied by all forms of Byzantine-fault Tolerant State Machine Replication, or alternatives such as blockchain smart contracts — is the highest form of credible and transparent algorithmic governance.

For the purposes of Gov4Git, we developed an architecture for decentralized trusted computation which is in stark contrast to blockchain-based solutions.

Our system can be deployed by any group of possibly non-technical end-user collaborators, who individually have access to git hosting — generally available to most open communities at zero cost (e.g. via GitHub, GitLab, and so on).

Users interact with Gov4Git through a desktop app, which manages their decentralized identity and safeguards the history of their interactions with the community governance.

## Benefits of Gov4Git

Any git-based project can adopt Gov4Git governance, either from the start, or mid-journey. We see substantial benefits from adopting governance, and distributing your products along with their governance records.

- Sustainability: Fair quantification of individual collaborator’s contributions and stake in the community enable fair retro-active distribution of funding, charitable grants, or commercialization benefits — a mechanism that attracts and incentivizes collaborators to stay.

- Authenticity: Governance records attest to fair and inclusive practices, as well as establish alignment amongst participants.

- Velocity: Market-driven arbitration leaves no room for decision deadlocks.

- Supply Chain Security: Package managers that distribute software with governance records can mechanically verify that critical updates are approved by large numbers of stakeholders.

We are building Gov4Git: a low-cost, decentralized protocol and software for trusted and transparent governance of collaborative communities based on git. Gov4Git aims to empower collaborative communities within open-source projects to autonomously and transparently self-govern in an efficient and fair manner. We believe that open-source projects equipped with governance will attract and sustain more contributors, experience less friction to commercialization or institutionalization, and enjoy a larger and sustained public impact. Furthermore, open-source projects distributed with governance records can mitigate a substantial class of software supply chain vulnerabilities.

Problem space

The standard collaborative development (SCD) workflow — which is based on a ticketing system (such as GitHub issues) and a code review system (such as GitHub pull requests) — captures the planning and execution side of the life of a project. The other side — governance (and management) — is not captured by any standardized tools as best we know. In open source, governance is typically provided either by an overarching company or institution, but most frequently it is ad-hoc and based on the benevolent dictator model that is the project’s initial owner.

Governance, in general, addresses three key aspects of collaboration, not captured by SCD: prioritization, decision-making, and attribution. Prioritization manifests in which tickets (or issues) are addressed first. Decision-making manifests as the criteria for accepting code changes (or pull requests). And, attribution — not manifested in SCD — quantifies the stake (or ownership) in the project of collaborators, based on their involvement and contributions over time.

Most open source communities are permissionless or composed of peers, especially at formation. They have no option but to resort to an ad-hoc benevolent dictator model until their product has matured enough to demonstrate real commercial or public value, which often takes multiple years.

During these formative years, the ad-hoc governance model creates immense frictions to growth, survival, success and developer satisfaction.

A growing community of collaborators imposes a significant management, transfer-of-knowledge, and review burden on the benevolent project owner. As communities grow, the diversity of tenure, expertise and contribution of its members grows too. The absence of a clear, transparent, and equitable framework for conflict-resolution, decision-making and attribution dissipates the incentives to participate and creates deadlocks.

Ad-hoc communities also lack a quantified method of fair attribution, which manifests itself in absence of long-haul incentives to participate, and difficulty in commercializing or retroactively funding the project — due to lack of reliable stakeholder information.

Approach

Gov4Git provides an out-of-the-box decentralized self-governance system, which utilizes incentive mechanisms to fulfill all responsibilities of governance (prioritization, decision-making, and attribution) in an equitable and efficient manner.

Gov4Git introduces a virtual community currency of (participation) credits, which are issued — as determined by the community — to incoming members. In the hands of a community member, credits represent ownership stake, which in a future commercialization or valuation event could be converted to real stake. Within the community, credits can be exercised strategically to influence prioritization and decision-making, resulting in profits or losses for participants depending on community outcomes. Credits can also be earned by making project contributions, which are themselves valued by a market mechanism.

When prioritizing tickets (or issues) and reviewing decisions (or pull requests), community members can weigh outcomes by “betting” credits — for or against — that capture the intensity of their opinions. Credit capital locked in these bets is eventually awarded to members who prioritized, reviewed and contributed — in a manner that rewards support for the eventual outcome and penalizes opposition to it.

This mechanism, combined with SCD practices, democratizes access to all tasks and roles (management, leadership, contribution) to all community members. However, it also incentivizes members to choose the tasks they are best suited to succeed in.

The credits accumulated by a community member (at any one time) are a form of fair market value for their lifetime contributions, according to their peers. This economic device ensures that contributions of any size, duration or capacity are rewarded — at least in virtual bookkeeping — fairly.

Technology

Gov4Git is embodied by a decentralized protocol — based purely on git — and a set of portable clients (desktop, mobile, web), together with deep integrations with popular SCD providers such as GitHub. The persistent infrastructure required for deployment is git hosting and nothing else, which results in a low to no-cost solution for most open-source communities. Both deployment and participation in Gov4Git communities can be accomplished by non-technical users, using our UI clients, in the matter of seconds.

The governance mechanism runs as trusted computation, realized as a Byzantine fault-tolerant state machine replication (BFT SMR) within the community which, similarly to blockchain smart contracts, ensures provable correctness and immutability (but without relying on any blockchain technology). The system provides full transparency to audit, in order to ensure trust by community members and outside stakeholders.

Each community deployment requires that all community members own personal git repos, and have connectivity to each other. This minimalistic requirement enables communities that are disconnected from the public internet — such as those under oppressive regimes or war zones — to take full advantage of our software.

Timeline and key milestones

• 2023 Nov
  - We completed the first private trial deployment for our partners Microsoft Research and GitHub
• 2024 Jan
  - We released the first public preview of Gov4Git, whose governance mechanism is based on the Plural Management Protocol (PMP). We also launched the first public dogfood deployment of Gov4Git in our own roadmapping community
• 2024 Feb
  - We plan our first official public deployment on the Plurality Book Project in collaboration with Microsoft Research, GitHub, RadicalXChange, and Audrey Tang
• 2024 Q2
  - Aspire to acquire two public open-source institutional deployments in the AI safety and alignment space — we think Together Computer, Hugging Face, Stanford Human-Centered Artificial Intelligence Lab, and a few others can be a great fit
  - Aspire to acquire one public trial with a Web3 effort — we are pursuing Filecoin and Ethereum Foundations, among others
• 2024 Q3
  - Fine-tune our governance mechanism, PMP, based on analysis of our public deployments, in collaboration with Management Science Researchers from HBS, Microsoft Research, MIT, and others.
  - Submit one peer-reviewed publication reporting our measurements and insights
• 2024 Q4
  - Release the first self-serve, general-use, production-grade version of Gov4Git, accompanied by a full-featured, portable desktop app, with governance mechanism based on the Plural Management Protocol.
• 2025
  - Build a production-ready mobile app for Gov4Git
  - Build a Byzantine fault-tolerance layer, enabling multiple community validators
  - Design and build a plural enterprise management protocol
  - Introduce messaging, cross- and intersectional community features
  - Acquire deployments with large open-source initiatives, such as US government, GAIA-X
• 2026
  - Release an SDK for developing custom, verifiable governance mechanisms in the Lean Language

Impact

We stipulate that many collaborative open-source endeavors never take off the ground, or stall during their formative stages, due to the lack of clear and trusted governance and incentive structure.

We also believe that mature and popular open-source projects experience unreasonably high friction to “exit” into commercialization (such as forming a COSS startup around them, for example) or public funding. This is caused by the lack of a legitimate and quantified ownership information for its original developers, which disincentivizes them to continue contributing after an “exit” event — a problem which in traditional companies is resolved by fair distribution of company stock and “golden cuffs” practices.

Finally, we believe that open-source projects with mechanically-verifiable governance records — such as Gov4Git — significantly reduce security risks in global open-source supply chains. Gov4Git governance records enable package managers (such as npm, for example) to check whether all code changes have been signed and approved by a substantial majority of project stakeholders. This measure prevents disgruntled rogue developers of popular packages from injecting malicious code in the global supply chain — a problem which manifests itself multiple times every calendar year.

Today we are thrilled to announce the first public release of our governance protocol for git — Gov4Git — and share with you what brought us here, and where we are headed.

What is governance and why does it matter, anyway

We view governance as the set of rules and norms that coordinate and reward participants in a collaborative enterprise. Governance mediates decision-making, determines incentives for participants, and enables an interface to the outside world of business and society.

Every group of collaborators has governance — be it implicit or explicit, digital or on paper, ad-hoc or premeditated. States, companies, unions, communes, religious institutions, open-source projects are all held together by the governance structures they have cultivated for themselves.

Governance is not “solved”. Constitutions and laws change, companies innovate “cultures” — for centuries and going. All of this effort is dedicated to a singular goal — to grow sustainable communities of happier and more productive individuals.

So, what is so special about now?

The present times hold a unique confluence of high-impact opportunities for innovation in governance and technological capabilities.

Over the past 30 years open-source has emerged as an ad-hoc collaborative phenomenon with a massive, but mostly implicit and indirect, impact on the world economy. It requires no mention that cell phones, search engines, driverless cars, robotic dogs or next-day delivery would not exist without open source.

While these products are thoroughly integrated in economies and markets, their open-source foundation exists in a mostly opaque shadow economy. This situation is the definition of an economic externality at scale.

We think the issue hides in plain sight. In its essence, an open-source project is very similar to a company. Its developer community grows from one to many, and its product grows from rudimentary to mature — all over time. But herein also lies a stark contrast.

Growing a small startup into a publicly-traded company is critically aided — from the start — by business mechanisms that provide fairness and coordination (via management), attribution and compensation (via stock) and funding (via forward-looking deals with outside economic players).

There are some open-source projects that have reached maturity — and eventually became commercialized or institutionalized — without any of these aids.

We believe open-source projects should be recognized as the “new” lean startups, and they should be afforded streamlined and cost-effective tools for growth, just the same.

Open source is uniquely amenable to benefit from an automated governance mechanism to aid growth, due to the effectively standardized workflow — based on issues and pull requests — adopted by most.

With these insights we’ve set out to create a holistic governance system for collaborative source development, which streamlines and formalizes prioritization, decision-making, attribution, and bookkeeping. And which enables diverse and multi-talented participants to fluidly take on tasks of leadership, management or contribution.

It is our intention to equip every team, regardless of size or maturity, with the due diligence and bookkeeping processes currently afforded only to well-funded companies. We believe this is a prerequisite for enabling an eventual frictionless transition to funding, institutionalization or commercialization.

Gov4Git, the product

Gov4Git — a decentralized protocol and software — is our way of accomplishing this vision.

Right from the start we recognized that governance is an evolution more so than a solution. This is why, first and foremost, Gov4Git is a platform for augmenting standard and existing collaborative development practices with economics, management and bookkeeping mechanisms, along with requisite infrastructure for experimentation, transparency, audit, analysis and security.

Gov4Git is independent of existing software management systems (such as GitHub, GitLab, Gitea, Gerrit, Jira, and so on), sporting its own model of the software development lifecycle which was designed for seamless integration with existing systems. As of today’s launch, Gov4Git provides a deep integration with GitHub.

Atop this powerful platform, today we are also releasing our first application — the Plural Management Protocol (PMP) for collaborative communities. PMP is a comprehensive mechanism for collaborative self-management. It introduces pluralistic incentivized workflows for prioritization (of issues), decision-making (on pull requests (PRs)), as well as an equitable quantification of contributor impact and stake in the community.

PMP is itself the first step in a pioneering effort to design a reusable protocol for self-governance of fair and sustainable communities of collaborators. PMP rests on the groundbreaking research of our team members in the management, political and social sciences, such as the recent invention of Quadratic Mechanisms.

For us Gov4Git is a substantial undertaking, not unlike a mission to Mars. We are anxious to launch it in the wild, and we are prepared to observe, learn, analyze, fix, improve and update the system while the ship is flying — deployed in your respective communities.

Gov4Git, the people

The Gov4Git project emerged one and a half years ago from a spontaneous collaboration of two working groups, one from Protocol Labs and one from Microsoft Research, which ultimately became an official partnership.

At Protocol Labs, I (Petar Maymounkov) had developed a keen appreciation for the power and challenges of inclusive decentralized development at scale. This led me to investigate self-governance in all of its aspects — technology, trust, security, economics, ethics — and ultimately to encounter Glen Weyl who, along with his colleagues, had impressive accomplishments in the parallel topic of plurality.

This serendipitous encounter gave shape and direction to our aspiration to build a practical governance system for open source. Ultimately governance is a hard experimental enterprise as it needs real-world use to glean insights. At the time, Glen and Audrey Tang — renowned as the inaugural Minister of Digital Affairs of Taiwan — were planning a large collaborative experiment aiming to result in the first crowd-authored book on tools for digital democracies, known as the Plurality Book Project. This experiment became our first “customer” and informed the roadmap to our present release.

We were soon joined by Kasia Sitkiewicz to head business development and public relations, but really to do a lot more than that. Kasia has been instrumental in building our team and connecting us with like-minded organizations and people around the world who are genuinely passionate about open source. With her help we were able to discover our unique and thoughtful design collaborators Shivani Thakur , whose creative contributions have added a beautiful and distinctive aesthetic to our project and Theresa Merchant, as well as Abigail Cabunoc Mayes who brings a unique perspective on open-source collaboration from her years of experience with Mozilla Foundation and GitHub.

We were very fortunate and grateful to have Microsoft Research donate our engineering and management collaborators — Jason Entenmann, Derek Worthen, and Nathan Evans. These folks have been indispensable for the realization of Gov4Git as a polished end-user product. Nothing in the Gov4Git stack is standard. It has taken serious effort and creativity to meet our high bar of decentralization, while maintaining a seamless user experience.

No less significant piece of the puzzle is our research scientists Leon Erichsen, Shrey Jain, and Tobin South. They are the creators of the Plural Management Protocol, which is a product of their remarkable knowledge and ability to model the subjective nuances of the social and organizational sciences into precise mathematical mechanisms. Beyond their technical contributions, Leon, Shrey and Tobin are active participants in the public discourse on DAOs, AI alignment and safety, social media and society — with numerous educational and inspirational podcasts and articles under their belt.

We are also very honored by the continued enthusiasm of volunteer collaborators joining our team, and thus recently welcomed Aaron Wolf as a user experience and product research expert.

Everyone on our team has been vital to giving life to Gov4Git. I know we are all very thankful and appreciative of each other. And I look forward to the exciting and uncharted future.

One last thing

Last, because it is most important: Gov4Git aspires to become the go-to solution for collaborators around the globe. Getting there is no less a product of its users than of its developers. We will very much rely on and anticipate the feedback and insights of our users. In return, and with time, we hope to reward our users with true and equitable ownership in Gov4Git, using its own devices.

While Gov4Git aspires to address a comprehensive scope of challenges in open source workflow and community management — such as attribution, fairness, transparency, security — this first release is aimed at being a practical superpower for project maintainers.

In our experience, maintainers of popular open source projects can find themselves unable to take full advantage of the large number of contributors and volunteers their project enjoys, due to the heavy management burden that falls on them.

Maintainers must triage, educate, review, and contribute. These responsibilities can make them a bottleneck to project velocity, and in more extreme cases can cause burn out.

To address this issue, we designed a governance protocol — called the Plural Management Protocol — that enables maintainers to delegate many of their responsibilities to the community, while still being able to influence the project’s focus and direction to any desired degree.

We determined that there are two key management factors that influence the focus and direction of any collaborative project: prioritization and decision-making. Prioritization controls where the community spends its efforts. And decision-making controls the quality of contributions that are accepted into the project.

These factors are conveniently embodied in the familiar software development workflow in the form of issues and pull requests. Issues describe tasks to be done, while pull requests capture proposed solutions to specific issues.

The goal of good management is to ensure that contributors have incentives to work on higher priority issues, and to aspire to high quality contributions. Ensuring this traditionally falls on maintainers by means of triaging and reviewing all pull requests.

Gov4Git substitutes the traditional workflow with a market-inspired incentive mechanism.

Gov4Git is based on a virtual community currency, called (plural) credits.

Community members participate in the prioritization of issues by spending credits for or against the priority of any one issue. Credits spent on prioritization are held as a bounty to be awarded to the contributor of the pull request that resolves the issue.

Community members also participate in the decision-making over pull requests by spending credits for or against the approval of any one pull request. Credits spent on dis/approval are held as a reward, which is distributed to the reviewers whose approval spending (for or against) predicted the eventual outcome of the pull request.

The goal of this simple mechanism is to enable a rich set of constructive strategic behaviors, while incentivizing quality, focus and alignment on direction. Participants can spend to exercise influence, or earn for contributions and participation in decision-making on the popular side.

Maintainers are provided one additional device to exercise control — they can issue credits to themselves or other community members. This simple tool, when used thoughtfully, enables them to control the degree and specificity of their involvement in steering prioritization and decision-making.

We hope you find this a compelling proposal and give it a try on your GitHub project.

We worked hard to make sure Gov4Git can be deployed seamlessly alongside any GitHub project, and can be used easily by non-technical users.

Try Gov4Git

We invite you to visit our first adopter — the Plurality Book Project — to see Gov4Git in action by taking a look at the governed issues, pull requests, and the community governance dashboard.

Install the desktop application to join and participate in the governance of any project on GitHub that is governed by Gov4Git.

Deploy governance to your GitHub project and experience Gov4Git as a maintainer.