Being a cofounder of GitHub, I found Greg’s article and Theo’s subsequent commentary fun, but figured that it might be interesting to write up my own take on the reasoning behind the rise and dominance of GitHub and perhaps correct a few things that were not quite right from their outside analysis. 

Being at the very center of phenomena like this can certainly leave you with blind spots, but unlike these youngsters, I was actually there. Hell, I wrote the book.

So here’s an insider’s take on why GitHub won.

If you want a very short read, here is the quick version of why I believe GitHub won and why you’re probably using the site to this day.

I can boil it down to exactly two reasons that happened to resonate with each other at the perfect frequency.

1. GitHub started at the right time
2. GitHub had good taste

All four GitHub cofounders had flops both before and after GitHub. Chris and PJ couldn’t quite make FamSpam work before GitHub, Tom and I couldn’t quite make Chatterbug explode after GitHub. I think both of these ventures had good taste and great product, but it wasn’t the right place or time or market or whatever for them to become GitHub level. 

At the time GitHub was starting, distributed open source version control tools were starting to get useful, solid and adopted and there was nobody around to seriously (much less commercially) host them. Big hosts didn’t care and smaller players weren’t serious.

Furthermore, the players (Sourceforge, Google Code, etc) who eventually did care, after seeing Git and GitHub rising in popularity, simply had no taste. They could never have competed with a developer tools company whose cofounders were all product-focused open source software developers.

We cared about the developer experience and had the creativity to throw away assumptions about what it was supposed to be and build how we wanted to work. Everyone else tried to build what they thought they could sell to advertisers or CTOs.

That’s why GitHub won.

Now that that’s out of the way, if you’re interested in some storytelling, let me lead you down the path of how some of this actually unfolded from the inside.

Let’s go back to the beginning of the story. 

I’ll dig a little more into the “GitHub started at the right time” theme from the point of view of a software developer circa 2005. This is when Git had it’s first commit by Linus and Mercurial had it’s first commit by Olivia.

What was it like to develop software almost 20 years ago and how was this an environment where Git could win over people and a GitHub could be born?

If you were a software developer in 2005, you were probably (hopefully) using a centralized version control system like Subversion. I professionally used RCS, CVS, Subversion and Perforce before Git came along. Hell, I was actually in a company that FTP'd it's PHP files directly to the production server.

Now, if you were working on proprietary commercial software, centralized version control systems like SVN honestly wasn’t the most horrible thing. It was pretty simple to checkout, make changes, check back in. Branching and merging completely sucked but in a lot of situations it could basically be avoided (I’m not sure I ever really used branching in Subversion or Perforce). 

People probably complain more about Git today than they did about SVN back then, to be honest - the user interface and mental model is arguably simpler than in Git.

The big problem that I think started coming to a head around this time was not in the world of professional development within closed, trusted teams. The big problem was within the growing world of open source.

You see, open source was barely a thing before this time, especially compared to today. Most of you kids probably don’t remember a time where there weren’t millions of open source projects around, but the phrase was only coined in 1998. 

To get a sense of scale, Dirk Riehle published a paper in 2008 analyzing global open source project trends and they estimated that there were a total of 18,000 active open source projects in the world at that time - in 2005, certainly far fewer.

To put this in perspective, there are over 280 million public repositories on GitHub alone today.

So, why did open source help usher in the era of Git and GitHub?

Because open source was growing fast and centralized version control systems were particularly bad at open contribution strategies. That is, you couldn’t easily share a project publicly and then take contributions back into it in a simple manner.

Contributing to Open Source in 2005

Really, how bad could it have been?

If you would like to see me talk about what open source contributing was like via my AWS Tokyo keynote 10 years ago, check it out and then you can skip the next few paragraphs:

Basically, you could make your Subversion server read only for unauthenticated users, this is generally how you hosted an open source project (or you put a tarball somewhere occasionally).

If you wanted to contribute, essentially you had to:

• checkout the latest version
• make your changes
• generate a patch file with GNU diff
• upload that patch file to a ticketing system or email list used by the project

Then the maintainer needed to:

• pull down that patch file
• apply it to their project to see if it
  • applied cleanly
  • worked properly
• either submit feedback, make changes, or commit the change

There are still artifacts of this around the internet. I used the Trac project at some point for this type of project, you can still see their Submitting Patches guide and an example of how a change would be suggested. 

It was a goddamn nightmare.

