Forty People, One File: What Open Source Actually Feels Like

On 11 and 12 August 2026 we put about forty people in a room, gave every one of them push access to the same repository, and asked them to build one web page together. No approvals, no gatekeeper, no one merging on anyone's behalf. Two days later that page had 41 tiles on it, 33 people with work in the history, and 249 saved changes. Watching it happen is the closest thing to seeing open source software get invented in front of you.

The setup: one file, forty terminals

The project was deliberately crude. One repository, one index.html, and 41 blocks marked off with start and end comments, one per person. The only rule was "edit inside your own markers." Everyone got write access to main on day one, which meant anybody could publish to the live page at any moment without asking a single human being for permission.

The room was three teams who work on India's school education ecosystem. Program people, communications people, operations people. Most of them had never opened a terminal before that morning. By the end of the first hour, 63 changes had landed on the shared page.

What actually happened

The numbers are not hand written. They are counted from the project's own history, which is the quiet magic of doing work in git: the record keeps itself.

• 249 saved changes across two days, from 33 people.
• 31 people published their own work to the live page, and 30 tiles were live by the end.
• 52 changes in one half hour, the busiest stretch, all of them landing on the same file.
• One person was still building at 1:22 in the morning, long after everyone else had logged off.

That last one is the tell. Nobody was assigned a tile. People stayed up because the thing they made was going to be visible on the internet with their name on it, and that is a different motivation from finishing a task.

The merge conflict is the moment, not the problem

Of those 249 saves, 159 built something and 90 existed only to untangle two people's edits. Thirty six percent of the work was collision cleanup. Every one of those 90 started the same way: someone hit publish, the push was refused, and their screen filled with a wall of red text they had never seen before.

This is the part people brace for and it turned out to be the part that taught the most. A refused push is git telling you that somebody else improved the shared thing while you were working, and would you please look at their work before you overwrite it. Three commands later you are back in business. Once you have done it twice, the fear is gone permanently, and you have understood something real about how thousands of strangers maintain the software the world runs on.

It is also a design lesson. Ninety collisions is not a people problem, it is a one file problem. Split 41 tiles into 41 files stitched together at build time and most of that friction disappears. Every mature open source project has learned this the same way: the shape of the repository decides how much of the day gets spent on coordination.

Nobody needed permission, and 25 people asked anyway

Here is the finding that stayed with us. The instructions said, in plain language, publish straight to the shared page, no approval needed. Everyone had the access to do it. And still, 45 pull requests were opened by 25 different people. Most cleared in about a minute. Twelve waited more than an hour, the longest for 23 hours, and five were closed without ever going live.

Nobody was being timid about the tool. They were being careful about each other. Asking before touching something shared is the instinct every functional team has, and open source is what happens when you formalise that instinct into a process instead of a feeling. Pull requests were not invented to control people. They were invented because people already wanted to check.

The practical lesson for anyone running a session like this: if you offer two ways to publish, the slower and safer one wins, no matter what the guide says. Say one thing, and say it first.

Starting was never the hard part

Thirty three of about forty people opened the project. Thirty one wrote something of their own. Thirty one got it published. The drop off is not where anyone expects it: nobody stalled on "I cannot think of what to build" or "I do not understand the code." They stalled at the last step, between finished work and live work, and almost every reason was a setup problem rather than a skill problem.

• Finished work sat in branches with no obvious road to the page.
• There was no way to preview a tile between saving and going public, so the safe move was to try less.
• Five people showed up under two different names because git was never told who they were, so their work got credited to nobody.
• Six people made a change that reached into someone else's tile, which nothing in the repo prevented.

Every one of those has a fix that costs an afternoon: one file per person, a single publish command that fetches and replays and sends, a local preview, and identity set once during setup. Which is precisely the arc every open source project walks. It starts as a shared file and a rule enforced by good manners, and it grows tooling exactly where the good manners keep failing.

Why this is what open source looks like at the start

Strip open source down and it is not licences, foundations, or a code of conduct. It is this: a thing that belongs to everybody, that anybody can change, where the history of who changed what is public and permanent. Everything else is scaffolding added later, at the exact point some group of people hit the wall we hit in two days.

You can read that in a definition and it stays abstract. You cannot forget it after you have watched 52 changes land on one file in half an hour, argued with a merge conflict, and then refreshed a public URL to find your work sitting next to thirty other people's.

The other thing it kills is a myth. Contributing to open source sounds like something reserved for career engineers. It is not. It is a text edit, a commit message, and a push, and the people doing it here had job titles in communications and programs. What used to be the barrier, knowing the commands, is now a conversation with an AI agent in your terminal that runs them with you and explains what came back.

Try it with your own group

If you run a team, this is a two hour exercise with a real artifact at the end and no cost. Make a repository. Put one page in it with a block per person. Give everyone push access on purpose. Let it break, because the breaking is the lesson, and fix it live in front of them. What people leave with is not git trivia. It is the physical sense that a shared thing can be safely changed by anyone, which is the whole idea underneath every piece of open source software they already use.

If you would rather see it done before you run it yourself, that is what our free live demo class every Tuesday is: one hour on Google Meet, watching AI run a real business and build a website from a blank terminal to a live URL. No card, nothing to buy, and it ends with open Q&A.

Forty people. One file. Two days. It held.