How open source solved remote work
What if open source has been running the world's largest distributed work experiment all along?
In March 2020, a few hundred million people became “remote workers” overnight. Companies scrambled. They bought Zoom licenses, stood up a Slack, shipped everyone a second monitor, and moved the Monday all-hands onto a grid of webcam faces. The org chart didn’t change. The standup didn’t change. The expectation that real work happened in meetings, in real time, with everyone present, didn’t change. They took the office and pointed a camera at it.
If you’ve spent any time contributing to open source, you watched this happen with a particular kind of déjà vu. Because the thing the rest of the workforce was panic-inventing—collaboration across time zones, with people you’ve never met, without a building to hold it together—you’d already been doing for years. On nights and weekends. For free. With strangers. And it worked.
Here’s the part the endless “future of work” takes never quite say out loud: open source is the largest, longest-running distributed-work experiment in history. It just never called itself that. Linux was remote-first three decades before “remote-first” became a LinkedIn headline. A maintainer in Berlin merging a patch from someone in São Paulo they’ll never meet, reviewed asynchronously over a weekend, shipped to millions—that was a Tuesday in 2005. The pandemic didn’t invent distributed work. It just forced everyone else into a room open source had been living in the whole time.
You don’t need me to explain how distributed teams work—you’re the one who figured it out. The useful part is naming it: once you can name what you already do, you can bring it to the day job that’s still doing it wrong.
How open source invented distributed work before it had a name
Strip away the code for a second and look at the mechanics of how a healthy open source project operates. This is what it looks like when open source works well. And almost none of it is technical. It’s a way of working that companies are now paying consultants to teach them.
The work happens in writing, where anyone can find it. A contribution starts as an issue. The reasoning lands in a pull request description, not in someone’s head. The debate plays out in a thread that’s still there a year later. Nobody schedules a meeting to decide whether to merge—the discussion is the deciding, and it leaves a trail. Companies are now rediscovering this and calling it “async by default,” as if it’s a novel methodology and not just how you’ve shipped software your whole life.
You’re judged on what you ship, not when you’re online. A maintainer reviewing your patch has no idea whether you wrote it at 9 a.m. or 2 a.m., whether it took you an hour or a week, whether you’re a principal engineer or a high schooler. They can’t see your hours. They can’t see your face. They see a diff. The contribution stands or falls on its merits. That’s the purest form of the thing every “results-oriented workplace” mission statement gestures at and almost none of them actually practice: impact over input. You are a handle and a body of work, and it turns out that’s enough.
Decisions have URLs. When someone asks why a project chose one approach over another, the answer is a link—to the Request for Comments (RFC), the issue, the Pull Request (PR) where it got argued out and settled. The reasoning outlives the people who made the call. Contributors leave, maintainers burn out and hand off, and the project’s memory survives because it was never in anyone’s head to begin with. Compare that to the average company, where the answer to “why did we build it this way?” died in a Slack channel that’s since been archived and a meeting that left no notes.
Onboarding is reading, not interrogation. A newcomer to a project doesn’t book time on five calendars to get up to speed. They read the history. The issues, the past PRs, the design docs, the commit messages. The why is written down, so they can dig it up themselves at midnight in their own time zone. The project scales to contributors precisely because ramping up doesn’t require a synchronous human bottleneck.
Nobody is watching, and it works anyway. There’s no manager pinging a contributor to ask if they’re at their desk. There’s no green-dot surveillance, no “just checking in.” The whole system runs on trust in the artifact, because surveillance isn’t even an option—you can’t monitor a volunteer in another country whose name you don’t know. And the work still ships. Open source is the standing proof that you do not need to watch people to get great work out of them. You need to make the work legible.
How open source turned remote work constraints into a force multiplier
Put those five together and you have a working definition of distributed collaboration—written-first, in the open, judged on output, durable, trusting. Now look at what most companies actually did when they “went remote.”
They digitized the office. They took synchronous, presence-based, manager-in-the-loop work and moved it onto a screen—same meetings, same hours, same expectation that you’re reachable and visible, now with worse audio. They added webcams to the surveillance instead of removing the need for it. They kept the standup and put it on Zoom. They confused being remote with being distributed, and they’re not the same thing. Remote is where your body is. Distributed is how the work flows. You can be remote and still completely synchronous, still bottlenecked on meetings, still rewarding the person who’s merely around—and most “remote” companies are exactly that.
Open source skipped the office entirely, so it never had an office to digitize. That’s the whole advantage. The constraints that made open source possible—no shared building, no shared time zone, no way to see who’s working—forced the practices that turn out to be the actual point. Working in the open isn’t a nice-to-have it adopted out of idealism. It’s load-bearing. It’s the only way the work could happen at all. The rest of the workforce is now reverse-engineering, at enormous cost, the practices your community arrived at because it had no other choice.
How open source contributors can bring distributed work skills to any job
If you maintain or contribute to open source, you already work in a way that most knowledge workers will spend the next decade clumsily reaching for. That’s worth saying out loud, because it’s easy to undervalue something you do for fun.
It’s also an edge. The next time your employer talks about “figuring out remote” or “getting async right” or “reducing meeting load,” you don’t have to treat it as an open question. You’ve already run the experiment, at scale, for years. You know that the thread can replace the meeting, that the written record beats the standup, that you can trust people you can’t see if you can read what they shipped. You’ve got the receipts. Bring them.
So here’s the test, the next time someone at work insists a decision needs a meeting, or that you can’t really trust people you can’t see: ask how your favorite open source project would handle it. The answer is almost always write it down, do it in the open, and judge it on what ships. That’s not a remote-work hack somebody invented in 2020. It’s how your community has worked the entire time.
Everyone else is just catching up. Thanks for figuring it out first.
The longer version
The community figured this out first. Open and Async is my attempt to write it down—a full guide to working in the open and communicating asynchronously, built on the practices open source has run on for years. Consider it a thank-you note, written so the rest of the workforce can finally catch up.
This article is adapted from Open source already solved remote work. Everyone else is just catching up by Ben Balter, and is republished with the author's permission.
Ben Balter spent over a decade at GitHub, most recently as Director of Hubber Enablement, where he helped thousands of GitHubbers do their best remote work. He has spent his career trying to figure out how large engineering organizations actually work—and why the obvious answers are usually wrong.