Open Source Policy — Governance That Accepts Pull Requests

The comparison between governance and software is not merely metaphorical. Both are instruction sets for complex systems. Both have explicit rules and implicit assumptions. Both produce emergent behaviors that their authors did not fully anticipate. Both can be forked — a community that disagrees with the governing body's rules can form a new organization with different rules, just as a development team that disagrees with a project's direction can fork the codebase.

What open-source software development discovered, over several decades and millions of contributors, is that distributed contribution at scale produces higher-quality code than centralized expert authorship. This is not because individual contributors are more talented than the core team — often they are not. It is because no individual or small group can fully anticipate how code will behave across all the contexts in which it will be used. The people who encounter a bug in production are irreplaceable sources of information about what the system is doing in conditions its authors did not test.

The same logic applies to policy. A regulation governing, say, sidewalk maintenance in a neighborhood was written by people who understood the general problem. But the people who navigate that sidewalk every day with a mobility device, or who operate a business adjacent to it, or who are responsible for maintaining a specific segment that has unusual conditions — these people know things about the regulation's edge cases that its authors could not have known. The pull request model creates a channel through which that knowledge can flow back into the governance system.

For a community organization to implement open-source policy practices, it needs to design several components deliberately.

Publication in accessible, commentable formats. The first requirement is that policies actually be findable and readable. This is not as trivial as it sounds. Many community organizations have governing documents scattered across email threads, filing cabinets, and institutional memories. Consolidating all policies into a single, searchable, publicly accessible location is a prerequisite for any open contribution process. The format matters: PDFs are archives, not collaboration surfaces. Editable documents with comment permissions — or platforms designed for collaborative document editing — are the appropriate medium.

A defined submission pathway. Without a clear process, proposed changes arrive in random formats through random channels and get lost. An open-source policy process needs a defined pathway: here is how you propose a change, here is the information you need to provide, here is where the proposal goes when you submit it, and here is when you can expect a response. The pathway should be as simple as possible. Barriers to entry — lengthy forms, mandatory meetings, complex formatting requirements — are filters that reduce participation and favor people with time and bureaucratic skill, which is rarely the population whose contributions are most needed.

A tracking system. Every proposal needs to be trackable. A public-facing log showing all submitted proposals, their current status (under review, accepted, declined, deferred), and the reasoning behind completed responses is the open-source equivalent of a project's issue tracker. This log serves multiple functions: it shows contributors that their proposals have not disappeared, it creates accountability for the governing body to respond within committed timelines, and it creates a public record of the community's ongoing dialogue about its own rules.

A genuine response obligation. The governing body must commit to providing substantive responses to all proposals. This is the hardest commitment to maintain, because it requires time and care, and because some proposals will be bad and require tactful handling. But the commitment is essential. A process that reliably declines proposals without explanation quickly becomes indistinguishable from a suggestion box. The response does not have to be long. "We are declining this proposal because it conflicts with Section 4.3 of our bylaws for the following reason, and we suggest the proposer consider engaging with the bylaw revision process instead" is a complete and useful response.

The Athenian procedure of graphe paranomon was an early form of open-source policy. Any citizen could challenge a law or decree as unconstitutional, and the challenge would be adjudicated in a public process. The mechanism created accountability for legislators: if a law you proposed was challenged and found unconstitutional, you could be penalized. This created strong incentives to draft carefully and to accept legitimate challenges rather than resist them through power.

The English common law tradition developed a different but related mechanism: any subject could bring a case that created precedent, and precedent constrained future legal decisions. The law evolved through a distributed process of challenge, interpretation, and reinterpretation — not through centralized revision cycles. This is why common law systems are often described as "judge-made law": the rules emerge from the accumulated judgments of people applying rules to specific cases, each case being a kind of pull request that tests the rule against reality.

Contemporary examples are closer to the software model. The city of Helsinki's participatory platform, introduced in 2012, allows any resident to submit a petition that, if it reaches a threshold of signatures, the city council is obligated to address. The response must be substantive — not a form letter — and must be published. Taiwan's vTaiwan platform, developed in 2015, creates structured digital deliberation processes in which citizens contribute to proposed regulations, and the government commits to implementing consensus positions. Both platforms have produced genuine policy revisions that originated from outside the governing body.

Open-source policy processes confront a specific legitimacy challenge: who decides what counts as a good proposal? In software, maintainers have technical authority — they can evaluate whether a contribution is correct, well-implemented, and consistent with the project's architecture. In governance, authority is more contested. The governing body has legal authority, but expertise is distributed, and the governing body's perspective is inevitably partial.

The resolution is to be explicit about decision criteria in advance. An open-source policy process should publish, and maintain, the principles that govern proposal evaluation: What values does the community hold? What constraints are non-negotiable (legal requirements, resource limits, prior commitments)? What tradeoffs is the community willing to make? When proposals are evaluated against explicit published criteria, declines are less likely to feel arbitrary, and proposers have a map for improving their proposals.

This process of articulating decision criteria has a secondary benefit: it forces the governing body to be explicit about its own principles, which are usually implicit and contested. The act of publishing "we will evaluate proposals based on these five criteria" requires the governing body to agree on those criteria, which often reveals disagreements that were previously unexamined. Surfacing those disagreements is itself valuable governance work.

Any open contribution process can be captured by organized interest groups. If a housing developer submits fifty carefully crafted policy proposals, and unorganized residents submit none because they do not know the process exists, the open-source policy process has become a tool for institutional capture rather than democratic revision.

The counter-measures are design choices, not accidents. Broad outreach about the process's existence, translated into all languages used in the community, is necessary. Simplified proposal formats that do not require legal or technical expertise are necessary. Proactive engagement with historically underrepresented community members is necessary. Limits on the volume of proposals any single entity can submit in a given period may be warranted. And the governing body's published evaluation criteria should explicitly include distributional considerations: does this proposal benefit the broader community or a narrow interest group?

These counter-measures require ongoing attention. The tendency over time is for any structured process to be learned and exploited by the people with the most resources to devote to it. Periodic review of who is actually using the process, and adjustment of outreach and design to correct imbalances, is itself a form of open-source policy practice: the process is code, and it also needs pull requests.

Open-source policy is the structural operationalization of Law 5 at community scale. It does not treat revision as exceptional — it institutionalizes revision as the normal operating mode of governance. Rules are not written once and enforced until crisis demands change. They are written, published, monitored, and continuously revised through a distributed process of contribution and response.

This operationalization addresses the most common failure mode of Law 5 at community scale: the governing body that acknowledges the need for revision in principle but has no mechanism for it in practice. Acknowledging that rules should be revisable is not the same as having a process by which they get revised. Open-source policy provides the process. The commitment to the process is what distinguishes communities that actually revise from communities that talk about revising.

The political theory underlying this approach is pluralist and empiricist: no governing body has complete knowledge, all rules have bugs, and the people best positioned to find the bugs are the people who live under the rules. This is not a radical proposition. It is the most pragmatic available account of how rules improve. Open-source policy is the structural commitment to acting on that account.