Coding Alone

It’s been over 30 years since Robert Putnam wrote about the American phenomenon of “bowling alone”. This analyses shows how the same thing is now happening to coding. Over the last few years, the world has rapidly moved from open-source software being produced and maintained by online communities, to software projects being built and maintained in isolation. By single developers, with ever-decreasing input from others. AI coding tools are now dramatically accelerating movement away from code as a collective endeavour to “coding alone”. I conclude by describing how such progression need not be considered inevitable. Every step has reflected the collective influence of countless individual human decisions. We can still decide to help re-activate open-source software communities, including through using AI coding tools in ways that help retain community.

In 1995, Robert Putnam noticed that more Americans were bowling than ever before, but the growth was in solo or casual bowling at the expense of organised, collective bowling. He argued that this was reflective of a broader collapse of associational habits which used to knit Americans into overlapping social groups. Local clubs, unions, congregations, and leagues had been quietly hollowing out for a generation, not because people had lost interest in the underlying activities, but because they’d stopped doing them together.

Open-source software has its own version of a league: public repositories, with a few core maintainers and shifting casts of outsiders who ask questions, report bugs, or leave comments. These communities of contributors guide and nurture ongoing software development. People still write code, but this analysis shows that the collective structures that have supported and sustained that writing are changing dramatically. Public software repositories are changing from places of social coherence and cohesion to become more like mere mirrors of a single person’s work.

Why does this matter?

Maybe software coded by increasingly isolated individuals will be just a good as previous software coded by larger communities building on one another’s ideas? Maybe a bunch of individuals with large enough budgets for billions on AI tokens will be able to usher in a new golden age of genius software? It’s obviously helpful at the outset to try to figure out whether that’s likely to happen or not.

The first problem in doing that is that good software is not easy to define. But at least for open-source software, popularity can generally be presumed to reflect quality. Popular open-source software can generally be presumed to be good (even though lots of really good software may go unnoticed). And popularity can be measured, generally by numbers of downloads, as well as by metrics like numbers of times people have “starred” software repositories on GitHub.

All of the following analyses use random selections of repositories from several common software distribution systems, including npm for Javascript, PyPI for Python, CRAN for R, and two GitHub-based software review organizations, JOSS (the Journal of Open-Source Software), and rOpenSci. Data extracted for each of these can show whether larger communities help produce better software, as measured through popularity.

Relationships between community size and popularity are of course complicated by the fact that both tend to change and interact over time (ideally through growing together). Such mutual interactions can easily be statistically accounted for, to estimate the effects of community size on repository popularity independent of any influence of repository age on either of those measures. And doing that reveals the relationships shown in the following figure:

Good software - as measured by popularity - is overwhelmingly produced by larger communities. This relationship is of course purely correlative, and can say nothing about whether larger communities actually cause software quality to increase. But it is nevertheless sufficient to clearly show why this matters: Software produced by smaller communities tends to be significantly less popular. This suggests that any decreases in the sizes of communities producing software will likely be associated with decreases in software popularity, and quite likely decreases in software quality.

To answer the question this section posed: These analyses matter because good software emerges from large communities, and anything that works to reduce community size will also work to reduce software quality. The rest of this analyses provides various insights in to what appears to be a comprehensive collapse of open-source communities.

What was measured

All data are taken from GitHub, primarily as measures of interaction with software repositories through “issues”. Issues are the place for anybody to ask questions of software authors, to report bugs, or to request new features. A corpus of repositories was taken from the five sources described above.

Analyses included every repository reviewed by JOSS and rOpenSci, every package currently on CRAN, and samples from the other three. Samples were stratified by popularity to ensure even sampling and representation regardless of popularity. In total, 3,139,779 issues were analysed across 52,461 repositories.

More popular or prominent repositories attract greater interaction, resulting in issues being opened more frequently, and from a wider community. To account for the effects of repository popularity, most of the results are represented for four popularity strata, taken as quartiles on a logarithmic popularity scale. The lowest quartile, denoted “Q1”, represents the least popular repositories. The “Q4” repositories are the outlying superstar repositories with enormous numbers of downloads and hundreds of people opening issues.

Main Findings

Finding #1: People are coding less

