💬 NLP

Patterns in the Transition From Founder-Leadership to Community Governance of Open Source

By analyzing 637 GitHub repositories and their evolving governance documents, this study reveals that successful transitions from founder-led to community governance occur not through tonal shifts but through the gradual layering and refinement of institutional roles and ecosystem-level regulations.

Original authors: Mobina Noori, Mahasweta Chakraborti, Amy X Zhang, Seth Frey

Published 2026-02-06

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Mobina Noori, Mahasweta Chakraborti, Amy X Zhang, Seth Frey

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

The Big Picture: From "One Boss" to "A Team"

Imagine a popular open-source software project (like a free app or website) as a giant, shared community garden.

At the very beginning, almost every garden is started by a single person—the Founder. This person plants the first seeds, builds the fence, and decides where the tomatoes go. In the beginning, this works great. The founder is the "benevolent dictator," and everyone just follows their lead.

But as the garden grows, it attracts hundreds of other gardeners. The founder can't possibly water every plant, prune every bush, or decide every rule alone. If they try, the garden might collapse, or the founder might burn out. The garden needs to turn into a community-run organization where everyone has a say and clear rules.

This paper is a study of how 637 of these digital gardens made that transition. The researchers wanted to see: How do projects change their rulebooks when they go from "One Boss" to "Community Governance"?

How They Did It: Reading the "Rulebooks"

Instead of watching people argue in chat rooms or counting how many code changes were made, the researchers looked at the written rulebooks.

On GitHub (the website where these projects live), there is a special file called GOVERNANCE.md. Think of this as the Constitution of the project. It's a plain text file that sits right next to the computer code. It says things like:

"Who can merge code?"
"How do we pick a new leader?"
"What happens if someone breaks the rules?"

The researchers collected the first version of this rulebook (when the project was young) and the latest version (when the project was mature) for 637 projects. They used a computer program to read these documents and break them down into three simple parts:

Roles (The "Who"): Who is allowed to do things? (e.g., "Contributors," "Maintainers," "The Steering Committee").
Actions (The "What"): What activities are being regulated? (e.g., "Voting," "Reviewing code," "Deciding on features").
Deontics (The "How Strong"): How strict are the rules? (e.g., "You must do this," "You should do this," or "You can do this").

What They Found: The Garden Gets More Complex

The researchers found that as these projects mature, their rulebooks don't just get longer; they get smarter and more balanced. Here are the key patterns they discovered:

1. More Specialized Jobs (The "Roles" Grow)

In the beginning, the rulebook was very simple. It mostly said, "Anyone can help" or "The Founder decides."

The Change: As the project grew, the rulebooks started defining specific, specialized jobs. They added rules for "Technical Committees," "Oversight Groups," "Sub-committees," and people who manage relationships with other projects.
The Analogy: Imagine a small family dinner where the mom decides everything. As the family grows into a huge wedding reception, you don't just have "Mom" anymore. You get a "Head Waiter," a "DJ," a "Florist," and a "Security Guard." The rulebook started listing all these specific roles.

2. More Types of Activities (The "Actions" Grow)

Early rulebooks focused on basic actions like "submitting code."

The Change: Later rulebooks covered a wider variety of activities. They started regulating how the project talks to the outside world, how they hold meetings, and how they handle oversight.
The Analogy: A small club just has rules for "signing up." A big club has rules for "fundraising," "hosting events," "managing the budget," and "mediating disputes." The scope of what is being managed got much wider.

3. The Rules Became More Balanced (The "Entropy" Increased)

This is a fancy way of saying the rules stopped being focused on just one or two things and started spreading out evenly.

The Change: In the early days, 90% of the rules might have been about the "Founder." In the later days, the rules were spread out more evenly across all the different roles and actions. No single person or group dominated the text anymore.
The Analogy: Think of a spotlight. At first, the spotlight is stuck on one person (the Founder). Over time, the spotlight moves around, lighting up different people and tasks equally. The "light" of responsibility is shared.

