Who's Writing Open Source Code?

richards1 pts0 comments

Who’s Writing Open Source Code? – tecosystems

You are using an outdated browser. Please upgrade your browser to improve your experience.

Skip to Content

As AI steadily reshapes the software industry around it as open source once did before it, it’s useful to try and understand where those two forces intersect. Open source has, as it has with virtually every other industry software category, had an enormous impact on AI. AI offerings are built on vast foundations of open source, and an emerging new set of highly capable models have been released in a manner reminiscent of open source, if not open source the way we’ve traditionally understood it. This has led to much recent vendor jockeying, from unusually coordinated defenses of open weight models to defensive critiques. But that’s a topic to be tabled for the moment, at least until some of the dust has settled.

Instead, as the impact of open source on AI makes headlines, it’s useful to examine the reverse: what is the impact of AI on open source? This is a common question in the industry, both for individual developers and maintainers, those responsible for project governance as well as vendors that sponsor open source work in some capacity. In the wake of examples like Bun, in which the project has transitioned from primarily being written by humans to one authored by machines, is that an outlier or the new norm? Put more simply: are open source projects more broadly still written by humans, or have the robots taken over?

Setting aside for the moment subjective feedback from project maintainers about the impact of AI, which in general is grim, what can we understand objectively and analytically about how AI is or isn’t contributing to open source code? To try and answer that, 15 projects were selected and analyzed to see what evidence they can provide for the growth or lackthereof of AI-authored code.

The Caveats

Sadly, the truth is that what we can say objectively, at any scale beyond a single project, is limited. We cannot, for example, account for code written by a machine but passed off by a human as their own work. Bot-delivered human code, likewise, can be difficult to identify and parse in some cases. Even bots themselves are limited to the hardcoded regexes that detect them. We cannot state with any degree of precision, then, what the exact percentage of code that was written by a human versus that of a machine.

We can, however, establish something of a floor from a contribution standpoint.

In simple terms, what can’t be stated is how much actual AI code is in these projects. What can be captured, however, is the number of commits that carry a machine-readable AI marker: a co-author trailer naming an AI tool, or authorship by an autonomous agent. Even those, however, could have plausibly different explanations.

New Instrumentation : it could simply be a function of the sudden rise of Claude Code appending "Co-authored-by: Claude" or Copilot’s agent mode doing the same thing.

New Tools : Copilot, for example, has been in market and assisting in development since 2021, but only in the last 18 months have agentic CLI tools really emerged as autonomous or semi-autonomous collaborators. In other words, growth is less a function of reporting and more a reflection of exploding usage of a new class of coding assistance tools.

In the end, however, both are likely to be true and there is no realistic way of apportioning them by way of this dataset. All that is available are coarse markers of overall usage. We can also, however, continue to take these coarse snapshops to monitor the slope of that minimum floor to see if usage is increasing, decreasing or remaining static.

The Study Cohort

To begin with, of course, a sample is needed. To determine project size, this analysis relies on the size of the contributor base. It’s an imperfect metric for that purpose, of course, but they all are. Next, we looked at criticality – i.e. how important or used a given project was – as measured by a variety of metrics. For medium and large projects, it was measured via deps.dev dependencies, with a fallback to GitHub mentions. Small projects, for their part, were less amenable to this approach and were instead measured via Debian Popcon popularity. Ultimately, while the sample wanted to reflect projects of differing sizes, the intent was to examine projects that were being used and relied upon.

To add one further linking thread, or remove one potential confounding variable, this analysis prioritized having projects written in a common language in all three cohorts. Given that a number of the most critical small projects were written in C, that was prioritized and that’s a bias worth being aware of here. Future runs will prioritize other more modern languages to assess whether there are language distinctions in AI uptake.

The only other thing to note here is that the data used in this analysis was obtained via the GitHub API rather than the GitHub Archive...

open source code projects project written

Related Articles