Although the main focus here is on the demise of open-source communities, all data also reveal a pervasive decline in coding activity in general. The most direct measures of coding activity are the creation of new repositories, and numbers of commits in each. Time series of these two statistics show trends common to most results that follow, with variable development up until 2020-2021, followed by more progressive declines.

Finding #2: There Are Fewer Contributors

There are several ways to measures numbers of contributors to open-source software. Source code itself provides one of the most direct measures, generally through tracking who made each change. Code-hosting platforms provide a different approach, through data on repository issues. Anybody (with an account) can open an issue to ask a simple question. Many who do may not necessarily end up directly contributing to code at all, while almost all non-core developers who do contribute code start their first interactions via issues. Data on issues therefore offers more inclusive insights into open-source communities than data on direct code contributors.

Total numbers of comments on each issue show a similar pattern, with similarly reversed trends for PyPI as well as npm. Taken together, these figures reveal both numbers of issue authors and numbers of comments per issue have declined severely in all software systems over the past few years.

Finding #3: New Authors Are Not Arriving

The rates at which new authors of GitHub issues appear have also progressively decreased across all software systems. In 18 of those 20 combinations of software source-by-popularity stratum, the new-arrival rate has fallen by more than overall author density has, meaning the decline documented above isn’t simply existing regulars posting a little less often; it’s disproportionately a shrinking supply of people showing up for the first time at all.

Finding #4: Spiralling Towards Solitude

For each person contributing to a repository, GitHub also provides a measure of their relative overall contribution, measured as numbers of commits to source code. These relative contribution values were used to arbitrarily distinguish core contributors to a repository as those contributing a cumulative total of 99% of all commits. Non-core contributors were then identified as those contributing less than 1% of the cumulative total.

The combined effect of these decreases must of course be a progression towards increasing numbers of repositories being maintained by one person only. Taken collectively, 27% of repositories were effectively maintained by a single person in January 2021. By October 2026, that share had risen to 44%.

What does this mean?

Many aspects of these analyses align with what other people have reported about the people who keep open source software alive. A 2024 survey of open-source maintainers found that 61% of them maintain their project entirely alone, and that unpaid maintainers were disproportionately likely to be working alone. A 2024 survey of maintainers by Tidelift found that 60% remain entirely unpaid and nearly 60% have quit, or seriously considered quitting, projects they maintain, citing reasons such as competing life demands, loss of interest, or burnout.

What about AI?

The declines observed here began several years before the advent of AI as we now know it. AI has almost certainly contributed, including through mechanisms such as “algorithmic monoculture” discouraging diverse inputs into software. AI is very likely to have had an influence in all of these accelerated rates of decline, although after and on top of more general and broader factors.

Doing before asking

Most human societies cultivate habits of asking before doing. Unsolicited pull requests reverse this custom. They represent a comparably more aggressive step of doing before asking. While causes for such cultural changes are likely complex, increased social isolation does seem to foster increased aggression. Although coding alone is likely to increase ratios of pull requests to issues, the increases more likely reveal an additionally negative influence of AI coding tools.

Perhaps all of the declines observed here reflect increases in the kinds of behaviour described by Suler more than 20 years ago. The easier it got to do everything online, including coding, the more the behaviours of those doing the coding become disinhibited from their pro-social, in-person behaviour. AI is just the culmination of that process.

What can we do about this?

First and foremost, everything here shows an immediate need to do anything and everything to cultivate, nurture, and maintain communities. Always seek to collaborate rather than doing things yourself. Even if you don’t know anybody to collaborate with, inviting collaboration on your open-source repositories can have a big effect.

Perhaps most importantly if you use AI coding assistants, ensure you use them in socially aware ways. These machines are trained to implement their own work-arounds to any software issues they encounter. And they often do so silently. Start with clear instructions in an AGENTS.md file or similar NOT to do that silently, rather to tell you about it. It really is quite easy to use AI coding tools in ways that help you as a human being connect with the human developers of other software. At the very least, never let an AI coding tool open an unsolicited pull request on any repository you do not know well. That is doing without asking, which is rude. Always ask first, and do so with your own, human words. Help to re-establish open-source communities as genuinely collaborative spaces.