Protocol Review 3: Version Control

An Interview with Nora Paula Colón (NPC) on Custody, Clerics, and Control

What began as custody and clerical discipline became an executable record of who changed what, who can accept it, and what counts as “real,” and it is now straining under a world that produces change faster than people can read it.

The Last Person With the Keys

By Johnny Smith

On a damp afternoon in Queens, the kind that makes the radiator click like it is thinking, Nora Paula Colón — who calls herself “NPC” for short — lifts the lid of a plastic storage tub and waits a beat, as if the air inside might have manners and offer an introduction. The tub sits on the floor beside her kitchen table. The table itself looks like it has hosted a decade of small domestic negotiations: a shallow knife scar, a coffee ring that never fully left, a corner worn down to a softer color. On the stove a kettle whistles with a restrained insistence, and the smell in the room has the faint mineral note of old paper that has absorbed years of humidity and then surrendered it back again. A bus sighs past outside. A neighbor’s television laughs at something Nora does not hear.

She reaches in and pulls out a binder the size of a courthouse ledger. The binder is heavy enough that she brings it up with both hands. Its cover is a tired blue vinyl. It has a homemade label taped on with yellowed transparent tape, the kind that turns brittle and crinkles when you touch it: “CHANGE LOGS 1962–1964.” Under the label, a smaller note in pencil: “Watch for smudged carbon.” When she opens it, the rings creak. A few pages have curled corners, where someone once flipped too quickly with a thumb still damp from a machine room.

She lays the binder flat, smoothing the first page the way people smooth a bedsheet when they are trying to reset a room. The entries are handwritten in a small, practical script. Dates. Initials. A brief description that reads like weather: “Tape reorder. New routine. Confirmed output.” Every few lines, a red mark. Some entries have a second layer of information in the faint purple of carbon copy. The paper is thin and has that slight translucence where you can see the shadow of the next page’s ink.

Nora is seventy-eight. Her hair is pinned up with two sticks that look like they could be chopsticks or knitting needles, and she wears a grey cardigan with a patch on one elbow, sewn with care rather than style. On the counter behind her, a small wooden box holds index cards organized by hand in a way that suggests she still believes in alphabetical order as a moral principle. A pencil sits in a mug like an old tool resting between shifts. There is a laptop open beside a bowl of tangerines, the screen dimmed, a terminal window visible under a scatter of browser tabs.

“People think version control was invented by computer engineers,” she says, and her voice has the calm of someone who has watched that kind of sentence acquire too much confidence over the decades. She slides a finger down the page to a line from 1963. “Engineers love inventing things that already existed, only now there are buttons.”

She says this without a bite. Her humor has the dry edge of someone who has spent a lifetime in rooms where everyone believes they are being perfectly reasonable while doing something that makes another person’s week impossible.

Nora began as a librarian’s assistant in 1959, in a small technical library that served a research facility across the river. She learned to stamp due dates, to keep a record straight even when the requester was senior, to hold a boundary with a smile. She learned that most arguments about truth are arguments about which document gets to be treated as the reference. She learned how to handle paper so it lasts. She learned how to listen for the way a person asks for a file when they already know it exists and are afraid it might have changed.

Then she moved into machine rooms. There was a need, she says, for someone who could keep the record. A new program run for the first time, a routine adjusted, a patch that fixed one output and quietly broke another. The machines were loud, and the people who used them had the kind of focus that made conversation feel like a disturbance. Somewhere in that environment there still had to be an accountable narrative of change. A ledger existed to absorb the part of work that disappears when nobody writes it down. Her job moved between shelves and consoles, between controlled stacks and controlled systems.

On her kitchen table now, the binder is a physical reminder that version control began as a kind of custody. Someone held the master. Someone had the keys. Someone knew what the current state was, because they were paid, formally, to know. The early forms were paper and policy, handwritten initials, carbon copies, stamped pages, locked cabinets. Later they became software systems that offered the same promise in a more aggressive way: you could change the world, and the world would remember what you did.

Nora stands, turns off the kettle, and pours water into two chipped cups. The tea is black and strong, and she takes hers with a small spoonful of honey that she keeps in a jar labeled in her own handwriting. She brings the cups back like an offering and sits down again, her chair giving a small protest. The laptop wakes as she touches its trackpad. A graph flashes into view on the screen, then disappears behind the terminal.