The Rails project, as well as my friends (and future GitHub cofounders) at Err used a similar ticketing system called Lighthouse (which is mind-blowingly still up) and one of my earliest open source projects was a command line tool called git-lighthouse that could simplify the process of pulling down and applying attached patches from tickets you wanted to test out. 

This process sucked enough that when something came around that simplified it, it was quickly embraced. And that something was GitHub. But first, we needed a Git.

The Rise of Git

Git actually started from the fact that Linus Torvalds really liked an (at the time) commercial version control system called BitKeeper. It was actually built specifically to help simplify the existing kernel development process.

If it had been open source or had better licensing terms, there probably would have been no Git or GitHub.

However, what happened instead was that one of the Linux developers reverse engineered the protocol, breaking the licensing terms, and BitKeeper and Linus determined that the spat that followed was untenable and they mutually decided to part ways.

So Linus took some of the concepts that BitKeeper opened his eyes to, threw together the simplest thing he thought would solve his problems with those principles in mind, and called the new project Git, the “information manager from hell”.

It was fairly quickly embraced by several people in the Linux community and slowly grew into an actual, sort of, version control system.

There are several reasons why Git felt awesome at the time. They were:

• branching and merging were dreams rather than nightmares
• it was stupendously fast
• permissions were vastly simpler

In the early days of Git, I would do talks where I would just go on stage, create a few branches, commit changes into them, switch between them and then merge them together, all in 60 seconds. I would literally see peoples jaw’s drop. Some of them would think I was faking the demo.

I just cannot tell you how magical it felt in 2006 to be able to switch and merge contexts that fast and easily. In Subversion this was a total nightmare.

Not having to go over a network to negotiate a commit with a central server was also incredible. It felt like a rocket ship. Everything was so fast.

And probably most importantly, you could fork the repository incredibly easily, which meant that you could host your own copy of a repository and have your own write access and push changes there that other people could pull down into their fork. The Linux project started doing this early on - for larger changes, they could send a request to pull changes from a hosted fork and Linus could very easily do so.

In fact, if you’re wondering where the terminology “Pull Request” came from, this is it. Git has a git request-pull command that would format an email for sending to a mailing list to help make this process simpler. When GitHub added the ability to basically generate this same type of message, we decided that a request to pull should be called a Pull Request. (A little more backstory on that here if you’re curious)

Some people think that developers liked Git because it was distributed and you got the whole history when you cloned, which meant you could share locally, etc. I disagree. I don’t think almost anybody really cared about any of that. Distributed was cool because you could do operations fast and you could host your own full, writeable fork which made permissions much simpler.

It was cool because contributing went from a problem of who had permission to push into the simplicity of who had something interesting to pull.

And of course, this last point led directly to GitHub.

The Rise of GitHub

Late last year, I interviewed my GitHub cofounder Tom, and among the things we discussed, he told the story of how he got the initial idea of working on GitHub.

Essentially, when he was working at Powerset, Tom’s team started using Git internally. However, it was a pain in the ass to add other team members to the internal server, because Git’s main protocol was over SSH, which means you need a user with ssh privileges on the machine. For everyone. It was difficult and, for most of the team, not worth it. This spawned the concept for him of making this process as easy as possible. 

Git is awesome, Git hosting is a pain in the ass. This is why Tom started working on GitHub.

I went through my old emails to see if I could find the first time I heard about Tom’s “GitHub” project, and it was this email from Chris responding to a Git screencast I made in late 2007.

It was still a secret side project between the two of them at that point (also Chris… lower-case ‘h’?) and it’s when I started chatting with Chris and Tom about the Git/Ruby libraries that ran the site, and eventually how I wiggled my way into the project and company.

There are a few interesting things about this pitch. 

The first is that they compared it to the only other real public Git hosting site, repo.or.cz (which also miraculously is still running, if you want to see what the state of Git hosting was pre-GitHub), but made a crucial innovation over that site and every other hosting service like it, which is to make it user-centric rather than project-centric. Before this, if you wanted to host something on Sourceforge or whatever, you needed to grab the name. With GitHub, you can make any project you want named anything you want because it’s namespaced to your user.

The second was that they focused on a pull model rather than a push model (basically the permissions thing I talked about before).

The third is that “not ugly” was a core feature. GitHub had taste.

This is why Git was cool and why GitHub was started to make using it easier, but the question is, why did Git win? Lots of distributed systems sprang up during this time. Mercurial was similar in a lot of ways and better in many. Why did Git come out on top in the great DVCS war?

I think the answer there was “PR”. 

