GitHub, or the bureaucracy of the algorithm

GitHub is often presented as a mere developer tool. I think that misses what matters most. GitHub is first of all a form of organization, and one of the most fascinating of our time: an organization with no boss, no office, no national border, where millions of people who will never meet build together a considerable share of the software that runs the world.

I wanted to understand how such a thing holds together. And above all, what lies behind the appearance of seamlessness.

An organization with no center

GitHub matches, almost feature for feature, what organization theory calls the postmodern organization. Linda Rouleau (2007) describes this model as a break with the classic pyramid: a fluid, distributed structure with no fixed center of command, where coordination no longer flows down from a hierarchy but emerges from the interactions themselves. That is exactly what we observe here. No one "runs" an open source project the way a manager runs a team. Work organizes itself differently.

How? Through technique. On GitHub, it isn't bosses who allocate tasks and approve the work, it's protocols. The repository holds the project, each person proposes a copy of it, works on it, then submits their changes through a pull request. Before being integrated, that contribution goes through code review, where others examine it. The interface replaces the manager. The supervisory function, normally carried by a person, is here written into the tool.

This is what makes GitHub's second trait possible: radical openness.

The strength of openness

The open model rests on a simple, powerful wager: anyone can contribute, whatever their degree, their employer, or their geography. Hila Lifshitz-Assaf (2018), in a remarkable study conducted at NASA, calls this mechanism the dismantling of knowledge boundaries. Where a classic organization reserves problem-solving for its internal experts, the open model erases the boundary between expert and amateur, between inside and outside.

Her study offers a striking example. A problem of solar-storm forecasting, on which NASA's specialists had been stuck for years, was finally solved by a semi-retired radio engineer, a stranger to the discipline, whose approach came precisely from elsewhere. The solution didn't come from the center, but from the margin. That is the whole promise of openness: by abolishing boundaries, you let in ideas the closed organization would never have produced.

GitHub operates on this principle on a planetary scale. And it works: a major share of the world's digital infrastructure rests today on open source projects maintained this way.

But this is where things get interesting. Because here, the strength and the flaw are one and the same.

The flaw in openness: the XZ affair

In 2024, the cybersecurity community uncovered one of the most sophisticated sabotage attempts in the history of free software. A backdoor had been inserted into XZ Utils, a discreet compression library that is nonetheless present in countless Linux systems, reaching as far as OpenSSH, one of the most sensitive tools there is. Tracked as CVE-2024-3094, this flaw could have given its author hidden access to millions of machines.

What strikes me in this affair isn't the technical feat. It's the method. The attacker, known by the pseudonym Jia Tan, didn't force the door. He walked through it after being invited inside.

For nearly two years, this contributor proved available, competent, consistent. He offered useful fixes, took part in discussions, gradually earned the trust of the project's maintainer. At the same time, accomplice accounts pressured that maintainer, already exhausted and alone in carrying a colossal load, to delegate more responsibility. The maneuver worked: Jia Tan obtained maintainer rights, and was able to plant his malicious code there. The flaw was spotted only by chance, when an engineer noticed that an SSH connection was taking a fraction of a second too long to run.

When trust becomes the angle of attack

Why is this story so instructive? Because it shows that the vulnerability of the open organization isn't technical. It's relational.

Beth Schinoff and her colleagues (2020) studied how relationships of trust form in virtual work, where colleagues never see each other physically. Their central concept is that of relational cadence: trust is built less through meeting than through the predictable regularity of interactions, through that shared rhythm that makes us end up anticipating how the other will behave. At a distance, you don't trust a face. You trust a regularity.

That is exactly what Jia Tan manufactured. He didn't hack a system, he built a cadence. Two years of regular, reliable contributions produced the appearance of reliability itself. The mechanism that allows the open organization to function, the trust granted to a stranger on the sole basis of their behavior over time, is precisely the one that was turned against it.

Lifshitz-Assaf, in her NASA study, describes a troubling phenomenon she names simulated adoption: some professionals pretended to embrace the open model, participated in appearance, but in reality protected their boundaries and never integrated what came from outside. The appearance of participation masked its opposite. The Jia Tan affair is its mirror image. Where the NASA professional simulated openness while staying closed, Jia Tan simulated belonging and loyalty while preparing a betrayal. In both cases, what is shown is not what is at play. And in a system that has, by construction, no way to verify intentions, appearance is all that remains.

The bureaucracy of the algorithm

How, then, can an organization with no boss defend itself? The answer, too, is written into the tool.

Faced with pressure and dubious contributions, it isn't bosses' decisions that stand in the way, but rules: mandatory code review, validation protocols, the automated checks that verify every change. This is what I would call a bureaucracy of the algorithm. The word bureaucracy isn't pejorative here. It designates, as it does for organization theorists, a mode of control that works through impersonal rules rather than through the authority of a person. On GitHub, that control has simply shifted: from the human hierarchy to the technical protocol.

But we must resist the idea that these protocols are neutral. Paul Leonardi and Stephen Barley (2010) showed precisely that the materiality of technique is never a neutral detail: the constraints and possibilities a tool offers shape action and inscribe relations of power within it. Deciding who can approve a pull request, which checks are automatic, at what point a maintainer can delegate their rights, these aren't trivial technical choices. They are organizational decisions, and therefore decisions of power, simply translated into code. The XZ affair isn't the story of a technology that failed. It's the story of an organization whose rules of trust and delegation contained a blind spot.

What I take from it

GitHub interests me because it makes visible a tension that every virtual, open organization will have to confront: you cannot have openness without the vulnerability that comes with it. They are two sides of the same coin. Lowering the boundaries to let value in also means lowering them to let risk in.

This observation reaches far beyond software. At a time when so many organizations, public and private alike, are adopting models that are more distributed, more collaborative, more dependent on trust at a distance, the question isn't whether to open up. It's how to think through, alongside openness, the protocols that make it sustainable. Because in the end, what protects an open organization is neither a boss nor a wall. It's the clarity with which it designs its own rules.