“People keep saying,” she tells me, “that what we are dealing with now is speed. Speed is the symptom. The deeper thing is that you can have perfect records and still feel lost.”

She says it and then looks back down at the page as if the evidence might either support her or argue with her. She has spent time reading about how print changed the world, about how the ability to reproduce a text reliably made new kinds of authority possible and new kinds of confusion inevitable. She keeps a worn paperback of Elizabeth Eisenstein on a shelf above the kitchen sink, with a strip of tape reinforcing its spine. She has watched, in her own career, how the urge to standardize does two things at once: it creates reach, and it creates a hunger for a single correct version that people will fight over.

We talk for a while before we even sit down to record. She shows me a drawer where she keeps a few punch cards from the early days. She takes one out carefully, holding it by the edges. The card has tiny rectangular holes arranged in a pattern. It looks like a musical score for a machine that never got tired. She keeps the card in a sleeve, the way someone might keep a photograph.

“This one was a change that broke payroll,” she says, and there is a softness in her voice, as if she is greeting an old mistake with forgiveness. “They found it because the checks came out wrong. People got paid, and the amounts were wrong in a way that made everybody angry. The machine did exactly what it was told, and nobody could remember what it had been told yesterday.”

She taps the card with her fingernail. “This is why history matters. People call it bureaucracy. People say it like a slur. The only reason you can fix anything is because you can point to a moment and say, ‘Here.’”

By the time we begin, Nora has arranged the binder, the punch card sleeve, and a small stack of printouts on the table like props, though nothing about her feels performative. The objects are comfort. The objects are proof. She is the kind of person who distrusts any system that cannot be explained with at least one physical artifact.

Outside, the afternoon light is already thinning, turning the window into a darker mirror. The radiator clicks again. The neighbor’s television changes volume. Nora reaches over and presses record on a small black audio device placed between us. It looks like a pebble.

“You want the simplest version?” she asks.

I nod.

She looks at the binder and then at the laptop, as if to acknowledge the whole arc between them.

“Version control,” she says, “is the system that decides whether change becomes real.”

About This Protocol

This feature draws on a week of recorded conversation with Nora Paula Colón in Queens, plus visits to two small archival collections in New York that hold mid-century computing operations manuals and change-control forms, and a set of interviews with engineers who lived through the shift from centralized version control systems to distributed ones in the early 2000s. Nora’s personal materials include machine room logbooks from the early 1960s, several change-request binders from the 1970s, internal release checklists from the 1980s, and notes from later work with SCCS, RCS, CVS, Subversion, Mercurial, and Git in both corporate and volunteer settings. She also keeps a long-running reading list on print culture, recordkeeping, and institutional control, including Eisenstein’s work on printing and the way standardization reshapes authority and memory. The conversation ranges from physical custody and centralized gatekeeping to modern platform-mediated repositories and the current pressure of rapid automated change.

Edited Q&A

SMITH: What would you say version control does, if you had to explain it to someone who has never written code?

NPC: I picture a hallway, honestly. A long hallway with too many doors. You are walking down it carrying something fragile. It could be a draft. It could be a wiring plan. It could be a set of instructions for a machine that nobody wants to stop. People keep stepping out of those doors with opinions, and every opinion has hands. Someone says, “I fixed it.” Someone else says, “You broke it.” Someone says, “I have a better version.” You get to the end of the hall and there is a single door with a lock, and behind that door there is whatever counts as official.

Version control decides how you move through that hallway without dropping the fragile thing on the floor. It decides who gets a key, who gets to make a copy, who gets to walk up to that final door and put their hands on the lock. It keeps the trail of crumbs behind you so that when something goes wrong you can walk backward and find where it went wrong. That sounds modest. It is modest. It also decides what becomes history.

SMITH: When did you first encounter that hallway?

Before the software. It was physical. It was paper and keys and a cabinet that everybody pretended they could live without until it was missing.

