HN

Comments (448)

• Menu

  DannyBee
  Actually, Google Code was never trying to win.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 whateverI 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".
• Menu

  AnotherGoodName
  Well Sourceforge literally bundled malware for a while. So everyone had to move.https://news.ycombinator.com/item?id=31110206This 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.
• Menu

  imiric
  The celebrity of Linus definitely helped Git win, and GitHub likely benefited from that by the name alone. Many people today mistakenly equate Git and GitHub, and since GH did such a good job of being a friendly interface to Git, to many people it _is_ Git. They did an early bet on Git alone, at a time when many of its competitors were supporting several VCSs. That early traction set the ball rolling, and now everyone developing in public pretty much has to be on it.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.
• Menu

  nerdix
  GitHub won because Git won. It was obvious by the late 00s that some DVCS was going to upend subversion (and more niche VCS like TFS). It ended up a two horse race between Git and Mercurial. GitHub bet on Git. Bitbucket bet on Mercurial.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.
• Menu

  ldayley
  Thank you for sharing this, Scott! He mentions "Taste" throughout the post and this intangible quality makes all the difference in an early-stage winner-take-all market dominance race.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
• Menu

  max_
  There is no real winners in business.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)
• jillesvangurp
  I think the analysis is largely correct. But not entirely. My take on this is that 1) Github fixed the one problem that Git had: terrible UX. Github made it more like subversion. Enough so to consider switching. Indeed a lot of small companies treat it like a central repository with commit rights for everyone. 2) It fixed a big problem OSS projects had: it was very hard to contribute to them.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.
• Menu

  SenHeng
  I used both GitHub and BitBucket during the early days. There was no comparison. GitHub was simply nice to use. The UX was phenomenal for its time and made sense. BitBucket was horrible but my then employer wouldn’t pay for hosting and GitHub didn’t provide free private hosting.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.
• trelane
  LWN linked to a summary of the origin of git: https://lwn.net/Articles/974914/They also provided a set of links to LWN articles from that era.
• Menu

  teqsun
  As a "younger" programmer it always shocks me how things like git were only created in 2005. It feels so ubiquitous and the way it functions has the "feeling" of something created in the 80s or 90s to me.
• Menu

  Bjorkbat
  The idea of Github having a unique "taste" advantage resonates with me a lot. I don't like the fact that Github is using my code to feed Microsoft's AI ambitions, but I dislike Bitbucket and Gitlab more simply on the grounds that they "don't look fun".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.
• chubot
  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.The "taste" thing is weird, making an analogy with Apple vs. Microsoft, who explicitly competed at many timesAs DannyBee said, there was never any Google vs. Github competition, because Google's intention was never to build something like GithubIn 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 productBut 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)
• gsliepen
  Another big advantage of Git for sites like GitHub is that you are never putting your eggs into one basket. You have your local copy of all history in a project. GitHub is merely a mirror. Sure, some features have been sprinkled on top like pull requests and an issue tracker, but those are not the most critical part. If GitHub goes down you can move your whole Git history to another site like GitLab, sourcehut, or just self-host it, or you can even start doing it right now with minimal effort. This was never the case with CVS and Subversion.
• Menu

  seveibar
  This article reinforces a lot of my biases around early bets. Taste is so so important, everyone looks at you weird when you say you're betting on "niche, tasteful solution" (git) instead of "common, gross solution" (SVN). Github bet on Git and made tasteful choices, and that was a huge propellant for them.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!
• Menu

  cromulent
  The guy who reverse-engineered the Bitkeeper protocol, triggering the creation of git, is the same guy who created rsync - Andrew Tridgell.
• thom
  I wonder if there's an alternative universe where Fog Creek pushed Kiln - their hosted Mercurial product - harder and exploited the mindshare of Stack Overflow somehow. Perhaps if they'd tried to get open source projects and their maintainers onto a shared platform to manage both code and (potentially paid) support they would have earned a mention here.
• Menu

  sunshowers
  > They never cared about the developer workflow.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
• Menu

  tanepiper
  Around about that time, I was working on a Mercurial frontend https://github.com/tanepiper/hgfront - it was around the time GitHub was starting to pick up, and BitBucket also appeared around then (we spoke to the original developer at the time but nothing came of it). Funnily enough also a Gist-like tool that had inline commenting, forking and formatting (https://github.com/tanepiper/pastemonkey).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
