Abstract
The rules governing those who build the software the world depends on are not clearly written in plain text. They live in configuration files and repository settings that many contributors never bother to check. My capstone project examines how GitHub's workflow configurations, including branch protection rules, reviewer requirements, and CODEOWNERS files, function as governance mechanisms in open-source communities. These settings determine who can contribute meaningfully and yet are almost never treated as the governance identities they are. My STS paper investigates how those same configurations distribute power and shape participation, drawing on scholarship by Eghbal, O'Mahony and Ferraro, and Nyman and Lindman, and motivated by the fact that open-source software is critical infrastructure whose governance deserves public analysis.
The capstone audits approximately fifteen GitHub repositories across three case study pairs, Elasticsearch and OpenSearch, Terraform and OpenTofu, and Redis and Valkey. The quantitative component uses the GitHub API to document branch protection rules, reviewer counts, CI requirements, and CODEOWNERS structures, measuring contributor activity within six-month windows before and after each governance event. A qualitative component analyzes CONTRIBUTING files, codes of conduct, and community discussion threads to provide context for the numbers.
Across all three cases, the original projects concentrated merge access and review authority among corporate employees, leaving outside contributors with little real influence. When those projects changed their licenses, the resulting forks redistributed those permissions and broadened maintainer eligibility to a wider pool of contributors. Even so, none of the forks achieved full decentralization; each one still stabilized around a foundation or a dominant company in the coordinating role. The conclusion is that the decision to fork a project is as much a governance restructuring as it is a technical one.
The STS paper asks how GitHub's workflow configurations distribute power in open-source communities, a question significant because this governance is invisible to most participants. The paper applies frameworks from Eghbal (2020), O'Mahony and Ferraro (2007), and Nyman and Lindman (2013) to the same three case studies through close reading of community documents and public discussions.
The presented evidence shows that configurations systematically favored corporate insiders in original projects. Elasticsearch routed approvals exclusively through Elastic employees, OpenSearch responded with public MAINTAINERS.md files and an RFC process, and HashiCorp's opaque review queues provoked the OpenTofu fork, which spread authority across multiple organizations. Valkey then quickly attracted contributors from Google, Oracle, and Ericsson, suggesting Redis's tight configurations had suppressed latent participation. The paper concludes that open-source governance cannot be fully understood through formal policy alone, and that transparent workflow configurations are a clear step toward the democratic norms that software communities value.