In 1959, I was in a technical library. My job was tiny, on paper. I stamped dates. I reshelved journals. I kept a ledger of who borrowed what. The ledger was the point. People treated it like a nuisance. People wanted the book. People wanted the manual. The ledger kept the institution from lying to itself. Without it, everybody thinks they returned the book and the book becomes a rumor.

Then there was a moment in the early sixties where they needed someone who could do that kind of work around the machines. The engineers were brilliant. They were also impatient. They wrote changes down on scraps of paper and then lost them. They remembered what they did until they didn’t. The machine kept running. The output changed. People noticed when payroll was wrong or a report looked strange or a tape got overwritten. So they created logs, and the logs were like a library ledger with higher stakes.

I remember the smell. Hot dust. Oil. Ozone sometimes. The paper was thin and the carbon copy would stain your fingertips. The routine was a kind of ceremony. You wrote the date. You wrote the operator. You wrote the change. You wrote why, if you had time. You initialed. You filed it. Then you locked the cabinet.

That cabinet is already sounding like a form of authority.

It was authority. It was also a kind of mercy. People think authority is always a person. It can be a form. It can be a lock. It can be the fact that a change has to have a place to go where it will be seen again.

When you centralize a record, you create a single point where things become official. That gives you coherence. That also gives you conflict. People line up at that point. People argue there. People try to control it.

When did you see that become formal software?

I saw early versions of it as procedures first. Release checklists. Change request forms. You filled them out. Someone reviewed. Someone signed. The signature mattered because it meant a person would answer if it went wrong. The signature also meant you could blame them, which is why signatures have always been complicated.

Then the software came. In the seventies, there were systems like SCCS. I encountered it through people who talked about it like they talked about a new filing cabinet that came with strict rules. You could check things in and check them out. The system kept deltas. The system kept a record of who did what. It felt like someone finally admitted that the paperwork was part of the work and decided to mechanize it.

I later read the original paper by Marc Rochkind, and what struck me was the seriousness. It was written like someone had seen enough small disasters to decide that the record itself needed structure. That was the mood of that era. A sense that the system must be able to explain itself after the fact.

You said “check in and check out.” That metaphor stays with people.

Because it matches a physical world they already understand. Library. Tools. A key. A clipboard on the wall. You sign out the wrench, and the shop knows where the wrench is. If you leave with the wrench and nobody records it, the wrench becomes a ghost.

Centralized version control worked like that. The repository was the tool crib. The clerk might be a person, or it might be software. The idea is the same. The main copy remains coherent because you can control how changes enter it.

And that creates a class system.

It does. It creates a small group who can move things into the official state. Sometimes they deserve the power. Sometimes they accumulate it because nobody else has time. Sometimes they guard it because it makes them feel safe. Sometimes they guard it because it makes them feel important. A system does not care which motivation it is. The system only cares that the gate exists.

I watched this in corporate settings, where the gate had a name like “release engineer” and a badge and a desk near the build machine. I watched it in volunteer settings, where the gate had a name like “maintainer” and the desk was a living room. The emotions are similar. People want their work to count. People want to know what counts.

When you say “what counts,” you mean “what becomes real.”

Yes. Everyone can have files on their own machine. Everyone can have opinions. The world that matters is the world that ships, the world that runs, the world that other people depend on. Version control is one of the systems that decides when your private change becomes part of the shared thing.

There’s a famous line about software projects and communication overhead. Did you feel that in those early systems?

I did, and later I found language for it. I read Fred Brooks much later than I should have. A friend handed me The Mythical Man-Month, and it had that smell of old paperback and coffee and stubbornness. People pass that book around the way they pass around a cautionary tale.

The line people quote is about adding people to a late project making it later. The point that stayed with me was simpler: coordination costs are real. They do not vanish because you want them to. The more people you have, the more time you spend managing the relationships between their work.

Centralized version control systems were a response to that. They were a way of saying: we can reduce the chaos of coordination if we reduce the number of ways changes can enter the official stream. You get consistency. You also get queues. You also get resentment.

So the protocol shaped behavior.

Of course. If you tell people they can commit directly, they behave one way. If you tell them they need permission, they behave another way. If you tell them the test suite must pass, they learn to fear the test suite. If you tell them the release window is Friday at 4 p.m., they learn to treat Thursday like a cliff edge.

