In 1991, a Finnish college student named Linus Torvalds posted a message to an internet forum. He was building a small operating system — the software that manages a computer's basic functions — and he wanted feedback. He described it as "just a hobby" and said it "won't be big and professional."
He was wrong about that last part.
Today, Linux runs the majority of the world's servers, most supercomputers, every Android phone, and most of the infrastructure that powers the internet. Microsoft, Google, Amazon, and virtually every major tech company depend on it. It is, by many measures, the most important piece of software ever written.
And for most of the 1990s, it looked like nothing was happening.
The long preparation
This is the part of the story that almost never gets told, because it's not dramatic. While Microsoft and Apple dominated the computer market, Linux was quietly getting built — by volunteers, in their spare time, for free. No venture capital. No marketing department. No product roadmap. Just thousands of people around the world, each fixing the piece they cared about, contributing back to a shared codebase anyone could use.
The shift from "hobby project" to "runs the world" didn't happen gradually. It happened fast, after very long preparation. For most of the 1990s, if you'd pointed to Linux and said "this is going to beat Microsoft," people would have laughed at you. The conditions weren't visible from the outside. The work was happening anyway.
For a long time, it looks like
nothing is working.
Then something shifts and
everything reorganizes fast.
Why it won
Linux didn't beat Microsoft and Apple by being better-funded or better-marketed. It won for structural reasons — because of how it was built, not just what it was.
First, it was built by people who used it. Every contributor had a direct stake in the quality of their piece. The person fixing the networking code was also running their own server on it. The person improving the filesystem was also storing their own files on it. That's different from employees building software for customers they'll never meet. The knowledge was local. The feedback was immediate.
Second, it got smarter over time instead of more brittle. In a traditional software company, the codebase belongs to the company. When an employee leaves, their knowledge mostly leaves with them. In Linux, every fix, every improvement, every hard-won lesson gets written into the shared codebase. The project accumulates knowledge. It doesn't lose it to turnover or reorganization.
Third — and this is the key — it was infinitely adaptable. Because anyone could modify it, Linux could be shaped to fit situations its original creators never imagined. Smartphones. Supercomputers. Submarines. Mars rovers. No centrally planned product roadmap could have anticipated all of those. But a system that anyone can adapt doesn't need to anticipate them. It just needs people who care about those problems to show up and do the work.
That adaptability is what made the Android moment possible. When smartphone hardware became viable, the Linux community had twenty years of mature, stable, adaptable code ready to run on it. Microsoft had to start from scratch. They never recovered.
What this has to do with your street
The Linux story is usually told as a tech story. But the pattern it demonstrates is much older and much broader than software.
Big changes don't accumulate gradually and then arrive. They arrive suddenly — after long, mostly invisible preparation. The preparation builds the conditions: the relationships, the skills, the shared tools, the common language, the organizational capacity. When something shifts in the environment — a new technology, a crisis, a political opening — the prepared system can move fast. The unprepared one can't.
The Civil Rights Movement didn't emerge from nowhere in 1955. It emerged from decades of legal groundwork by the NAACP, organizing infrastructure built through Black churches and civic organizations, generations of leaders trained in historically Black colleges, and a network of relationships across the South that could mobilize quickly when the moment came. Rosa Parks was a trained organizer, not a tired seamstress who spontaneously refused to move. The moment was real. The preparation made it land.
The same pattern shows up in cities. Neighborhoods that successfully fight off destructive development, or win genuine changes to policing, or secure real resources for their schools — they almost never do it on the first try, starting from scratch. They do it because someone started building the organization years earlier, when there was no immediate crisis to justify it. The tenant association that existed before the eviction wave hit. The neighborhood group that had been meeting monthly for three years before the rezoning proposal landed.
One of the most demoralizing things about slow, patient organizing work is that it looks like nothing for a long time. You're building relationships. You're developing shared language. You're learning how local power actually works. You're creating structures that can absorb new people and move quickly when needed.
None of that is visible as "winning." But it's exactly what winning requires. The Linux developers writing networking code in 1994 weren't winning. They were building the conditions for winning — which arrived thirteen years later in the form of Android.
The work that looks like nothing is often the work that matters most.
What you're actually building
If you've read this far in this series, you probably already sense that the usual options — vote, petition, attend a meeting, post online — aren't sufficient on their own. They're not useless. But they don't build the conditions for the kind of change that actually reorganizes how things work.
What does build those conditions is the same thing Linux was built from: real relationships with real people in your immediate community — not followers, not contacts, but people you'd call in a crisis and who would call you. Organizations with track records, however small — a tenant group that has successfully resolved three disputes, a mutual aid network that delivered during the last emergency, a neighborhood association that got one thing changed and knows exactly how it did it. Shared language for what's actually happening, so when the moment comes you're not burning your energy arguing about whether the problem is real. Skills that transfer — how local government actually works, how to run a meeting, how to read a budget, how to escalate.
None of that is glamorous. None of it trends. The Linux developers writing networking code in 1994 were not winning. They were building the conditions for winning, which arrived thirteen years later in a form nobody predicted.
When something shifts — and things do shift, faster than anyone expects — the question is whether the preparation is there. Linux was ready when smartphones arrived. The question is whether your neighborhood is building toward being ready for its moment.
That moment will come. The preparation is the work.