And there are two big PR gorillas fighting it out for the “why did Git win” answer. The first was Linux and by extension, Linus. The other was GitHub, and specifically the Rails community.

Maybe it was Linus/Linux

The Linux project using Git and Linus having started the project gave instant credibility to it.

Everyone knew Linux, everyone knew Linus. If he made an amazing operating system that everyone uses (at least for their servers, next year is the year of Linux on the desktop), he can certainly make a next-level version control system. And even if it’s difficult to use, that just means he’s smarter than us and we should try harder, right?

This video is one of the first talks about Git online, circa 2007. It's Linus talking about Git and distributed version control systems, then a brand new concept, at the Google campus.

It came out in between when I started using Git (late 2005) and when I started at GitHub (mid 2008). I watched it several times, as did millions of people. Who doesn’t like listening to the Linux guy say “CVS is the dumbest shit that has ever been thought of, and everyone who disagrees is ugly and stupid”? At Google! 

It’s just great PR.

Beyond that, if you conflate Linux and Linus, which most people do, there is an argument that Linux itself pushed Git adoption indirectly through Android.

This is where I really don’t know how much impact my own efforts or GitHub’s efforts had compared to this big, quiet, behind-the-scenes side effect of Android becoming a thing at exactly the same time. Or even, my personal impact in either or both of these fronts, doing Git talks and corporate training for years.

In early September 2008, right as Android 1.0 was being released (like 2 weeks after this email, but before I did the training), Shawn Pearce, an early super hero of the Git ecosystem, wrote me this email asking me to help train the Google Android team on Git.

It’s difficult to determine what impact Android had in corporate Git adoption, but it certainly wasn’t zero. While the Google/Android team was the first that I did corporate training for under the GitHub banner, I also eventually did Git training for engineering teams at Motorola, Qualcomm, Ericsson and Broadcom, just to name the telecoms. And that was before we hired a team to do this for us full time.

Linus pushed Git with his broad ranging brand of superstar nerd PR that Mercurial never got, but Android furthermore pushed Git uniquely, via it’s dependance from the Linux kernel, into massive companies out of pure practicality that also otherwise never would have happened for at least another decade.

Maybe it was GitHub

There is also, and I must say this with a grain of hopeful humility, a possibility that GitHub was the determining factor in the eventual dominance of Git over Mercurial.

GitHub had the incredible luck to have an amazingly supportive and hip community that embraced us right out of the gate, namely the Ruby community. Within months, everyone in the Ruby community put their stuff on GitHub. Rails was the hot shit at that time, it was cooler than PHP, JS frameworks weren’t really around, there was no Node, etc. So everyone was paying attention to what the hip cats in the Ruby community were doing, they were the bleeding edge of cool development in the software world. And they were using GitHub.

And it’s not just me, Linus himself also recently said that from his perspective, the Ruby community unexpectedly made Git explode overnight. He doesn’t credit GitHub for that by name, but I think it’s impossible for anyone to argue that the Ruby community didn’t adopt Git in a very large part due to us. 

By the transitive property and some speculation, I’ll make the claim that Linus in fact thinks that GitHub is the reason Git won. 😀

Of course, the Ruby community adopting GitHub wasn’t random. 

I remember all of us - Chris, Tom, PJ and myself - sitting at tables at Ruby conferences with all the guys in the early Ruby community, showing them GitHub, selling them on Git, doing talks, etc. We were all speaking at the same conferences, we all drank beers together after Ruby meetups in SF. These were the guys who started Rails, Heroku, Twitter, jQuery, you name it. 

It’s not that we were selling it, it’s that we were all sharing what we were passionate about. There was a high level of trust in this community, the GitHub founders were a deep and authentic part of it, and we all tried each others stuff and supported each other.

The Ruby community using GitHub meant that every conference talk everywhere had a GitHub plug in it. Free advertising everywhere. This meant that as more and more projects moved to or were started on GitHub, even people who liked Mercurial had no real choice but to use Git. After a while, it probably just wasn’t worth it. GitHub’s dominance in the hosting sphere just crushed Mercurial in just the span of a few years.

In Mercurial land, there was BitBucket, which was started for Mercurial hosting and written in the Django framework, but I think we just had too much of a head start and there wasn’t enough differentiation. The Python community just didn't adopt it as aggressively as our Ruby community did.

As early as December 2008, GitHub was hosting about 27,000 public repositories where BitBucket had a little over 1,000. It became difficult to catch up.