I watched people plan their lives around release gates the way people plan their lives around the post office closing time. You start to feel the weight of the deadline as a physical thing.

You’ve seen systems from paper logs to SCCS to Git. What, in your view, changed with Git?

The location of power. The texture of disagreement. Before Git, a lot of systems assumed that coherence came from a single source of truth. One main repository. One place where the history lived. You could make branches, you could make copies, you could experiment, and the gravitational pull was always the center.

Git allowed the center to become a choice. That is the thing people miss when they talk about it like it was simply a better tool. It was a social solution packaged as a technical system. Anyone could have a full history. Anyone could record changes without asking. The act of recording became cheap and personal. The act of acceptance became the point of control.

That separation matters. It moves the fight. In a centralized system, people fight over access. In Git, people fight over merging. The fight becomes more explicit. It becomes a conversation about whether a change deserves to enter a shared branch, instead of a conversation about whether you are allowed to touch the repository at all.

You’re describing a shift from permission to selection.

Yes. The system stops asking, “Are you allowed to write history?” The system starts asking, “Whose history will we accept into ours?” That is a different kind of authority.

It also changed the emotional life of contributors. People could work without feeling like they were asking for a favor. They could build a branch and show it. The work could speak before the status did. That is liberating for some people. It is threatening for others. Some maintainers felt like they lost a lever of control. Some contributors felt like they gained a door.

Git also came out of a particular conflict.

It did. People like to present these systems as neutral. They are born in tension. They come from pain. They come from someone saying, “This is not sustainable.”

If you read the origin story, you see the urgency. A large, high-stakes project. A breakdown in trust with a tool vendor. A need to keep moving without waiting for permission. The system is built to ensure that no single choke point can stop the work. That is a governance decision expressed as software.

How does that relate to your early experience with cabinets and keys?

The cabinet was a choke point. It gave you coherence. It also gave you fragility. If the cabinet burned, you lost history. If the cabinet key holder got sick, the work slowed. If the cabinet key holder got paranoid, the work became political.

Git is like giving everybody a copy of the cabinet. The lock still exists in a sense, because there are still branches people treat as official. The difference is that the system tolerates multiple cabinets without falling apart. It accepts that coherence is negotiated. It accepts that disagreement will produce divergent lines. It treats divergence as normal.

You said earlier that version control decides what becomes history. In Git, everyone can create history. How does that change the idea of history?

It makes history plural until someone makes it singular.

That is a strange sentence, so let me ground it. Imagine a meeting. Ten people leave with ten interpretations. The official minutes become the version that counts. Git allows everyone to write minutes. The shared branch becomes the official minutes only when someone chooses it, or when enough people treat it as official that it becomes difficult to challenge.

This can be healthy. It can also become exhausting. When there are many possible histories, you need a mechanism for consolidation. The mechanism is often social. It is often reputation. It is often endurance.

Endurance?

The person who keeps showing up. The person who reviews pull requests at midnight. The person who answers the same question for the fiftieth time. Systems have a way of selecting for that. People call it dedication. It is also a workload distribution problem.

That’s where the managerial aspect becomes visible.

Yes. People like to imagine management happens in meetings and performance reviews. A lot of it happens in defaults. Who can merge. Who can approve. Who can push a tag. Who can cut a release. Those are governance decisions. They shape behavior more reliably than a speech.

In centralized systems, governance is obvious because access is obvious. In distributed systems, governance is subtle because it appears at integration points. The maintainer who merges becomes a kind of editor. The repository becomes a publication. The release becomes a stamp.

You’ve read Eisenstein. How does printing enter your understanding of this?

When I first read Eisenstein, I felt relief. She described something I had seen in a different medium. Printing increased the reach of text. It stabilized copies. It made it possible to refer to the same page across distance. That created a new kind of authority. You could argue about what the text meant, but you could at least agree on which text you were arguing about.

Version control does something similar for change. It stabilizes the record of what happened. It makes it possible to point to a specific commit or a specific revision and say, “This is the moment.” That changes how organizations remember. It changes how they blame. It changes how they fix.

It also produces obsession. People become attached to the idea of the correct version. They treat it like a moral thing. In printing, you get editions and errata. In version control, you get tags and reverts. People develop rituals around them.

