The Social Network for Code

Three Developers in a Sports Bar

Late two thousand seven. Two Ruby developers sitting in a San Francisco sports bar called Zeke's, sketching on napkins after an "I Can Has Ruby" meetup, realize they might be onto something big. A few months later, a third joins them, and together they're about to change how software gets built.

Tom Preston-Werner, Chris Wanstrath, and PJ Hyett didn't set out to create GitHub. They just wanted to make it easier to share Git repositories. But in doing so, they accidentally invented social coding, transformed open source, and built a company that Microsoft would buy for seven and a half billion dollars.

This is the story of how Git went from Linus's command-line tool to the foundation of modern software development. And it starts with a simple observation: Git was too hard.

Tom's Blog Post

By two thousand eight, Git was already winning. The Linux kernel used it. Large open source projects were adopting it. Developers who tried it usually preferred it to Subversion.

But there was a catch. Git's learning curve was brutal.

Linus had built Git for kernel developers, people comfortable with complex command-line tools, willing to understand the internals, okay with reading man pages. For everyone else? Git was intimidating.

Want to share your code? You needed to set up SSH keys, configure a Git daemon, or use a Perl script called GitWeb that looked like it was designed in nineteen ninety-seven. Want to collaborate? Figure out email patches or give people shell access to your server.

The tools existed, but the friction was immense. Open source projects were on SourceForge, which had CVS and Subversion support but no Git. Setting up public Git hosting meant running your own server.

Tom Preston-Werner, already known in the Ruby community for creating Jekyll, got frustrated with this. He wanted to contribute to open source projects, but just getting access was a pain. He wanted to host his own projects, but running a server was overkill.

He wrote a blog post describing his vision: dead-simple Git hosting, social features around code, friction-free collaboration. The idea resonated, but Tom wasn't planning to build it himself.

Then he met Chris Wanstrath at a San Francisco Ruby meetup.

The Problem with Sharing Git

Chris Wanstrath was working at CNET, also frustrated with Git's collaboration problem. He'd built some internal tools for making Git more accessible. When Tom mentioned his blog post, they both realized they were thinking about the same problem.

They started talking. And they kept talking. And eventually, they found themselves in a sports bar with PJ Hyett, another Ruby developer frustrated with the same things, sketching ideas on napkins.

The core concept was simple. Make Git hosting trivial. Sign up, create a repository, push code. No server configuration, no SSH key gymnastics, no ugly web interfaces. Just Git that works.

Some sort of website that acted as a hub for coders to share their Git repositories. I even had a name: GitHub.

Preston-Werner had the vision and the name. But they added one crucial insight: make it social.

Think about it. SourceForge and Google Code, the dominant platforms then, treated code hosting as a technical problem. You upload files, maybe track bugs, done. They were digital filing cabinets.

But code is created by people. Projects have communities. Development is social. So why not make the platform social?

They sketched out features. Follow other developers. Watch repositories. Activity feeds. User profiles showcasing your code. Fork with one click. Browse anyone's code instantly.

This was radical. At the time, the prevailing wisdom was that open source needed barriers to entry. You had to request access, prove yourself, join mailing lists. GitHub said no. Let anyone fork anything. Let people contribute without asking permission. Lower the barriers to zero.

They started coding that night. Ruby on Rails, naturally. By mid-January two thousand eight, they had a private beta. By April, GitHub was open to the public.

The growth was immediate and explosive.

The Fork Button

The killer feature, the one that changed everything, was the fork button.

In traditional open source, contributing to a project meant requesting access from maintainers, waiting for approval, getting commit rights, and only then could you contribute. Or, if you didn't get commit rights, you'd download the code, make changes locally, generate a patch file, email it to a mailing list, hope someone reviews it, watch the mailing list for feedback, and repeat.

GitHub collapsed all of that into three steps. Fork. Change. Propose.

That's it. You could contribute to any public project without asking permission. You didn't need commit rights. You didn't need to email patches. You just forked, changed, and proposed your changes.

The fork button did something subtle but powerful. It removed gatekeepers from the first step. You could try contributing without anyone's approval. If maintainers rejected your pull request, fine, but they had to actively reject it. The default shifted from "no access unless approved" to "anyone can propose changes."

This changed the economics of contribution. Lowering friction increases participation. GitHub didn't invent forking. Git itself made that easy with git clone, which gives you a complete copy of any repository. But GitHub made forking visible, social, and one-click simple. Suddenly, open source projects that had been maintained by small, closed groups found themselves receiving contributions from strangers worldwide. The barrier to entry collapsed.

Pull Requests and the Collaboration Layer

The fork button got attention, but pull requests became the foundation of modern development.

A pull request is a simple idea. "I made changes on my fork. Want to merge them?" But GitHub's implementation added crucial features. Inline code review, where you could comment on specific lines and discuss changes contextually. Status checks, where automated tests run on every proposal and you could see immediately if changes break anything. Threaded discussions, where teams could debate approaches, ask questions, and iterate on ideas, all attached to the code itself.

Pull requests became more than a technical mechanism. They became the collaboration layer. The place where new contributors propose changes, experienced developers review and mentor, architectural decisions get debated, knowledge gets shared, and communities form.

By two thousand ten, "open a PR" was standard vocabulary. Projects organized around pull requests. Workflows developed around them. Continuous integration tools integrated with them. The entire modern software development process crystallized around GitHub's pull request model.

