Inside the research: How GitHub Copilot impacts the nature of work for open source maintainers

Maintainers, AI Assistants, and the Changing Shape of Open Source Work

As code-generating AI tools become a routine part of many developers' workflows, a new research paper examines a group that often gets overlooked in the conversation: the maintainers of open source projects. Rather than focusing on how individual programmers write code faster, the study looks at the upstream effects and how the nature of the work itself shifts when maintainers adopt GitHub Copilot.

The paper, recently released, is the result of collaboration involving two researchers at Harvard. Manuel Hoffmann is a postdoctoral scholar at the Laboratory for Innovation Science at Harvard, housed within the Digital, Data, and Design Institute at Harvard Business School; he is also affiliated with Stanford University. His research centers on the social and behavioral aspects of open source software and artificial intelligence under the broader umbrella of innovation and technology management. Sam Boysel is a postdoctoral fellow at the same lab. An applied microeconomist, Boysel's work concentrates on digital economics, labor and productivity, and socio-technical networks, often examining the private provision of public goods and productivity in open collaboration environments.

The research starts from a straightforward set of questions: Once a maintainer starts relying on Copilot, does the focus of the work move? Does the maintainer spend more time on reviewing commits than writing them? Do projects see a shift in the rhythm of releases or the nature of community interaction?

What Adopting Copilot Really Changes

One of the central findings is the reallocation of maintainer attention. With AI handling much of the boilerplate and routine code writing, the work that remains involves different tasks—or at least, a different mix of them.

The balance tips toward more time dedicated to higher-level judgment, such as reviewing contributions, and Copilot's outputs, for quality and security.

Because Copilot produces code that needs verification, there is a rising emphasis on the parts of the job that are hardest to automate. This points to a potential shift in the skills that matter the most for maintainership positions.

Impact on Project and Community Structure

The study suggests the effects extend further than the maintainer using the tool. When the lead maintainers' workload changes, the entire architecture of a project's social dynamics can adjust. This area is where the paper looks to uncover the strategic aspects that play out in real-world development environments.

The authors leverage the open nature of software development to measure changes in concrete terms—using data on commits, PRs, issue response times, and review cycles. The researchers say these community-level metrics have implications for large, medium-sized, and entrepreneurial firms alike, since open source underpins so much of the economy's software infrastructure.

When maintainers have to spend a larger portion of their already limited time on tasks like code review rather than production, this can alter how new feature requests are prioritized, and how quickly external contributors see their contributions merged. This dynamic changes whether the software ecosystem expands or stabilizes in a given period.

The Cost of Free Labor

Many of the challenges this research highlights resonate with broader, long-standing questions about open source work. Even before any AI tool arrives, maintainers routinely perform a lot of labor that often does not benefit them directly. Their time is spent on code maintenance, security patch reviews when a critical exploit comes to light, and acting as gatekeepers for others' work. Without this effort, collaborative projects do not retain their value; with it, maintainers give up time for other things.

Maintainer reactions to Copilot access

The research team behind this study analyzed GitHub activity data to understand how giving maintainers free access to GitHub Copilot changes what they actually do on the platform. The core finding: developers who get the AI coding assistant shift their effort toward writing code and away from project management work.

That effect is strongest in the first year after Copilot access begins, but it persists even two years later, according to the authors. Perhaps more notably, the shift is driven mainly by developers who work more autonomously. Rather than needing to coordinate with other humans to solve problems, they can turn to the AI assistant directly, which reduces the collaborative friction that often slows open source work.

Exploration over exploitation

Beyond the basic coding-versus-management tradeoff, the paper digs into how Copilot affects the balance between exploration and exploitation. In this framing, exploitation means putting effort into known, high-value options, while exploration means experimenting with new options that might yield larger returns.

The data shows that developers with Copilot access lean toward exploration. They are more likely to start new projects and less likely to keep working on older ones. They also branch out into programming languages they had not previously used—particularly languages that command higher salaries in the labor market. A back-of-the-envelope calculation suggests that the value of this purely experimental language switching alone amounts to around half a billion US dollars within a year.

How the causal analysis works

A naive comparison of Copilot users versus non-users would only reveal correlations. For example, if Copilot users push more code, there are at least three explanations: Copilot causes more pushes, more pushing causes Copilot adoption, or some third factor like professional status drives both. To isolate causation, the researchers used a regression discontinuity design (RDD), a method that approximates a randomized controlled trial (RCT) with observational data.

An RCT would randomly assign developers to either use Copilot or not, but running one at scale is expensive and impractical over long time horizons. Instead, the team exploited what they describe as natural randomness already present in GitHub’s system: an internal ranking of maintainers determines who gets free Copilot access through a top maintainer program. Developers do not know the ranking or the cutoff, so eligibility is effectively arbitrary at the margin.

Consider a simplified version: if one million repositories are ranked and the top 500,000 get free access, comparing the #1 repository to the #1,000,000th would be meaningless because they differ in countless ways besides Copilot access. However, the #499,999th and the #500,001st repositories are likely to be nearly identical except for whether they cleared the threshold. Any outcome differences between narrow bands of repositories just above and below the cutoff can therefore be attributed to Copilot access itself.

Known gaps and limitations

The authors acknowledge that no study of this kind is complete. One limitation is that their analysis relies on public repository data. If they had visibility into private repositories, they could test whether the experimentation seen in public projects also happens privately, and whether AI-assisted improvements made in private eventually spill over into public codebases.