You mentioned reverts. You called reversibility symbolic under certain conditions. What do you mean?

In theory, you can always go back. In practice, going back has consequences. You might break compatibility. You might lose data. You might invalidate assumptions. You might anger someone whose work you are reversing. Reversibility is a technical affordance and a social act. When people say, “Just revert it,” they are speaking like a person who has never had to explain a revert to a stakeholder who lost a week of work.

In the early paper log days, reversing a change meant physically changing what was in the machine room. It meant pulling a tape. It meant reloading. It meant somebody staying late. The cost was visible. In modern systems, the cost looks smaller because the action is a command. The consequences remain real. The system hides the labor behind the command.

How does that connect to “who decided”?

The record answers that in a thin way. It tells you whose account made the change. It tells you who merged it. It tells you who approved it if the platform records approval. It rarely tells you the full story of why. Sometimes the commit message is beautiful. Sometimes it is “fix.” Sometimes it is “final2.” People write commit messages the way they write notes to themselves when they are tired.

So you can have a perfect record of what happened and still have a weak record of why it happened. That gap matters more as the environment becomes more complex.

Let’s talk about that environment. You’ve mentioned automation and LLMs. What do they do to this system?

They change the ratio between output and attention. For most of my career, the bottleneck was the ability to produce changes. People had ideas. They had feature requests. They had bugs. The hard part was writing the code, testing it, getting it into the system without breaking everything else.

Now I watch teams where the hard part is reading. The change arrives quickly. It arrives in bulk. It arrives with a confidence that is sometimes deserved and sometimes theatrical. People can generate a hundred lines, a thousand lines, with a prompt. They can rewrite a file because they feel like the file should be cleaner. They can reshape an entire area of a codebase as if they are rearranging furniture.

Then version control faithfully records it. The record expands. The review queue expands. The commit history becomes thick. The question becomes: who has the time to absorb the meaning of the change?

You’re pointing at comprehension as the constraint.

Yes. A human can hold only so much detail. A human can develop a sense of a system, a feel for it, a set of instincts. That takes time. When the change rate outpaces that, you get a situation where the record remains complete and the understanding becomes partial.

You still have a history. You also have a growing number of people who interact with that history like it is weather. They accept that changes arrive. They accept that breakage happens. They accept that the remedy is another change.

This can work for a while. It can also create a kind of drift. The codebase becomes an ecosystem where nobody knows the full shape, and authority becomes a matter of who can fix the immediate break rather than who understands the deeper structure.

How does Git specifically strain under that?

Git assumes a certain unit of work. It assumes that a commit represents something a person can explain. It assumes that a diff is something someone can read. It assumes that a review is a meaningful moment of selection.

When you flood the system with changes, the temptation is to turn review into a formality. You rubber-stamp. You skim. You rely on automated tests to catch what your eyes cannot catch. Tests become the new gatekeeper. The build becomes the new judge. That shifts authority again, away from human reading and toward machine verification.

That solves certain problems. It creates others. Tests cover what they cover. Tests miss what they miss. People then learn to treat whatever is untested as invisible risk.

You’ve lived through multiple shifts in how authority appears. Where do you see it now?

I see it in pipelines and permissions. I see it in who can merge to the branch that triggers deployment. I see it in who can approve a change to infrastructure. I see it in who can flip a feature flag.

The repository sits under those layers. Git is foundational, and many organizations behave as if Git is the whole story. In reality, the protocol has grown a stack. Code review systems. Continuous integration. Release management. Incident response. Audit requirements. The governance of change is distributed across that stack.

When LLMs accelerate change, the stack thickens. People add checks. People add bots. People add rules. They add new forms of gatekeeping because the old gatekeeping was too slow and too political, and the new gatekeeping becomes automated and quiet.

Earlier, you described central systems producing gatekeeping and conflict. Git changes where that happens. Does it eliminate the politics?

It moves them. It changes their shape. People will always negotiate status, trust, and control when they share a system that matters. In centralized systems, politics often attach to access. Who gets commit rights. Who gets to push. Who is inside the trusted circle. That creates a clear boundary and a clear resentment.