And here's the thing. None of this was Git. Git has no concept of pull requests. GitHub built them on top of Git. They turned a version control tool into a collaboration platform. What git push and git pull do, sending and receiving commits between repositories, is the plumbing. GitHub built the social layer on top of that plumbing.

Public Free, Private Paid

GitHub started as a side project. Tom, Chris, and PJ were doing it nights and weekends. They incorporated in two thousand eight but didn't quit their jobs initially.

Neither Chris nor I were in any particular hurry for this to happen. I was working full time at Powerset, and he was making good money as a Rails consultant.

The question everyone asked: how will you make money?

Open source projects demanded free hosting. Developers expected free accounts. SourceForge was free. Google Code was free. Why would anyone pay?

GitHub's answer was elegantly simple. Public repositories free, private repositories paid. Open source developers get unlimited free hosting. Companies that want private repositories, to protect proprietary code, develop in secret, control access, pay monthly per user. Both sides get what they want.

This aligned incentives perfectly. GitHub wanted to maximize open source usage for network effects, so making that free was smart. Companies had budgets and needed privacy, so charging them made sense.

We bootstrapped the company on a few thousand dollars and became profitable the day we opened to the public and started charging for subscriptions.

Preston-Werner was not exaggerating. By late two thousand eight, GitHub had paying customers. By two thousand nine, the founders quit their day jobs. By two thousand ten, they were profitable. By two thousand twelve, they raised a hundred million dollars in funding.

The pricing model worked so well that it became the standard for developer tools. Offer a generous free tier for individuals and open source, charge for teams and enterprises, add premium features at higher tiers. Stripe, Vercel, Heroku, everyone copied this model.

GitHub proved you could build a sustainable business on top of open source without compromising the open source community. That was genuinely new.

The Network Effect Kicks In

GitHub's growth wasn't linear. It was exponential.

In two thousand eight, there were a few thousand repositories. By two thousand ten, over a million. By two thousand thirteen, over ten million. By two thousand twenty, over a hundred million.

Why? Network effects. If you're a developer looking for open source libraries, you search GitHub. If you're maintaining an open source project, you host on GitHub. If you're hiring developers, you check their GitHub profiles. If you're a developer building a portfolio, you showcase GitHub contributions.

Each of these behaviors reinforces the others. More projects on GitHub means more developers on GitHub means more activity means more projects. The flywheel spins faster and faster.

By two thousand twelve, "show me your GitHub" had become a standard interview request. By two thousand fifteen, GitHub profiles were effectively resumes. By two thousand eighteen, not having a GitHub presence made you look suspect as a developer.

Code as Performance

The "GitHub resume" phenomenon meant your social capital as a developer became visible and quantifiable. Stars, followers, contribution graphs, these became status markers. Some people loved it. Others found it toxic.

The meritocracy myth was strong on GitHub. "Code speaks for itself," people said. But does it? Research showed women and minorities got harsher code reviews, fewer merged pull requests, more aggressive comments. The public, performative nature of GitHub exposed and sometimes amplified bias.

Should your unpaid hobby work be judged as professional credentials? Should employers expect to see your personal projects? The "GitHub resume" debate raged for years and still simmers today.

GitHub tried to address the darker side. They added Code of Conduct templates. They built moderation tools. They cracked down on harassment. But the tension persisted: how do you build a social platform that's welcoming while preserving the open, transparent nature that makes it work?

Meanwhile, security became a concern. Public repositories meant public vulnerabilities. Leaked credentials, exposed API keys, accidentally committed secrets, these became epidemic. GitHub added secret scanning, but the damage was often done by the time they caught it.

Code was now performative. You programmed in public, for an audience. Open source became as much about reputation and community as about software. GitHub became the social network for developers. Not LinkedIn. Not Twitter. GitHub. Where your identity was defined by your code, your contributions, your project stars.

The Platform Eats the Commons

By two thousand eighteen, GitHub faced an identity crisis. It had grown from a scrappy startup to infrastructure for the entire software world. And then came the announcement that shook the developer community to its core. On June fourth, two thousand eighteen, Microsoft said it was acquiring GitHub for seven and a half billion dollars.

Microsoft. The company that called Linux a "cancer." The company that fought open source for decades. That Microsoft.

The developer community panicked. Some immediately migrated to GitLab. Others created accounts on smaller platforms. The exodus was real, if not massive. Trust takes time, and many developers remembered the old Microsoft.

But that's a story for the next episode.

What matters here is what GitHub had already become by the time Microsoft came knocking. It wasn't just a hosting platform anymore. It was where most of the world's code lived, where open source was governed, where developers built their professional identities, where companies recruited, where the collaboration patterns of an entire industry were defined.

Git is distributed by design. Every clone is complete. There is no central server in Git's architecture. But our usage is centralized. Everyone has full copies of their repositories, but we all treat GitHub as the source of truth. The technology enables decentralization. The social layer demands centralization.

From three people in a sports bar to the foundation of modern software development. GitHub took Git from a tool for experts to a platform for everyone. They made collaboration trivial, open source accessible, and code social. Whether that concentration of power in a single platform is a gift or a danger is the question the rest of this story has to answer.

Not bad for a side project.

git push. Two words that send your work from the kingdom on your desk to the rest of the world. Everything we talked about in Episode Six, every clone being complete, every repository being independent, that stays true. But git push is the moment you choose to share. It is the bridge between distributed and social, between the architecture Linus built and the platform three developers in a sports bar built on top of it.