How do I remember those numbers you might ask? Well, I had a website I put up called whygitisbetterthanx.com and this guy named Jesper emailed me to say that one of my points was incorrect, where I argued that Git has GitHub and Mercurial and Bazaar didn't have a GitHub. I rather arrogantly argued that they're not in the same league.

To his credit, he never called me out on my response, which now seems real snippy of me in hindsight. But it turns out that Jesper in fact was the founder of BitBucket. Whoopsie.

A year or so later, we met up with him in Amsterdam, drank some nice whiskey together and have remained friendly ever since.

The Competitive Field Collapses

In the end, whether it was GitHub that helped Git win, or Git that helped GitHub win, it was quickly over. 

In 2006-2007, people were first learning about distributed version control systems and Git and Mercurial were starting to fight it out. 

In 2008, GitHub launched. 

In 2011, both Google Code and BitBucket added Git support, which I’ll mark as the year that the nail was in the Mercurial coffin. Git had won and GitHub was now essentially unbeatable. 

Just 4 years later, in 2015, Google Code just completely gave up and shut it’s service down. In the email they sent out, they basically said “just move to GitHub”. If I remember correctly, they even reached out to us for help with the migration.

Of course, while BitBucket started after us and so we had a head start, there were other hosting sites that existed before us. So why didn’t they win?

In early 2009, Google Code added Mercurial support and Sourceforge added both Git and Mercurial support. So if these industry monsters had a massive user head start and had DVCS support only months after we launched, why didn’t they wipe the floor with us little guys? 

Not only little, but also nearly completely un-funded. Chris was able to put a little bit of money in to bootstrap iirc, but the rest of us were totally broke and we didn't raise any outside funding.

When Google Code launched Mercurial support, we were still 4 developers working out of cafes in South Beach with zero VC investment. We struck deals with our buddies (May 2008) at Engine Yard for help with hosting costs because we didn’t really have the cash.

How is it possible that this tiny, unfunded team made Google Code fold in just a few years?

Side Note: GitHub Funding

As a side note, speaking of funding, the article I’m reacting to states “VC investment wasn't an option for the cofounders.” This is purely untrue. 

From the very first days, we were talking to VCs. When PJ emailed me in July of 2008 to say they wanted me to join them and we should all make the leap, quit our respective jobs, and make this a full time thing instead of a side project, he explicitly said “we've been talking to one VC in particular we like a lot and we want to raise a handful of money to do a few of things.” These were things like get an office, hire some people, etc.

It was always on the table, we could have done it at literally any time. We considered and thoughtfully rejected the idea constantly over the years. We didn't really need an office. We didn't really need more people yet.

Not only that, we actually nearly rejected the idea when we were considering our $100 million A round from Andreessen Horowitz, 4 years later. I remember vividly the night we all sat down for dinner at some restaurant on Folsum St in April of 2012 and argued very heatedly if we should take a capital round at all. 

We basically had offers from a16z, Benchmark, Sequoia and Bessemer (pretty much the best VC firms on the planet) on the table and meanwhile us four assholes sat around and heatedly yelled at each other about whether or not we should tell all of them “thanks, but no thanks”. Offers that other tech entrepreneurs would probably literally have killed for.

But the point is that it wasn’t that we couldn’t have raised money, but that we didn’t even need to in order to take down the entire field.

GitHub Had Taste

The original article is correct, the other hosts focused on distribution and revenue streams. We cared about developers. But it wasn’t about when they added Git, it never really mattered. They never had any taste. They never cared about the developer workflow. They could have added Git at any time and I think they all still would have lost.

You can try to explain it by the features or “value adds”, but the core takeaway that is still relevant to starting a startup today is more fundamental than if we had an activity feed or profile page or whatever. The much simpler, much more fundamentally interesting thing that I think showed in everything that we did was that we built for ourselves. We had taste. We cared about the experience.

We were developers and we built what we wanted in order to enable how we wanted to ideally work. We were the only tool in the space built by developers for developers without PMs or accountants or CEOs trying to optimize for revenue rather than for developer experience.

In the end we won because the open source community started to converge on distributed version control and we were the only ones in the hosting space that truly cared about how developers worked at all. The only ones who questioned it, approached it from first principles, tried to make it better holistically rather than just throwing more features onto something existing in order to sell it.

So, to sum up, we won because we started at the right time and we had taste. 

We were there when a new paradigm was being born and we approached the problem of helping people embrace that new paradigm with a developer experience centric approach that nobody else had the capacity for or interest in.

I guess the question is, what is the next sea change in developer workflow, and who will have good enough taste to make it explode in the same way?