In Git-based worlds, you can work without access. You can create history without permission. The politics gather around acceptance, and around attention. Which pull requests get reviewed. Which changes get discussed. Which contributors get a response. Which forks get treated as serious. Attention becomes the scarce resource. A system can remove one scarcity and reveal another.

You keep returning to scarcity.

Because protocols exist where scarcity exists. If everything were abundant and harmless, nobody would care about change logs. Nobody would care about version control. The system exists because the shared artifact is valuable and fragile.

What were the early failure modes you saw in centralized systems?

Merge conflicts before the term. People stepping on each other’s toes. People overwriting work. People arguing over whose change caused the bug. People working around the gate by keeping private copies and then dumping them in at the last moment, creating chaos.

There was also a quiet failure mode: fear. People feared touching the official branch. People feared being blamed. People feared that a mistake would be visible forever. They delayed. They hid. They hoarded changes.

A central gate can produce discipline. It can also produce avoidance.

And in Git?

In Git, you get the opposite failure mode sometimes: proliferation. Branches everywhere. Forks everywhere. Multiple versions of the truth in motion. People lose track. People merge without fully understanding. People carry long-lived branches that become their own little worlds.

Abandoned branches are a kind of fossil. They show what someone hoped would happen. They show what the system tolerated. They show what the organization could not integrate.

You’re making it sound like the repository becomes an organizational memory, with its own archaeology.

It does. If you read it like a record, you can see patterns. You can see bursts of activity. You can see moments of panic. You can see a series of reverts that look like a person trying to un-say something. You can see big refactors that feel like someone moving houses.

You can also see silences. Long stretches without commits. Areas of code untouched for years. Those silences can mean stability. They can also mean fear. They can mean nobody knows what it does. They can mean nobody wants to be responsible.

You said earlier: version control decides whether change becomes real. In a modern organization, what else participates in that decision?

The platform. The bot. The reviewer. The build. The release manager. The incident that happened last week and made everyone cautious. The compliance team that added a requirement for approvals. The executive who demanded faster shipping. The customer who demanded fewer outages.

The system becomes a set of conditional permissions. “If tests pass, then.” “If two approvals, then.” “If the change touches this directory, then.” These are policies encoded as workflow. They feel neutral because they are expressed as rules. They carry assumptions about risk and trust.

That’s the managerial layer embedded in software.

Yes. It’s management done through the shape of the path you are allowed to walk.

I used to sit in meetings where people argued about process. The argument would end with a document. Then the document would be ignored. Now the argument ends with a pull request template or a required check. The document becomes an enforcement point. People adapt to enforcement. They complain, and then they comply, and then they forget how things felt before.

Let’s return to your kitchen table for a moment. You have the old binder. You have the laptop. What do you feel when you look at both?

I feel affection for the binder. I feel respect for the laptop. The binder is honest about its limitations. It shows you the handwriting. It shows you the smudge. It shows you where someone hesitated and rewrote a line. The laptop gives you power, and power has a way of making people forget what it costs.

I also feel a kind of sadness. The binder was written by people who had no illusions about the need to explain themselves to the future. They wrote for the next shift. They wrote for the person who would be blamed if something broke. They wrote because the institution demanded it.

Modern commit histories are often thinner in that sense. The system records more. People explain less. People assume the diff speaks. Sometimes it does. Often it does not.

And the LLM moment increases that?

It does, because the change can be produced without the same relationship to its consequences. When you write a change by hand, you feel each line. When you generate, you supervise. Supervision can be responsible. It can also be shallow. People can approve things they do not fully understand because the output looks plausible.

Then the repository becomes a record of plausibility. The record remains useful. It remains dangerous.

What layers do you think will emerge above Git in response?

Systems that manage attention. Systems that summarize. Systems that classify. Systems that enforce smaller units. Systems that require rationale in a structured way because free-form rationale disappears under load.

You already see it. People use bots that label pull requests. People require linked issues. People require approvals from specific owners. People build dashboards that show change volume, failure rates, time to merge. They try to measure trust.

The system grows a nervous system. The repository becomes a spine, and the layers above become senses and reflexes.

Does that risk turning back into centralized gatekeeping?