4. The Rules Stayed "Nice" (The "Deontics" Didn't Change Much)

The researchers checked if the rules became stricter or more punishing over time.

The Change: Surprisingly, they didn't. The ratio of "You must do this" vs. "You can do this" stayed roughly the same. Even though the projects got huge and complex, they didn't turn into strict police states. They remained mostly about permission and encouragement rather than prohibition.
The Analogy: Even as the garden got bigger, the signs didn't change from "Please help out" to "Do not touch the plants or you will be arrested." The tone remained friendly and volunteer-based.

The Main Takeaway

The paper concludes that successful open-source projects don't usually rip up their old rulebooks and start over. Instead, they layer on new rules.

They start with a simple foundation (the Founder's vision) and slowly add more layers of detail, specialized roles, and shared responsibilities as the project grows. It's like building a house: you start with the foundation and walls, and over time, you add rooms, a second floor, and a fancy kitchen. You don't tear down the first floor to build the second; you just keep adding to it.

In short: Successful communities grow by adding more specific jobs and spreading out the responsibility, rather than by changing the tone of the rules or replacing the old system entirely.

Technical Summary: Patterns in the Transition From Founder-Leadership to Community Governance of Open Source

Problem Statement

Open source software (OSS) underpins critical global digital infrastructure, yet the majority of projects operate under a "founder-led, single-leader governance model." This default regime often lacks formal accountability to the community or society. While many projects eventually transition to community governance to ensure sustainability and robustness, the determinants of successful transitions remain unclear. Existing research relies heavily on indirect behavioral signals (e.g., commits, mailing lists) or cross-sectional case studies, lacking a systematic, longitudinal account of how governance is explicitly articulated and evolves in formal textual artifacts. Furthermore, the transition process is often ad-hoc, relying on "hacks" of existing tools rather than dedicated, theoretically-grounded mechanisms.

Methodology

The authors address this gap by analyzing 637 GitHub repositories to trace the evolution of governance from founder-ownership to shared governance. The study utilizes a scalable, NLP-driven pipeline to analyze GOVERNANCE.md files, which serve as version-controlled project constitutions.

Data Collection and Preprocessing

Corpus: The study analyzes 637 repositories with at least two recoverable governance snapshots (an "initial" and a "latest" version) spanning 2013–2022.
Normalization: Governance documents are preprocessed to remove markdown artifacts, normalize headings, and convert tables to lists. Coreference resolution is applied to reduce pronoun ambiguity.
Pairing: The dataset pairs the earliest valid governance snapshot with the most recent for each repository, focusing on "across-day" changes to capture institutional evolution.

Institutional Parsing Pipeline

The core methodological contribution is the extraction of institutional components using the Institutional Grammar (IG) framework, adapted for NLP:

Semantic Role Labeling (SRL): Sentences are mapped to predicate-argument structures to identify the underlying grammar of governance actions.
Component Extraction: The pipeline extracts three core components from the text:
- Roles (Attribute): The agents or positions recognized (e.g., "maintainer," "technical committee").
- Actions (Aim): The activities requiring governance (e.g., "commit," "review," "decide").
- Deontics: The prescriptive force of the statement (e.g., "must," "should," "may").
Clustering: Extracted tuples are encoded using Sentence-BERT and clustered via BERTopic to identify semantic governance patterns across repositories.

Measurement Framework

To quantify institutional development, the authors employ two primary metrics:

Count ( $K$ ): The number of distinct governance categories (roles, actions, deontics) present in a snapshot.
Entropy ( $H$ ): Normalized Shannon entropy measuring the evenness of the distribution of governance categories. Higher entropy indicates a more balanced allocation of attention across different roles and actions, while lower entropy signals concentration.
Jensen-Shannon Divergence (JSD): Used to measure the semantic drift between initial and latest distributions.

Statistical significance is determined via equal-weight bootstrap confidence intervals ( $B=10,000$ ) across repositories, with "rarefied" estimates used to control for document length differences between initial and final versions.

Key Results

The analysis reveals that OSS governance evolves through accretion and differentiation rather than simple replacement or tonal shifts.

Expansion of Scope ( $K$ ): Over time, projects define a significantly wider array of roles and actions.
- Roles: The average number of distinct role categories increased from 3.46 to 3.95.
- Actions: The average number of distinct action categories increased from 3.86 to 4.46.
- Deontics: The count of deontic types remained statistically stable, indicating that the types of obligations do not proliferate, even as the scope does.
Balancing of Attention ( $H$ ): Governance attention becomes more evenly distributed across specialized categories.
- Roles and Actions: Both show positive changes in entropy ( $\Delta H$ ), indicating a shift away from broad, generic categories (e.g., "all_project") toward specialized roles (e.g., "technical committee," "oversight," "ecosystem").
- Deontics: While the balance of modal verbs (may/should/must) remains stable, there is a significant concentration of enabling verbs ("can") over restricting verbs ("cannot"), with enabling language comprising over 97% of references.
Specific Shifts in Focus:
- Oversight and Ecosystem: There is a marked increase in regulations defining oversight roles and interfacing with the broader ecosystem (dependencies, external entities).
- Leadership Stability: The role of "project_lead" does not disappear; rather, leadership roles coexist with broader participation. The transition is not about dismantling leadership but distributing responsibility.
- Action Distribution: While the proportion of action categories (e.g., "choice," "authority") remains relatively stable, the total volume of governance text increases, suggesting that governance acts as scaffolding for collective work rather than a mechanism for strict control.

Significance and Contributions

The paper offers four primary contributions to the fields of Human-Computer Interaction (HCI), collaborative computing, and open source studies:

Longitudinal Dataset: A curated dataset of 637 paired initial and latest GOVERNANCE.md snapshots, enabling the first large-scale, longitudinal study of explicit governance articulation.
Scalable NLP Pipeline: A reproducible pipeline for extracting institutional components (Roles, Actions, Deontics) from governance text, allowing for the analysis of hundreds of projects simultaneously.
Quantitative Framework: A measurement framework using Entropy ( $H$ ) and Count ( $K$ ) to quantify governance maturation, demonstrating that successful transitions involve layering and refining responsibilities rather than shifting tone.
Empirical Findings on Maturation: The study empirically demonstrates that OSS governance diversifies and rebalances as projects mature. It challenges the notion that community governance requires a radical shift in power dynamics, showing instead that it evolves through the layering of specialized roles and the formalization of ecosystem relationships.

The authors conclude that governance in OSS functions less as a static rulebook and more as a dynamic coordination mechanism. The findings suggest that interventions to support community governance should focus on lowering the cost of adding clarifying roles and committees, rather than requiring disruptive constitutional rewrites. This work provides a foundation for developing tools that help communities transition from founder-ownership to accountable, shared governance.