Who writes open source, and how?

I once submitted a small fix to a project and had it reviewed, argued over, amended and accepted by three people I have never met, in three countries, across two days, without a single video call, a project manager, or anybody knowing what anybody else did for a living. As somebody who has sat through a great many meetings about coordinating work, I found that faintly insulting and extremely interesting.

How does a project with thousands of contributors, no shared employer, no shared timezone and no shared language beyond bad English produce something that works? The answer is not enthusiasm. It is a set of mechanisms, and they are copyable.

Everything is written down, because nothing else survives

The first and most important property: the discussion is the record. Proposals, objections, reasoning, the final decision — all in text, all public, all permanent. Not minutes written afterwards by somebody who was in the room. The actual conversation, as it happened.

This is forced by circumstance rather than chosen for virtue. When contributors are spread across every timezone, synchronous discussion is impossible, so everything has to work when read eight hours later by somebody who was asleep. But the side effect is enormous: a person joining in five years can read why a decision was made, including the objections that lost. In most companies I have worked for, that reasoning existed only in the heads of people who have since left.

Small, reviewable pieces

Contributions arrive as individual changes, each one doing a single thing, each one explaining itself. Nobody sends six months of work in one delivery, because nobody could review it.

This is the mechanism that makes trust unnecessary, which is the part I find genuinely clever. A maintainer does not need to know whether a contributor is competent, honest, or employed by a competitor. They need to be able to read the change. A small change can be understood completely by one person in an evening; a large one cannot be understood by anybody, which is why large ones get rejected regardless of who sent them.

Underneath it all sits a tool built specifically for this problem: a version control system that lets thousands of people work on the same files simultaneously, keeps every version, and shows exactly who changed what. It was written by the same person who started the kernel, for exactly this reason, and it is arguably the more influential of the two projects.

Authority earned in public

There is a hierarchy, and it is strict — someone decides what goes in, and that person's decision is final. What is unusual is how the position is reached. Not by appointment, not by seniority, not by employer. By a long visible record of good judgement in the same public archive everybody else can read.

The practical consequence is that a good argument from an unknown person can win against a weak one from a well-known company, because both are written down next to each other and anybody can compare them. I have watched a corporate proposal get taken apart by somebody who was, as far as anyone could tell, a student. That is not how it goes in a meeting room, where the person with the title usually wins by default.

What it costs, because it is not free

Slowness. Asynchronous review means a small change can take days and a contentious one can take months. For anything with a deadline this model is genuinely worse than four people in a room, and pretending otherwise would be dishonest.

Harshness. Written review with no tone of voice, frequently from people writing in a second language, produces feedback that reads as brutal. Some of it is brutal. Several projects have lost good contributors this way, and the ones that have consciously worked on it have generally grown faster, which suggests the harshness was never the source of the quality.

And a bus problem that is worse than it looks. The structure concentrates authority in small numbers of maintainers, and many critical components have exactly one. That is a fragility the model has not solved.

The part I stole for my own work

Write the reasoning down where the next person can find it. Not documentation — reasoning. Why this drive and not that one. Why the backup runs at that hour. Why this client's machine is configured differently.

I started doing this because of how open projects work, and the person it has helped most is me, eighteen months later, looking at a decision I no longer remember making. A one-person business has exactly the same knowledge-loss problem as a distributed project — the colleague who was not in the room is your future self, and they will not remember either.