• Menu

  simonw
  I clicked on this link thinking "timing and product quality", so I was satisfied to see that GitHub co-founder Scott Chacon credits it to "GitHub started at the right time" and "GitHub had good taste".
• ThinkBeat
  A commercial proprietary platform that came around at the right time to cash in on the open source movement, and was then acquired by Microsoft for $7.5 billion¹ in 2019.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
• INTPenis
  I was there from the ground floor and Gitlab.com failed miserably in SEO.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.
• izietto
  I think GitHub won because its UI/UX it's the best among competitors-and I don't mean it's perfect, just that it's the best among competitors.
• red_admiral
  I remember the days when on sourceforge, you sometimes had to find a small link as opposed to the big download button that gave you an installer bundled with "offers". As far as I know this is something SF added on top of the binaries the author was trying to distribute.That left a market opportunity for something better. I think that _might_ have had something to do with it.
• masa331
  Surely Github is most popular git hosting nowadays but fortunately there are good alternatives like Gitea for those who don't want to give Microsoft free access to any code you you host on Github. Spinning up a new instance can be done in one afternoon and is not complicated
• pmarreck
  And they STILL don't have IPv6 support >..<
• physicsguy
  Sourceforge was horrible to use. GitHub was widely used but it only really reached proper dominance I think when it started offering free closed source repositories to people that weren't paying them, which was what, 2014/2015 or so? Until then it was pretty common in my experience for people to use BitBucket for Git for private stuff.
• scelerat
  The ease of creating, deleting and merging branches and patches is what sold me on git over subversion (which itself was a vast improvement over the only VCS I had experienced up until that point, CVS). When the author describes the literal jaw-dropping demos, I remember having a similar reaction.
• langsoul-com
  They had the timing, the name and the reputation boost.Though I wonder if bit bucket would win if they had githubs name
• codr7
  Because it was a lot better than the alternatives and free?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.
• thepra
  I don't know about that, it was a dead platform for my projects by the time that the US government policies went and blocked accounts and projects of some middle east developers.Since then I'm happy self hosting Gitea. GitHub is still a decent place to contribute to others projects.
• Menu

  sirspacey
  I’m a little stunned by “taste” as the defining factor, but GitHub has certainly brought the industry a long way!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?
• asnyder
  Personally I really liked darcs, always felt more natural and intuitive to me.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.
• Menu

  amtamt
  vi: 1976 GNU Emacs : 1984 BIND: 1986are (along with too many other projects) from way before Nov 1993, where "The Total Growth of Open Source" graph starts from 0.
• Menu

  LtWorf
  Github won because sourceforge was ruined already.
• righthand
  It’s also never to late to use a different vcs. Especially if you have no one who’s interested in your code, like me. “Winning” isn’t everything as they say.
• Menu

  transpute
  > we won because we started at the right time and we had taste.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.
• Menu

  devnull3
  The rise of github also coincided with enshitification of sourceforge.net. SF although was not git based at that time but it had the mindshare of lot of open source projects and it went complete downhill.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
• Menu

  throwaway5752
  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.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.
• mikemitchelldev
  I didn't realize Scott Chacon was a founder of Github. Did they all cash out equally?
• below43
  cough. its, not it's.
• sergiotapia
  I still miss Codeplex from microsoft ;) it was a really beautiful website
• lkrubner
  Github won in part because git won. And git won because, for complex sociological factors, the software engineers were able to argue that their needs were more important than the needs of other parts of the companies for which they worked.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.
• Menu

  amir734jj
  I work at Microsoft, so I write a lot of pipelines and interact a lot with git.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
• sylware
  Well, I can login and use core functions on github with a noscript/basic (x)html browser... gitlab... well...
• anon
  undefined
• mproud
  its
• Menu

  ranger_danger
  https://sfconservancy.org/GiveUpGitHub/
• jarule
  Why GitHub was started. To ease ass pain.
• pictur
  [dead]
• Menu

  chx
  git won because of empty hype, bzr was far superior in basically every aspect. Much easier to program with either for plugins or to be embedded, much saner "hide your development commits" model with log levels, much saner command line interface. It's just better.It's not the first thing to be carried by hype instead of careful comparison.
• keybored
  > Why GitHub Actually Won> 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.
• vander_elst
  They might have taste but they still don't have IPv6. Sorry for the rant, but I'm always baffled that they haven't switched yet. Anyone has insight about the challenges they are facing?