Why GitHub Won
GitHub's success stems from its timely launch during the rise of distributed version control, prioritizing user experience, simplifying collaboration for open-source projects, and leveraging the cofounders' open-source expertise.
Read original articleGitHub's rise to dominance in the code hosting space can be attributed to two main factors: timing and a focus on user experience. The platform emerged when distributed version control systems, particularly Git, were gaining traction, yet there was a lack of serious hosting options. Existing platforms like SourceForge and Google Code failed to meet the needs of developers, primarily because they lacked a user-centric approach and good design. The GitHub cofounders, all experienced in open-source software, prioritized the developer experience, creating a platform that was not only functional but also aesthetically pleasing.
GitHub simplified the contribution process for open-source projects, which was cumbersome with traditional centralized systems. By allowing easy forking and pull requests, GitHub made it easier for developers to collaborate. The platform's design and functionality resonated with the growing open-source community, leading to its widespread adoption. GitHub's success is a testament to the importance of timing and user-focused design in the tech industry.
- GitHub's success is largely due to its launch at a time when distributed version control was becoming popular.
- The platform prioritized user experience and aesthetics, setting it apart from competitors.
- GitHub simplified the contribution process for open-source projects, making collaboration easier.
- The cofounders' background in open-source software influenced GitHub's design and functionality.
- GitHub's focus on a pull model rather than a push model enhanced its appeal to developers.
Related
"GitHub" Is Starting to Feel Like Legacy Software
GitHub faces criticism for performance decline and feature issues like blame view rendering large files. Users find navigation challenging and core features neglected despite modernization efforts. Users consider exploring alternative platforms.
Mercurial is simply too good (2020)
Mercurial, a user-friendly version control system created as an alternative to git, offers intuitive commands and safeguards. Despite losing popularity, it sees a resurgence with companies like Facebook adopting it.
GitHub Actions Outage
GitHub is facing issues with actions and jobs, working to resolve by failing over to another region. Users can subscribe for updates via email, text, Slack, or webhook notifications for ongoing incident information.
Number of incidents affecting GitHub, Bitbucket, Gitlab and Jira is rising
Incidents on major development platforms like GitHub, Bitbucket, GitLab, and Jira are rising, with GitHub up 21% in 2023, highlighting security challenges and the need for better collaboration in DevSecOps.
PSA: Eget That Executable from GitHub
The blog post discusses the challenges of downloading binaries from GitHub and introduces "eget," a command-line tool that simplifies this process while addressing security and API limitations.
- Many attribute GitHub's success to its user-friendly interface and superior user experience compared to competitors like SourceForge and Bitbucket.
- Several commenters emphasize the importance of timing, noting that GitHub capitalized on the growing popularity of Git as a version control system.
- There is a recurring theme of "taste" in product design, with some arguing that GitHub's aesthetic and community engagement set it apart.
- Critiques of GitHub include concerns about its proprietary nature and the implications of its acquisition by Microsoft.
- Some commenters express nostalgia for earlier systems like Subversion and highlight the complexities introduced by Git, suggesting that not all users find it intuitive.
It was simply trying to prevent SF from becoming a shitty monoculture that hurt everyone, which it was when Google Code launched. Google was 100% consistent on this from the day it launched to the day it folded. It was not trying to make money, or whatever
I was there, working on it, when it was 4 of us :)
So to write all these funny things about taste or what not, is totally besides the point.
We folded it up because we achieved the goal we sought at the time, and didn't see a reason to continue.
People could get a good experience with the competition that now existed, and we would have just ended up cannibalizing the market.
So we chose to exit, and worked with Github/bitbucket/others to provide migration tools.
All of this would have been easy to find out simply by asking, but it appears nobody bothers to actually ask other people things anymore, and I guess that doesn't make as good a story as "we totally destroyed them because they had no taste, so they up and folded".
https://news.ycombinator.com/item?id=31110206
This articles about the open source distribution side but I will also point out that the number of developers who don’t realise your remote GitHub repo can be located on any machine with an ssh connection and nothing more is surprising. As in people use private GitHub repos thinking that’s THE way you work with git. If GitHub was just for open source hosting I suspect they’d have trouble monetising like sourceforge clearly did which led to scammy attempts to make money. But they always had this huge usage of private GitHub repos supporting the rest. This must have helped a lot imho.
Tangentially: it's a pretty sad state of affairs when the most popular OSS hosting service is not only proprietary, but owned by the company who was historically at opposite ends of the OSS movement. A cynic might say that they're at the extend phase of "embrace, extend, extinguish". Though "extinguish" might not be necessary if it can be replaced by "profit" instead.
Git took the early lead and never looked back. And GitHub's competitors were too slow to embrace Git. So GitHub dominated developer mindshare.
It seems strange now but there was a period of time during the late 00s and early 10s when developers were pretty passionate about their choice of DVCS.
In 2007 I was teaching myself programming and had just started using my first version control tools with Mercurial/Hg after reading Joel Spolky's blog post/love letter to Mercurial. A year or two later I'd go to user group meetups and hear many echo my praise for Hg but lamenting that all the cool projects were in GitHub (and not bitbucket). One by one nearly everyone migrated their projects over to git almost entirely because of the activity at GitHub. I even taught myself git using Scott's website and book at that point!
"Product-market fit" is the MBA name for this now. As Scott elegantly states this is mostly knowing what problem you solve, for whom, and great timing, but it was the "flavor" of the site and community (combined with the clout of linux/android using git) that probably won the hearts and minds and really made it fit with this new market.
Edit: It didn't hurt that this was all happening at the convergence of the transition to cloud computing (particularly Heroku/AWS), "Web 2.0"/public APIs, and a millennial generational wave in college/first jobs-- but that kinda gets covered in the "Timing, plus SourceForge sucked" points
Just people/products that are temporarily on top.
SourceForge was probably "the winner" for some time.
The same will be for GitHub.
Someone just needs to build an actual superior product and provide a service that GitHub will not provide. Then build a sufficient audience.
One such service is an end to end encrypted Git repo service.
Some anarchists I know don't want everyone to know what they are working on.
The same goes for algorithmic trading. I need strong guarantees that my code will not be used to train an LLM that will leak my edge.
I am shocked a superior Git service to GitHub has not been built.
I really liked source hut. But the custodian is abit arrogant (crypto projects for instance are banned)
One of my biggest gripes was that switching back and forth between code view and editor mode would wipe whatever you had written. So you better had them in separate tabs. Also be sure not to press the backspace key outside a text window.
It's tricky, because any serious Github competitor would implicitly have to compete by attracting the deep pockets of enterprise clients, who care little for "fun". Getting revenue from solo devs / small teams is an uphill battle, especially if you feel obliged to make your platform open source.
Still, I wish someone would make a Github competitor that's fun and social.
I feel the same way about tscircuit (my current startup), it's a weird bet to create circuit boards with web technologies, nobody really does it, but the ergonomics _feel better_, and I just have to trust my taste!
The "taste" thing is weird, making an analogy with Apple vs. Microsoft, who explicitly competed at many times
As DannyBee said, there was never any Google vs. Github competition, because Google's intention was never to build something like Github
In fact, one thing he didn't mention is that URL, as I recall, was
code.google.com/hosting/
not code.google.com/ # this was something ELSE, developer API docs for maps, etc.
SPECIFICALLY because management didn't want anyone to think it was a product. It was a place to put Google's own open source projects, and an alternative to SourceForge. (There was also this idea of discouraging odd or non-OSS licenses, which was maybe misguided)That is, the whole project didn't even deserve its own Google subdomain !!! (according to management)
(I worked on Google Code for around 18 months)
---
However if I try to "steel man" the argument, it's absolutely true that we didn't use it ourselves. The "normal" Google tools were used to build Google Code, and we did remark upon that at the time: we don't dogfood it, and dogfooding gives you a better product
But it was a non-starter for reasons that have to do with Google's developer and server infrastructure (and IMO are related to why Google had a hard time iterating on new products in general)
I think also think Github did a lot of hard work on the front end, and Google famously does not have a strong front end culture (IMO because complex front ends weren't necessary for the original breakout product of search, unlike say Facebook)
The first reason was why Git became interesting, the second one is why it won.
Prior to Github the way to contribute to OSS projects was a protracted process of engaging with very busy people via mailing lists, issue trackers, and what not and jumping through a lot of hoops to get your patches considered, scrutinized, and maybe merged. If you got good at this, you might eventually earn commit privileges against some remote, centralized repository. This actively discouraged committing stuff. OSS was somewhat elitist. Most programmers never contributed a single line of OSS code or even considered doing so.
Github changed all that. You could trivially fork any project and start tinkering with it. And then you could contribute your changes back with a simple button push: create pull request. It actively encouraged the notion. And lots of people did.
Github enabled a bunch of kids that were into Ruby to rapidly scale a huge OSS community that otherwise would not have existed. That success was later replicated by the Javascript community; which pretty much bootstrapped on Github as well. What did those two communities have in common: young people who were mostly not that sophisticated with their command line tooling. This crowd was never going to be exchanging patches via some mailing list, like the Linux crowd still does today. But they could fork and create pull requests. And they did. Both communities had a wild growth of projects. And some of them got big.
Github gave them a platform to share code so they all used it. And the rest is just exponential growth. Github rapidly became the one place to share code. Even projects with their own repositories got forked there. Because it was just easier. A lot of those projects eventually gave up on their own central infrastructure. Accepting contributions via Github was easier. In 2005 Git was new and obscure; very elitist. In 2008 Github popped up. By 2012 it hosted most of the OSS community. Game over by around 2010 I would guestimate. By 2015 even the most conservative shops were either using it or considering it at least.
Man, given how terrible GitHub's developer workflow is in 2024... there is still no first-class support for stacked diffs, something that Phabricator had a decade ago and mailing list workflows have been doing for a very long time.
I personally treat GH as a system that has to be hacked around with tools like spr [1], not a paragon of good developer workflows.
[1] my fork with Jujutsu support: https://github.com/sunshowers/spr
People in the field less than 20 years might not appreciate the magnitude of this change (though, adding my two cents to the author's article, branching in p4 was fine). People may have also dealt with ClearCase (vobs!) or Microsoft Visual SourceSafe.
Git did as much for software development velocity as any other development in recent history.
I always wonder what would have happened if we had a dedicated team to make something of it, but in the end git won over hg anyway so likely a moot point.
Edit: there's a low-quality video of the early interface we worked on - https://youtu.be/NARcsoPp4F8
Tridge never accepted the license terms of BitKeeper and re-implemented client libraries only by observing black box behaviour of the server, so at no point did he break the terms of the license. He also told Linus what he was doing and asked, "how do you think [Larry McVoy] will react?". Linus said he thought it would be okay.
The main reason I hear people say they use GitHub is due to network effect. "It's what everyone else is using", "You'll get more visibility and more contributions" or "My employer forces us to use it".
Essentially, the same reasons why Windows is a popular platform; not really technical reasons, mostly business and ecosystem factors driving people towards it.
Sure, GitHub was* better than the alternative in its initial days. But things have changed in the last decade. GH has continuously declined while alternatives have surfaced and improved dramatically.
Personally, it pisses me that GitHub presents itself as "an open source hub", when it is a proprietary, hosted, service.
Becoming a jewel for (one of) the worlds most profitable proprietary software and platform company.
And GitHub is still super popular, evolving more and more into a social network. where the users work for free to increase the value of platform and promote it for the chance at more GitHub stars.
With the common echo chamber: "" Windows is bad, eww proprietary bloated spy software and evil Office. Opensource and Linux is goood. "" and then
"I have 3000 stars on GitHub now, check out my repos."
Did Microsoft predict the value having trivial access to all those codebases for training software models?
The kind of insight they have with Microsoft GitHub and Microsoft LinkedIn is quite something.
¹ In stock
This is my own opinion:
- GitHub looks nice but PR merge window between forks is still bad
- GitLab CI is so much more intuitive than GitHub CI and there is a lot of existing codes that you can copy/paste specially if you use Terraform, AWS, K8S
- I am biased, but AzDevops both looks most intuitive, and its pipeline system is the best
Whenever I’ve asked for help using GitHub (usually because I’m getting back into coding) the dev helping me out stumbles, forgets, and is confused often. What’s surprising is that’s true no matter how senior they are.
GitHub did a ton to smooth out dev workflows, for sure, but there’s something almost intensely counter-intuitive about how it works and how easy it is to miss a step.
I’d assume good product taste is reasonably indexed to “intuitive to use” but GitHub doesn’t seem to achieve that bar.
What’s an example of GitHub’s good taste that I’m missing?
There are ancient threads about it on their issue tracker, that go nowhere for years and years. It's almost as if they were trying to sabotage themselves.
SEO was hugely important because when you searched for something Github projects actually came up in Google, gitlab.com did not. Even if there was an interesting project there, it wouldn't have been known.
So I'm not surprised Github became synonymous with Git forge online.
I introduced Subversion at my first job, we were sharing updates over FTP and heavily coordinating who worked on what before.
Subversion was definitely a step up, but branching/merging was very problematic and time consuming.
I still find Git confusing as hell sometimes, and would guess most developers use like 50% of the features tops; without GitHub or something similar it wouldn't have gone anywhere.
are (along with too many other projects) from way before Nov 1993, where "The Total Growth of Open Source" graph starts from 0.
That left a market opportunity for something better. I think that _might_ have had something to do with it.
2012, https://a16z.com/announcement/github/
We just invested $100M in GitHub. In addition to the eye-popping number, the investment breaks ground on two fronts:
It’s the largest investment we’ve ever made.
It’s the only outside investment GitHub has ever taken.
2018, https://web.archive.org/web/20180604134945/https://a16z.com/... Six years ago we invested an “eye-popping” $100 million into GitHub. This was not only a Series A investment and the first institutional money ever raised by the company, but it was also the largest single check we had ever written.. At the time, it had over 3 million Git repositories — a nearly invincible position.. if I ever have to choose between a group of professional business managers or a talented group of passionate developers with amazing product-market fit like GitHub, I am investing in GitHub every time.
Though fortunately was compatible and natively convertible to git and made the git takeover mostly smoothless.
At the time it felt that github and the rapid tooling and integrations developed in response cemented git's rise and downfall of everything else including darcs.
Since then I'm happy self hosting Gitea. GitHub is still a decent place to contribute to others projects.
They also provided a set of links to LWN articles from that era.
So, a downfall of a potential alternative was also a factor IMO.
Edit: after I commented I realized that SF was already mentioned in other comment
Though I wonder if bit bucket would win if they had githubs name
For a counter-point (which I've made many times before) from 2005 to 2012 we used Subversion. The important thing about Subversion was that it was fun to use, and it was simple, so everyone in the organization enjoyed using it: the graphic designers, the product visionaries, the financial controllers, the operations people, the artists and musicians, the CEO, the CMO, etc. And we threw everything into Subversion: docs about marketing, rough drafts of advertising copy, new artwork, new design ideas, todo lists, software code, etc.
The whole company lived in Subversion and Subversion unified every part of the company. Indeed, many products that grew up later, after 2010 and especially after 2014, grew up because companies turned away from Subversion. Google Sheets became a common way to share spreadsheets, but Google Sheets wasn't necessary back when all spreadsheets lived in Subversion and everyone in the company used Subversion. Likewise, Google Docs. Likewise some design tools. Arguably stuff like Miro would now have a smaller market niche if companies still used Subversion.
At some point between 2008 and 2015 most companies switched over to git. The thing about git is that it is complex and therefore only software engineers can use it. Using git shattered the idea of having a central version control for everything in the company.
Software engineers made several arguments in favor of git.
A somewhat silly argument was that software developers, at corporations, needed the ability to do decentralized development. I'm sure this actually happens somewhere, but I have not seen it. At every company that I've worked, the code is as centralized as it was when we used Subversion.
A stronger argument in favor of git was that branches were expensive in Subversion but cheap in git. I believe this is the main reason that software developers preferred git over Subversion. For my part, during the years that we used Subversion, we almost never used branches, mostly we just developed separate code and then merged it back to main. Our devops guy typically ran 20 or 30 test servers for us, so we could test our changes on some machine that we "owned". For work that would take several weeks, before being merged back to main, we sometimes did setup a branch, and other times we created a new Subversion repo. Starting new repos was reasonably cheap and easy with Subversion, so that was one way to go when some work would take weeks or months of effort. But as ever, with any version control system, merge conflicts become more serious the longer you are away from the main branch, so we tried to avoid the kind of side projects that would take several weeks. Instead, we thought carefully about how to do such work in smaller batches, or how to spin off the work into a separate app, with its own repo.
A few times we had a side project that lasted several months and so we would save it (every day, once a day) to the main branch in Subversion, just to have it in Subversion, and then we would immediately save the "real" main branch as the next version, so it was as if the main branch was still the same main branch as before, unchanged, but in-between versions 984 and 986 there was a version 985 that had the other project that was being worked on. This also worked for us perfectly well.
The point is that the system worked reasonably well, and we built fairly complex software. We also deployed changes several times a day, something which is till rare now, in 2024, at most companies, despite extravagant investments in complex devops setups. I read a study last week that suggested only 18% of companies could deploy multiple times a day. But we were doing that back in 2009.
The non-technical people, the artists and product visionaries and CFOs and and CMOs, would often use folders, when they wanted to track variations of an idea. That was one of the advantages of having something as simple as Subversion: the whole team could work with idioms that they understood. Folders will always be popular with non-technical people.
But software developers preferred git, and they made the argument that they needed cheap branches, needed to run the software in whole, locally on their machines, with multiple variations and easy switching between branches, and needed a smooth path through the CI/CD tools towards deployment to production.
I've two criticisms with this argument:
1. software developers never took seriously how much they were damaging the companies they worked for when they ended the era of unified version control.
2. When using Subversion, we still had reasonably good systems for deployment. For awhile we used Capistrano scripts, and later (after 2010) I wrote some custom deployment code in Jenkins. The whole system could be made to work and it was much simpler than most CI/CD systems that I see now. Simplicity had benefits. In particular, it was possible to hire a junior level engineer and within 6 months have them understand the whole system. That is no longer possible, as devops has become complex, and has evolved into its own specialty. And while there are certainly a few large companies that need the complexity of modern devops, I've seen very few cases myself. I mostly see just the opposite: small startups that get overwhelmed with the cost of implementing modern devops "best practices", small startups that would benefit if they went back to the simplicity that we had 10 to 15 years ago.
> How GitHub _actually_ became the dominant force it is today, from one of it's cofounders.
> 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.
Downvote all you want for being “non-substantive” but for some reason I can’t voluntarily tolerate such a density of well-actually phrasing. It’s grating.
It also seems to be everywhere these days but maybe I’m too attuned to it.
It's not the first thing to be carried by hype instead of careful comparison.
Related
"GitHub" Is Starting to Feel Like Legacy Software
GitHub faces criticism for performance decline and feature issues like blame view rendering large files. Users find navigation challenging and core features neglected despite modernization efforts. Users consider exploring alternative platforms.
Mercurial is simply too good (2020)
Mercurial, a user-friendly version control system created as an alternative to git, offers intuitive commands and safeguards. Despite losing popularity, it sees a resurgence with companies like Facebook adopting it.
GitHub Actions Outage
GitHub is facing issues with actions and jobs, working to resolve by failing over to another region. Users can subscribe for updates via email, text, Slack, or webhook notifications for ongoing incident information.
Number of incidents affecting GitHub, Bitbucket, Gitlab and Jira is rising
Incidents on major development platforms like GitHub, Bitbucket, GitLab, and Jira are rising, with GitHub up 21% in 2023, highlighting security challenges and the need for better collaboration in DevSecOps.
PSA: Eget That Executable from GitHub
The blog post discusses the challenges of downloading binaries from GitHub and introduces "eget," a command-line tool that simplifies this process while addressing security and API limitations.