How researchers are using GitHub Innovation Graph data to reveal the “digital complexity” of nations

Measuring what trade data can’t see: software complexity on GitHub

Four researchers from Corvinus University of Budapest, Maastricht University, and the Toulouse School of Economics recently published a paper in Research Policy that applies the Economic Complexity Index (ECI)—a metric traditionally built on physical exports—to software development activity on GitHub. Using data from the GitHub Innovation Graph, they argue that the geography of open-source code production reveals a nation’s “digital complexity” that conventional economic indicators miss.

For years, economists have measured national economic complexity through what countries export, patent, and publish. These measures predict growth, inequality, and other macroeconomic trends. But they overlook a massive and growing part of the economy: software. As the researchers put it, code doesn’t pass through customs. It flows via git push, cloud services, and package managers—invisible to traditional trade statistics. The team sought to bring that “digital dark matter” into view.

Building software bundles

The core data comes from the GitHub Innovation Graph: quarterly counts of developers pushing code, broken down by economy and programming language for 163 economies and 150 languages from 2020 to 2023. But individual languages aren’t the right analytical unit. Real software projects use bundles of languages together—a web app pairs HTML, CSS, and JavaScript; a data science project leans on Python and Jupyter Notebook; systems work often combines C with Assembly.

To address this, the researchers built a custom dataset. They queried the GitHub GraphQL API for all active repositories in 2024 to see which languages co-occur within the same repos. They computed cosine similarity between languages using weighted co-occurrence, applying a normalization scheme so large polyglot repos wouldn’t dominate, then ran hierarchical clustering to group the 150 languages into 59 coherent “software bundles” representing technology stacks.

From there, they followed the standard ECI pipeline: build a country-by-bundle matrix, calculate revealed comparative advantage to see whether a country has a disproportionate share of developers in a bundle versus the global average, binarize that matrix, and apply an iterative method to produce complexity scores. Countries that dominate in many non-ubiquitous bundles score high; countries focused only on what everyone does score low. For relatedness, they measured proximity between bundles via co-specialization patterns, then tested whether countries are more likely to enter software areas close to their existing strengths. They found the “principle of relatedness” holds for software, just as it does for physical products.

The team’s headline result: the software ECI captures information that trade, patents, and research data leave out. It helps explain variations in GDP per capita and income inequality even after controlling for traditional measures.

Think of countries like kitchens. Some can cook anything—they have an abundance of ingredients and tools. Others can manage rice and a few simple dishes. We can’t see the kitchens directly, but the ECI lets us infer complexity from what they produce. A chicken-and-rice country might be a Python-and-JavaScript country; a Michelin-star country can program certified embedded systems for aerospace and defense.

Top 20 economies by software economic complexity

Data gaps and next steps

The work has clear limitations. Most notably, the analysis covers only public GitHub activity, ignoring proprietary corporate work. That means software complexity is likely underestimated in countries where closed-source development dominates and the open-source culture is weaker.

The time window is another constraint. Four years (2020–2023) is sufficient for cross-sectional analysis but too short to test long-term growth predictions—precisely what ECI was designed for. Economic structures shift over decades, not quarters. Twenty years of similar data would be needed for robust longitudinal findings.

The authors also want richer project-level information. Knowing a repo builds a fintech app rather than a game engine would enable far more granular capability bundles. GitHub Topics offers a partial view and served as a robustness check, but remains noisy and incomplete.

Policy and developer implications

Software is an unusual target for industrial policy. It depends on highly movable human capital, which means countries could in principle attract developers through talent programs. But that high mobility is double-edged: developers are sensitive to regulations that add friction to data work or shift innovation risk onto small and medium firms. Countries that attract software talent without smothering it under well-intentioned but burdensome rules will likely lead. Developers looking to relocate, conversely, can use the software product space to identify places where their skill set is a natural fit.

Looking forward, the researchers pose an open question about generative AI. If AI coding assistants lower the hurdle to learning new languages, does relatedness weaken, allowing faster diversification? Or does it reinforce existing advantages, since countries with the best AI infrastructure benefit most? Work is already underway, including a Science paper tracking the global diffusion of AI-assisted coding on GitHub.

Finally, the team predicts software-based ECI measures will become standard policy tools, complementary to trade data.

The data is open, it updates quarterly, and it captures something that traditional data genuinely can’t.

From Physics to GitHub: Unconventional Routes Into Open-Source Economics

The researchers behind the Innovation Graph study arrived via very different academic paths. Johannes grew up in mathematics before moving into computational social science during his PhD at Central European University in Budapest. He became interested in digital data traces as a way to study human behavior, and was drawn to network methods because they bridge the micro-level activity in those traces and macro outcomes. He stumbled into open-source research after realizing GitHub offered a rich, public record of valuable knowledge production that few social scientists were using.

Sándor's route was more traditional: a PhD in economic geography at Utrecht University, where the research community already applied economic complexity to regional development. He was trained to think about places through the lens of networks and capability accumulation. Jermain built technical skills through entrepreneurial projects during his PhD at RWTH Aachen, including work on Moviegalaxies.com and analyzing Kickstarter data. That led to multimodal machine learning and eventually passing networks for a German soccer team. These days his focus is causality and causal machine learning. César started in physics at Notre Dame, where he worked on complex networks and discovered those tools could describe economic evolution—an area that became known as economic complexity.

Day-to-day life in this niche mixes writing code, writing papers, and talking to people, with the usual teaching and administrative duties. Johannes values the freedom to shift focus when a project stops being interesting. Sándor points to the interdisciplinary community as a highlight: in a single week he might discuss the same research question with an economic geographer, a computer scientist, and a physicist.

Generative AI and Research Practice

Generative AI tools have become a regular part of their workflows. Johannes says LLM tools are used for debugging data pipelines, drafting boilerplate code, and sanity-checking statistical approaches. He finds them especially useful on a project with many different methods requiring team coordination — though they are much more helpful when you already know what you want to do.

Advice for Early-Career Researchers

When asked what they would tell a younger version of themselves, the researchers were candid. César's advice: invest in things that compound. He warns against spending months on projects simply because you don't want to lose work already put in, and cites tools like the Observatory of Economic Complexity and Data USA as examples that were difficult to build but have paid off for years. His test for a project is whether you honestly believe it will be more important in a decade than it is today.

Johannes suggests building a broad research question that motivates your work, and generating your own data. He prefers applying a straightforward method to a bespoke dataset over applying a complex method to a dataset everyone already knows. Jermain echoes César's warning: don't ride a dead horse. After a PhD, the temptation to keep milking old topics while pivoting to new ones leaves you straddling two worlds and mastering neither. His advice is to pick your focus deliberately and let go of past work that no longer aligns, even if it feels wasteful.

Sándor would tell his younger self to collaborate more and earlier. The four-author, five-institution, four-country paper behind this research wouldn't have happened if any of them had stayed in their silos. He recommends going to conferences outside your field, taking coffee meetings with people whose work seems tangential, and cold-emailing researchers whose work you admire.

Learning Resources

For those interested in exploring further, César recommends the Observatory of Economic Complexity for a web-based introduction, along with the book The Infinite Alphabet: and The Laws of Knowledge. Jermain suggests developers start by looking up their own country on the Observatory, seeing what it exports, where it sits in the product space, and then considering how software fits into that picture—a more intuitive way to build understanding before engaging with the mathematics.