Another limitation concerns how they estimate the dollar value of Copilot. The language-switching calculation above assumes a partial equilibrium: it extrapolates across all top developers without accounting for the possibility that wages for those languages might fall if more developers enter those fields. That said, the authors suspect the estimate is more likely understated than overstated, since it excludes non-language-specific exploration and any value derived from non-experimental uses of the tool.

Looking ahead

On future directions, the authors reason that AI tools will tend to incentivize whatever activities they make cheaper, but it is not yet clear how that will play out across many possible applications. They anticipate a proliferation of AI tools that reward different activities, prompting individuals, firms, and policymakers to make deliberate choices about which tasks deserve emphasis. There may also be entirely new recombinations of work that are hard to foresee today.

The researchers draw an analogy to the steam engine: factories were once organized around a single massive engine, but electric motors eliminated that constraint and enabled entirely new factory layouts, which drove significant productivity gains. AI may follow a similar pattern, with its largest impact arriving only after work processes are reorganized around it. They also note that developers have a rare opportunity to shape that future because they are the ones building machine learning systems in the first place.

The distributional consequences of generative AI remain uncertain, according to the authors. On one hand, substantial computing power needed to train large language models is concentrated among a few players, which could widen inequality. On the other hand, there is documented evidence that lower-ability individuals benefit most from generative AI in the short term. In this study, the effect is larger among developers who are relatively less skilled, contradicting fears that AI will simply replace entry-level work. Instead, the data suggests AI can lower the cost of experimentation, reduce barriers to entry, and potentially level the playing field in parts of the labor market. The authors recommend policymakers monitor these distributional effects closely, supporting cases where the technology naturally delivers broad benefits while intervening where it does not.

Maintainers in the Lab: What an Economist Sees in Copilot Data

Manuel Hoffmann and Sam Boysel are both economists who study open source software: Hoffmann is a researcher with affiliations including Harvard Business School and Stanford, while Boysel is a data-focused applied researcher. In conversation with Tech Report, they discussed how they wound up studying developer ecosystems, what a typical research day looks like, and how generative AI tools have changed their own coding workflows.

From Hobbyist to Researcher

Both researchers arrived at open source from a mixture of personal interest and formal training. Hoffmann describes himself as having been involved with open source before his academic career: he used Linux and Ubuntu, programmed as a hobby, and valued the freedom available on personal computers and the internet. His formal studies pulled him toward economics, particularly causal inference and welfare questions, where he learned to apply experimental and quasi-experimental methods to social, medical, and technological innovation. After a PhD focused on labor and health, he moved into health research at Stanford, then back into labor questions at Harvard Business School — with open source software as the research area that let him keep working on both.

Boysel was introduced to open source early, picking up a copy of OpenSUSE for Dummies in middle school. As an undergraduate, he was drawn to economics as a social science and its ability to explain human behavior across many settings. In graduate school, he decided to combine the discipline with his long-standing interest in computing. Open source, he notes, is an unusually data-rich environment for economic questions. His prior work includes studying peer effects in contribution decisions, modeling software dependency networks through strategic behavior and risk aversion, and exploring how labor market competition shapes output in open source projects.

The Research Workflow

Both researchers describe days that mix standalone work, collaboration, teaching, and public communication of results. Hoffmann says his research time is spent refining causal inference papers and speaking to audiences about them; that means juggling multiple projects at once, from earlier health-focused work to his current studies of generative AI and the nature of work. Boysel characterizes his job as using data to answer questions that come from current events, conversations with colleagues, or observations about the open source ecosystem. His data often comes from publicly observable behavior online: static code analysis and version control history to trace codebase evolution, job postings to measure demand for open source skills, and packaging ecosystem dependency graphs to track relationships between projects. From there, he applies economic theory and econometric methodology, then writes up results, presents them, and iterates on feedback.

Copilot in Practice

Hoffmann uses GitHub Copilot when building experiments and writing JavaScript, often alongside Daniel Stephenson from Virginia Commonwealth University. He finds it interesting how often Copilot produces correct, context-aware suggestions — but stresses that the big picture decisions still belong to the developer. In his experience, Copilot speeds up the process and helps avoid mistakes, as long as one does not blindly follow its suggestions.

Boysel has only recently adopted Copilot but reports a substantial impact on his workflow. Most social science researchers, he points out, are not professional software engineers, yet they still have to write code to meet deadlines. Before generative AI, the path from problem to solution was typically padded with search queries and time spent parsing Q&A forums and documentation. Being able to resolve uncertainty inside the IDE itself, he says, is a significant productivity gain.

Advice for Newcomers

Hoffmann offers three broad pieces of advice: find work or questions you genuinely care about, focus on what you can control rather than what you cannot, and seek advice from many different people before picking and choosing what fits. Boysel adds that the ability to communicate effectively across both software engineering and research communities is extremely important, that the best work tends to come from genuine passion, and that premature optimization really is the root of all evil.

Learning Resources

Both researchers were asked for resources they would recommend to someone wanting to dig deeper. Hoffmann broke his suggestions down by topic: Ethan Mollick’s social media posts for generative AI research, Microsoft Learn’s advanced GitHub Copilot training module for coding with the tool, Susan Athey’s lab materials for causal inference and machine learning, and NBER working papers for economics and business studies.

Boysel pointed to what he calls reasonably entry-level papers that helped shape his own approach: Lerner and Tirole’s “Some Simple Economics of Open Source,” Bessen and Maskin’s “Sequential Innovation, Patents, and Imitation,” and Athey and Ellison’s “Dynamics of Open Source Movements.” For the empirical toolkit, he recommended Scott Cunningham’s Causal Inference: The Mixtape. He also plugged a collaborative collection of data sources for open source researchers, hosted on GitHub and open to contributions.