It risks creating new forms of gatekeeping that feel less personal. A centralized system with a human gatekeeper can be negotiated with. You can plead. You can explain. You can build a relationship. An automated gatekeeper does not care. It blocks you until you satisfy its conditions. That can be fair. It can also be brittle.

Every system solves a class of problems and produces a new class of frustrations. People then build new systems on top. That is how organizations evolve.

When you think about Git’s core shift, decentralizing history creation and making acceptance the key, do you see that as a permanent shape?

I see it as a response to a real problem. I see why it won. I see why people rely on it.

I also see the costs. Decentralized history creation increases freedom. It increases the number of possible realities. That means more work is required to integrate. Someone has to decide. Someone has to review. Someone has to merge. The labor does not disappear. It migrates.

In some contexts, that migration is worth it. In others, people prefer a strong central line because the cost of divergence is too high. Large organizations sometimes build constraints that recreate central discipline on top of distributed tools. They do it because the alternative feels like chaos.

So the protocol gets re-shaped by its environment.

Yes. The environment includes the size of the team, the risk tolerance, the regulatory pressure, the number of stakeholders, the consequences of failure.

Open source has a particular environment. It has uneven trust. It has volunteers. It has conflicting goals. In that world, the old model of commit access becomes intensely political. The distributed model reduces that particular tension by letting people work without asking. Linus talked about that in a way that is blunt and funny and also true. People can be reckless. People can be careless. A centralized gate becomes a fight over who is allowed near the keys.

Distributed systems reduce that fight. Then they create a new challenge: how to integrate responsibly without drowning in options. That is where maintainers become editors, and editing becomes the work.

When you say “editing,” it sounds like printing again.

It is similar in spirit. When texts proliferate, selection becomes power. When changes proliferate, merging becomes power. The power can be exercised with care or with ego. The protocol does not guarantee the care.

You’ve worked with people who were excellent gatekeepers and people who were difficult ones.

Yes. The excellent ones had a sense of proportion. They understood that the purpose of control is to protect the shared artifact, and also to keep contributors engaged. They understood that rigidity has costs. They explained decisions. They wrote good commit messages. They maintained a human tone.

The difficult ones used the system as a weapon. They delayed. They ignored. They required unnecessary perfection. They treated the gate as their identity.

A protocol can amplify character.

Do you think the current moment amplifies certain character traits?

It amplifies impatience and fear. Impatience because change is cheap and people expect motion. Fear because the consequences remain expensive and the system becomes harder to understand as it grows.

People then look for safety. Safety can become more rules. Safety can become more automation. Safety can become fewer people allowed to merge. The pendulum swings.

How should we understand “version” now, given the pressures you describe?

“Version” used to mean a state you could hold in your head. A release. A tape. A printed manual. A specific thing you could point to and say, “This is what we shipped.” Even in Git, a tag can feel like that. A named moment.

In a world of constant deployment and constant refactoring, “version” becomes a moving boundary. It becomes a set of conditions rather than a single artifact. It becomes a promise: at this moment, the system behaves within expected limits. That is a different kind of version. It is less like a book edition and more like a heartbeat.

That sounds unsettling.

It is also honest. The systems are alive in a way they used to pretend they were not. They change continuously. The record is continuous. The question becomes: can humans continue to understand enough to be responsible?

And you think the answer will be new layers above Git.

Yes. Layers that restore proportion. Layers that help people see which changes matter. Layers that capture rationale. Layers that enforce smaller scopes. Layers that turn the flood into a stream again.

Those layers will also introduce their own politics. They will privilege certain forms of work. They will create new categories of contributors. They will create new gatekeepers, human and automated.

That is the trade. You gain coherence and lose some freedom. You gain speed and lose some comprehension. You gain safety and lose some flexibility. Every organization will choose where to sit on those curves, and they will move over time as the environment changes.

Always a trade-off isn’t it?

Because that’s where responsible thinking ends up. Version control gave us a way to keep going when the work outgrew memory and when trust became uneven. Git gave us a way to keep going when central gates became political choke points and when disagreement became normal. The new moment is asking for a way to keep going when change itself outpaces attention.

The record will keep getting better. The need for judgment will keep staying. The tension between them will keep producing new protocols, and new frustrations, and new forms of care.