Daniel's been thinking about infrastructure — the kind you don't notice until someone asks how it got there. GitHub turns eighteen this year, which means there's a whole generation of developers who've never emailed a patch file to a stranger and hoped for the best. His prompt is basically: what did collaboration look like before that green button existed, who built this thing, and how did open source go from an ideological niche to the default way the world writes software?
Eighteen years. That puts the launch in April two thousand eight. And you're right — it's invisible now. But the world it walked into was completely different. Proprietary software dominated. Microsoft Windows and Office were the default assumption about how software got made and sold. Open source existed, but it was... earnest. Ideological. The kind of thing you did because you believed in it, not because it was convenient.
Daniel's asking about that cultural shift specifically — how publishing your code, forking someone else's project, collaborating with strangers, all of that went from radical to ordinary. And he wants the origin story. The people, the problem they were solving, and why Git mattered before GitHub ever existed.
So let's go back to before the pull request existed — to a world where contributing to someone else's project meant emailing them a patch and waiting.
To understand what GitHub changed, we need to see the world it walked into. And that world was... SourceForge.
SourceForge. Founded in nineteen ninety-nine, acquired by VA Linux, eventually sold again. By the mid-two thousands it was the place for open source hosting. It gave you a project page, a download section, a CVS or Subversion repository, some basic bug tracking. And that was it.
And CVS and Subversion were...
Centralized version control. One canonical repository on one server. You'd check out a copy, make changes, check them back in. If you wanted to contribute to someone else's project, you'd download a tarball of the source, make your changes locally, generate a diff file, and email it to the maintainer. Who might respond. Might not. Might respond six months later after you'd already moved on.
So the collaboration model was essentially: shout into the void and hope the void had a mailing list.
That's not far off. And the void often had strong opinions about coding style and didn't appreciate your variable naming conventions. There was no lightweight way to propose a change. No way to see what other people were working on. No social layer at all. Open source was a broadcast medium — the maintainer broadcasted releases, and contributors broadcasted patches. There was no conversation.
And discovery? If I wanted to find a project, or see what was active, or know who was working on what...
You'd browse SourceForge's project directory, which was organized by category. You'd look at download counts, which were the only real signal of popularity. You couldn't see the code easily — you'd have to check it out. You couldn't see who was contributing or how active development was. It was like browsing a library catalog where half the books were abandoned and you had no way to tell which half.
So that's the collaboration landscape. Now the version control piece — because this is where people get the timeline wrong. Git didn't come from GitHub. Git came from Linus Torvalds, three years earlier, and the story of why is worth telling.
It's a great story. Two thousand five. The Linux kernel had been using a proprietary version control system called BitKeeper. It was distributed — every developer had a full copy of the repository — and it handled the massive scale of kernel development reasonably well. But there was tension. Some kernel developers, notably Andrew Tridgell, had been reverse-engineering the BitKeeper protocol to write a free client. Larry McVoy, BitKeeper's creator, revoked the free license for Linux development.
So Torvalds suddenly had no version control system for the largest open source project in the world.
Right. And Torvalds being Torvalds, he didn't go shopping. He wrote one. In about a week, he had something that could apply patches. Within a few months, the kernel was self-hosting on Git. The key design decisions were all reactions to the BitKeeper crisis and the limitations of existing tools. Distributed — every clone is a full repository with complete history. No central server required. Cryptographic hashing of everything, so you can't tamper with history. And branching and merging that actually worked, unlike Subversion where merging was... let's say an adventure.
I remember Subversion merges. They were the kind of adventure where you packed extra supplies and told your family you might not be back.
The phrase "merge hell" existed for a reason. Git made branching cheap — it was literally just a pointer. You could branch for a single feature, experiment, throw it away, merge it back. That was transformative technically. But Git itself was... not friendly. The command-line interface was famously opaque. The learning curve was steep. Linus's philosophy was basically "the plumbing works; figure out the porcelain yourself."
And this is where our three founders enter. Tom Preston-Werner, Chris Wanstrath, PJ Hyett. Who were they in two thousand seven?
Outsiders to the open source establishment. None of them were kernel developers or GNU project veterans. Preston-Werner was a developer who'd worked at a startup called Powerset, which Microsoft later acquired. Wanstrath was a developer who'd worked at CNET. Hyett was a designer and developer. They were Ruby developers, part of the Ruby on Rails community, which was itself a relatively new and enthusiastic scene.
So they weren't ideological warriors. They weren't coming from the free software movement with manifestos about user freedom. They were pragmatists who wanted to make collaboration easier.
And that pragmatism is central to the whole story. The free software versus open source debates of the nineties were philosophical — Richard Stallman arguing that proprietary software was morally wrong, Eric Raymond arguing that open development produced better code. These were serious, important arguments. GitHub sidestepped them entirely. They didn't argue philosophy. They built something that made sharing code so easy that the philosophy became... optional.
The insight wasn't that version control needed to be better. Git already existed. The insight was that version control needed a social layer.
Yes. And the pull request was the mechanism. Let's get concrete about this. In the old model, if you wanted to contribute to a project, you'd email a patch. The maintainer would review it, maybe apply it, maybe ask for changes, maybe ignore it. There was no record of the conversation, no visibility for anyone else, no way to track the status. The pull request turned that into a structured conversation attached to the code. You fork the repository — make your own copy — make your changes, and then submit a pull request. The maintainer sees the diff, sees your explanation, and can discuss it right there. Other people can see the discussion. The whole thing is public and archived.
And forking. Forking is the part that I think people really don't understand was once considered hostile.
It was. In the old model, forking a project meant taking the code and starting a competing project. It was a vote of no confidence in the original maintainer. It split the community. It was the nuclear option. GitHub reframed forking as a compliment — it meant someone was interested enough in your project to make their own copy and potentially contribute back. The fork became the first step of collaboration, not the last step of a breakup.
That's a complete inversion of meaning. And it happened in, what, a couple of years?
It happened fast. GitHub launched in April two thousand eight. By two thousand ten, the pull request workflow was becoming the standard way open source projects accepted contributions. By two thousand twelve, if you were still asking people to email patches, you looked like a dinosaur.
Let's talk about the timing. Two thousand eight. Facebook was four years old and growing fast. Twitter was two years old. The idea of sharing your life publicly on the internet was being normalized by social networks. GitHub's pitch — "social coding" — landed because the cultural moment was ready for it.
That's a crucial point. GitHub didn't have to convince people that sharing was good. The social networks had already done that work. What GitHub did was apply that model to code. Your profile showed your repositories, your activity, your contributions. You could follow other developers. You could see what they were working on, what they were interested in. It turned coding from a solitary activity into a visible one.
And that visibility changed incentives. Before, you kept your code private because... why would anyone publish half-finished work? It'd be judged. It might be wrong. Someone might steal it. GitHub made publishing the default. New repositories were public unless you paid for private ones. That was a deliberate choice.
Preston-Werner has talked about this. The free plan was public repositories. If you wanted private repos, you paid. That pricing structure encoded a philosophy: code should be public by default. And because the free plan was genuinely useful, developers adopted it. They published their dotfiles, their weekend projects, their experiments. Suddenly there was this massive corpus of public code that anyone could browse, learn from, and contribute to.
The network effect spiral is worth tracing. More public code attracted more developers. More developers created more public code. GitHub became the place where you went to see what existed — if a project wasn't on GitHub, it might as well not exist. And then it became the place where you went to be seen. Your GitHub profile became a portfolio. Companies started hiring based on open source contributions.
The GitHub profile as résumé. That was a genuine shift in how developers built careers. Before, your work was mostly invisible — it happened inside companies, behind firewalls. You couldn't show a prospective employer what you'd built. After GitHub, you could point to actual code, actual collaborations, actual conversations about technical decisions. It changed hiring. It changed how developers thought about their own work. Every commit became a potential career asset.
Which also changed the economics of open source. In the old model, contributing to open source was something you did on nights and weekends, for ideological reasons or personal interest. After GitHub, it was... professional development. Literally. Your open source work was visible to employers. It could get you hired. It could build your reputation in ways that your day job couldn't.
And that fed back into the ecosystem. Companies started encouraging employees to contribute to open source because it was good recruiting. They started open-sourcing their own tools and libraries because it attracted developers. Google, Facebook, Netflix, Amazon — the infrastructure of the modern internet is built on open source, and a lot of that code lives on GitHub.
Let's go back to the founders for a moment, because the story of how they built it is instructive. They were bootstrapped. No venture capital initially. Preston-Werner has said they built GitHub because they wanted to use it themselves. They were Ruby developers who wanted a better way to collaborate on open source projects, and they scratched their own itch.
The first commit to the GitHub repository was in October two thousand seven. Preston-Werner and Wanstrath were working on it nights and weekends. They launched a private beta in January two thousand eight, and the public launch was April tenth. By the end of the first year, they had something like a hundred thousand repositories. It grew fast.
The "social coding" tagline wasn't just marketing. The site was designed around people, not projects. SourceForge organized everything by project — you went to a project page. GitHub organized everything by person — you went to a developer's profile. The unit of organization shifted from the codebase to the coder.
That's the fundamental design insight. SourceForge was a project directory. GitHub was a social network. The profile page showed your activity feed, your repositories, your followers, the organizations you belonged to. It made developers visible to each other as people, not just as email addresses on a mailing list.
And visibility created accountability. If you maintained a project on GitHub, people could see how responsive you were to issues and pull requests. If you ignored contributors for six months, everyone could see that too. The publicness applied social pressure.
Which is a double-edged sword, obviously. Open source maintainer burnout is a real problem, and the visibility of GitHub can make it worse — you can see all the issues piling up, all the pull requests waiting for review. But the core shift was that collaboration became observable. You could learn how good projects were run by watching them. You could see the norms of polite code review, of constructive feedback, of graceful disagreement. The culture was transmitted by example.
So let's trace how open source itself changed. In the nineties, open source — or free software, depending on your terminology — was an ideological movement. The GNU General Public License was a legal weapon designed to enforce software freedom. The debate was about user rights, about the morality of proprietary code, about the ethics of software patents. These were serious people having serious arguments about freedom.
And they weren't wrong. Those arguments mattered. The GPL and the free software movement built the legal and philosophical foundation that open source still rests on. But the movement was also... intense. There were flame wars about licensing. There were purity tests. There was a sense that using proprietary software at all was a moral failing. That intensity kept a lot of developers away.
GitHub didn't argue with any of that. It just made sharing code so easy that the arguments became beside the point. You didn't need to believe in software freedom to put your weekend project on GitHub. You just needed to want to share it.
And the MIT license became the default. Permissive, short, easy to understand. Not the GPL with its copyleft requirements and legal complexity. Just "here's the code, do what you want with it, don't sue me." That pragmatism — use whatever license you want, we're not going to tell you what's right — was very different from the ideological gatekeeping of the earlier era.
It depoliticized open source. For better and for worse, depending on your perspective. The free software advocates would say that depoliticization was a loss — that GitHub made it easy to use open source without caring about the principles behind it. And they're not wrong. But it also made open source the default way the world builds software.
That's the tradeoff. The ideological movement won the argument about whether open source was viable — it clearly is — but lost the argument about whether the ideology was necessary. Most developers on GitHub today have never read the GPL. They've never heard of the four freedoms. They just know that putting your code on GitHub is what you do.
Companies adopted it internally. That's the knock-on effect that I think is underappreciated. GitHub didn't just change open source collaboration. It changed how companies build software internally. The pull request workflow became standard inside organizations. Code review, which used to be something that only happened on mission-critical systems, became routine. The tools and norms that grew up around open source got imported into proprietary development.
Inner source. The idea that you should run your internal development like an open source project — public repositories within the company, pull requests between teams, documentation that anyone can improve. GitHub made that natural because the tools were the same. The workflow you learned contributing to an open source project on nights and weekends was the same workflow you used at work.
Then Microsoft bought it. Twenty eighteen. Seven point five billion dollars. Which was... let's say controversial.
Understatement. Microsoft had spent decades as the villain of the open source story. "Linux is a cancer" — that was Steve Ballmer in two thousand one. The Halloween Documents. The embrace-extend-extinguish strategy. So when Microsoft announced it was acquiring GitHub, there was a lot of... let's call it skepticism.
Some people moved to GitLab. Some moved to self-hosted Gitea instances. There was a minor exodus.
Microsoft didn't ruin GitHub. They put Nat Friedman in charge, kept it running independently, and actually expanded the free tier. Private repositories became free in twenty nineteen. The skepticism faded. It turned out that Satya Nadella's Microsoft wasn't Ballmer's Microsoft.
Which is itself a sign of how much the industry had changed. Microsoft in two thousand one saw open source as an existential threat. Microsoft in twenty eighteen saw GitHub as a strategic asset. The company that once called open source a cancer now owned the platform where most open source was hosted.
The platform kept growing. By twenty twenty-three, GitHub had over a hundred million developers. Over four hundred million repositories. It had become, as Daniel put it, the place where much of the world's software gets built.
Let's pull back to the cultural shift, because that's really what Daniel's asking about. How did ideas that once seemed radical become so ordinary we barely notice them? Publishing your work. Collaborating with strangers. Forking someone's project. Building in public. These were controversial in two thousand five. Now they're background assumptions.
Part of it is the normalization of social media. We got used to sharing our lives publicly. Code was just another thing to share. Part of it is the professional incentives — your GitHub profile became valuable. Part of it is the tooling — Git and GitHub made it so easy that the friction disappeared.
But I think there's something deeper. GitHub changed what it meant to be a developer. Before, you were a developer because you wrote code, usually for an employer, usually in private. After, you were a developer because you had a GitHub profile with activity on it. Your identity as a developer became public and portable. It wasn't tied to your employer. It was tied to your work, visible to everyone.
That's a profound shift. It changed the power dynamic between developers and employers. If your reputation lives on GitHub, you can take it with you. You're not dependent on your current job for your professional identity. That gave developers more leverage — and I think it contributed to the rise of engineering culture in companies. Developers weren't just employees anymore. They were members of a visible profession.
The norms of that profession were shaped by open source culture. Code review. Constructive feedback. Meritocracy of ideas. Transparency. These weren't just open source values — they became engineering values, transmitted through GitHub's social layer.
The pull request review process is a great example. In a traditional corporate environment, code review was often hierarchical — a senior developer reviewed a junior developer's work. In open source, it's more egalitarian — anyone can review anyone's code, and the quality of the feedback matters more than the title of the reviewer. That norm got imported into companies through GitHub.
Before we wrap, Hilbert has been making noises back there — and I suspect he has a confession.
Hilbert: I ran a shareware operation in the late nineties.
Of course you did.
Hilbert: Desktop utilities. Screen savers, disk cleanup tools, that kind of thing. Had about fifteen thousand registered users at the peak. And I maintained the whole thing myself. Code, documentation, support emails, the website. Everything.
What was your version control?
Hilbert: A folder called "backup" with dated zip files. Sometimes I'd email myself a copy. Real professional setup.
That was... not uncommon.
Hilbert: It worked until someone wanted to contribute. I'd get an email with a patch file attached, some guy in Germany who'd fixed a bug in the registration system. And I'd mean to look at it. I really would. But I had support emails to answer and a day job and the patch would sit there.
How long?
Hilbert: Longest was six months. Found it in my spam folder. The guy had already forked the project and released his own version by then. Called it something slightly different. Had a small user base. I was annoyed — at him, at first, which was stupid. He'd done the work. I just hadn't responded.
You were the bottleneck.
Hilbert: I was the bottleneck. And the thing is, I knew I was the bottleneck. I just didn't have a system that forced me to not be the bottleneck. No public issue tracker. No visible pull requests. Nobody could see that I was ignoring things. So I did.
GitHub changed that for you?
Hilbert: I moved the project to GitHub in twenty ten. Not the shareware — that was dead by then. A new thing. A small utility library. And suddenly everything was public. Issues, pull requests, how long I took to respond. People could see. So I responded faster. I didn't want to look like the guy who ignored patches.
The social pressure worked.
Hilbert: Worked perfectly. I hated it. But it worked. I became a more responsive maintainer because I didn't want strangers on the internet to think I was lazy. That's not a technical improvement. That's a social one.
That's the thing about infrastructure — it hides the people who lived through the before.
Hilbert, did you ever reconnect with the German developer? The one whose patch you lost?
Hilbert: He emailed me in twenty fourteen. Said he'd found my new project on GitHub. Asked if I remembered him. I apologized. He said don't worry about it, he'd done the same thing to someone else a few years later. We had a laugh about it. His library's still up. Has about four hundred stars.
That's a happy ending I wasn't expecting.
Hilbert: Most of this stuff ends fine. People adapt. The tools get better. You just have to live through the awkward part first.
The misconception that drives me crazy is that GitHub invented version control. It didn't. Git existed for three years before GitHub launched. What GitHub invented was the social layer — the pull request, the fork as collaboration, the profile as identity. The version control was the plumbing. The social network was the innovation.
The second misconception is that open source was always mainstream. It wasn't. In the nineties and early two thousands, it was associated with ideological movements and specialist communities. GitHub's pragmatism — use whatever license you want, share whatever you want, we're not going to lecture you about freedom — is what made it accessible to developers who just wanted to build things.
The question I keep coming back to is: what's the next GitHub? What's the infrastructure we take for granted now that's actually a radical bet waiting to be normalized? Because the cycle doesn't stop. Every invisible layer of infrastructure was once someone's controversial idea.
The lesson of GitHub isn't really about code. It's about how changing the social layer of a technical system can transform an entire industry's culture. The pull request wasn't a technical breakthrough. It was a social one. And it changed how the world builds software.
If you enjoyed this, leave us a review wherever you listen. And if you have a weird prompt of your own, send it in — show at my weird prompts dot com.
Thanks to Hilbert Flumingtop for producing. This has been My Weird Prompts.
We'll be back soon.
