25 ms·

Why GitHub won

• simonw 2y ago
  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".
  • SoftTalker 2y ago
    git won because linux used git, and the vast majority of open-source code was written for linux. Simple as that. GitHub won because it made remote collaboration on a code base easier than anything else.
    • bluGill 2y ago
      I think that if github hadn't come out something other than git would have one. While git did have Linus behind it, the others were objectively better in some way and working on the areas they were objectively worse, and eventually the advantages would have got everyone to switch. However the others never had anything like github - even 20 years latter they still aren't trying (rumor is they are not dead)
• LtWorf 2y ago
  Github won because sourceforge was ruined already.
  • heisenbit 2y ago
    SF lost its way. My vague memory is that SF and also CollabNet were focusing on higher level functionality and while valuable neglected the basic code sharing growth/ease of use which is the rationale for all their existence. Too early into higher level functionality.
    • latchkey 2y ago
      I worked for CollabNet from pretty early on. CollabNet had one major customer... HP. Everything got developed for a relatively stodgy old customer. They wanted centralized version control. They wanted tons of ACLs. It all was very corporate sales focused. Github "won" because they were not CollabNet.
      • heisenbit 2y ago
        At the time I was in an industry collaboration and we needed a place to work together and looked at SF and CollabNet. Internally we also would have benefitted from such a tool so I even got an onsite demo by SF. It was impressive but also as you say enterprise focused and very different from their free offering. And that was imho the key reason: There was not one but were two offerings with different tech and customers. Focus was lost.
• teqsun 2y ago
  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.
  • vehemenz 2y ago
    As an "older" programmer, I feel the opposite. Git became mainstream very recently, though admittedly it's been a good ten years or more. I sometimes think younger programmers' attitudes toward git are borderline cultish—git or GitHub is not required to do programming—it's just another tool. I half expected something would have replaced it by now.
    • schacon 2y ago
      Git's been around for almost 20 years now. I would say fairly dominant for 15 or so.
    • keybored 2y ago
      Git is overrated for a DVCS. But it’s not overrated considering the old-school competition like SVN. The assumptions of SVN makes it feel like a dinosaur now.
      • deleted 2y ago
        [deleted]
    • gmueckl 2y ago
      I have to agree on the cult aspect. This is unfortunate because better tools exist already today, but lots of people refuse to even entertain that possibility.
      • teqsun 2y ago
        I feel about git how I presume vim users feel. Maybe there are better ways, but I've become so accustomed to how it works that I doubt I could easily switch to anything else.
• DannyBee 2y ago
  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 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".
  • schacon 2y ago
    I'm not sure what "SF" means in this context. San Francisco? I can't figure out what you want to say Google Code was for exactly. If Google launches a major project, I find it hard to believe that it's just for fun.
    • kemayo 2y ago
      Sourceforge.
    • deleted 2y ago
      [deleted]
    • ipsi 2y ago
      SourceForge, probably.
    • blktiger 2y ago
      It’s short for Source Forge which is still around technically but a shadow of its former self.
      • 2y ago
• sergiotapia 2y ago
  I still miss Codeplex from microsoft ;) it was a really beautiful website
• AnotherGoodName 2y ago
  Well Sourceforge literally bundled malware for a while. So everyone had to move. https://news.ycombinator.com/item?id=31110206 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.
  • schacon 2y ago
    This is not my recollection, at least at the time. I remember meeting with one of the SourceForge founders and being a little star struck. SourceForge was a huge deal at the time and we totally felt like we were the underdogs in that arena. Perhaps later they got more desperate, but in 2008, SourceForge was the 900lb gorilla.
    • AnotherGoodName 2y ago
      2013 is when the binaries had malware included although even in 2008 they were guilty of having 5 download buttons due to excessive and unpoliced inline advertising with only one of those buttons being the holy grail that linked to the download you actually wanted. Choose wisely.
      • beAbU 2y ago
        I completely forgot about the absolute gamble that was "which big green button is the actual download button this time" when using SourceForge and Tucows back in the day.
    • kstrauser 2y ago
      Who is "we"?
• throwaway5752 2y ago
  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.
  • kstrauser 2y ago
    That's all true for me, too, although I hadn't used p4. I resisted Git for a little while because I didn't see the massive appeal of a distributed system in an office with a central server. CVS... worked. SVN was a much more pleasant "faster horse". And then I made myself try Git for a week to see the fuss was all about and my eyes were opened. Git is not perfect. There are other products that did/do some things better, or at least more conveniently. But Git was miles ahead of anything else at the time that I could use for free, and after I tasted it, I never wanted to go back to anything else.
    • throwaway5752 2y ago
      I was a late adopter, also, and git is definitely not perfect. Mercurial did some things better, and at the time, notably, the forest extension. Git's flexibility is a two edged sword and the history rewrite footguns should be harder to use. Git does comes close enough to solving a fundamental problem it will be very, very durable, though. As long as it is used for linux kernel development I expect it continue to be the dominant dvcs.
  • physicsguy 2y ago
    God I hated ClearCase, did a migration from it in 2016(!) for a project that had been around since the late 80s. People were really resistant to moving but once it was done were like "Oh wow, it's really fast to create a branch, this means we don't have to have one branch for three months!"
• seveibar 2y ago
  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!
  • nprateem 2y ago
    It's just survivorship bias. If HH hadn't won no one would be trying to reverse justify their success. This bet worked, the mercurial ones didn't.
  • aidenn0 2y ago
    I would argue that hg was more tasetful than git at the time github began. The one thing git had going for it was that the most common operations were absurdly fast from the beginning, while hg took a bit of time to catch up.
    • seveibar 2y ago
      I agree with this take, I think hg could have overtaken git for a while, but git catered a bit better to the OS communities and hg catered a bit more to big companies from a DX perspective. Maybe in this case, the important thing is knowing that your partners/technologies are aligned with your vision of the future- git has been more open-source first (I would argue)
  • digging 2y ago
    Not sure what is even meant by "taste" here; what I see over and over is that convenience wins, where winning is defined as widespread use.
    • rustyminnow 2y ago
      The article uses "taste" pretty broadly compared to many folks in the comments. First mention is about the site being pretty. But later he says "We had taste. We cared about the experience" which more aligns with your perspective of convenience.
• devnull3 2y ago
  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
  • schacon 2y ago
    I would argue that SF was always pretty shitty, because it focused entirely on advertising. I remember Chris giving a talk comparing the signup process of GitHub and SourceForge. SF had like 8 fields and GitHub had 2. This was because SF wanted to know ad demographic info - where did you hear about us, etc. GitHub just wanted a name and a password. But this was the difference in everything - SF cared about advertisers, not developers. GitHub never thought about what anyone other than the developers using the product wanted.
    • devnull3 2y ago
      Agree but my point is when you see a new and better rival then instead of pivoting SF became even worse and became malware-ised. Also SF was based on SVN. They failed to understand and capitalize on a better tech on the market i.e. git.
      • schacon 2y ago
        They actually did so very early. In early 2009 they added Git, Hg and Bzr support: https://arstechnica.com/information-technology/2009/03/sourceforge-adds-support-for-new-version-control-systems/ https://arstechnica.com/information-technology/2009/03/sourc... That's less than a year after GitHub launched and was still very small.
        • devnull3 2y ago
          I stand corrected! Thanks!
  • 2y ago
• max_ 2y ago
  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)
  • crop_rotation 2y ago
    > 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. I doubt there is a big enough market of anarchists for Github to even bother worrying. > One such service is an end to end encrypted Git repo service. There are so few people that need this, that they can just use client side tools and store all data that gets to remote servers encrypted
    • Diti 2y ago
      It’s already feasible with Keybase (although I wouldn’t trust them any more, because of the Zoom debacle).
    • max_ 2y ago
      >I doubt there is a big enough market of anarchists for Github to even bother worrying. A lot of people writing prorietory code bases would definitely use it. I don't think a founder wants the startup's codebase to leak via an LLM?
      • nine_k 2y ago
        A ton of proprietary code lives on GitHub, on closed paid repos. A lot of people reasonably think that GitHub's security chops are better than theirs. But if you care, there is a whole gamut of on-prem solutions, from running bare cgit to fluff like Gitea and GitLab. Lock up your central repo machine all you want, the code is still checked out to developers' laptops. For more security, don't allow that, and let your devs connect to a server with all necessary tools and access to the code, but without general internet access, for instance.
• imiric 2y ago
  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.
  • schacon 2y ago
    I do go into Linux and Linus in the article in some depth, but even Linus credits the Ruby community to a degree with the explosion in popularity of Git, which is fairly clearly due in large part to GitHub. But, it's certainly a chicken/egg question. I would also argue that MS is nothing like the company that it was 30 years ago when that philosophy was a thing. The truth today is the via GitHub, Microsoft hosts the vast majority of the world's open source software, entirely for free.
    • nine_k 2y ago
      MS have realized that producing the right kind of important open-source software gives even more strength than producing closed-source software. Hence Typescript, VS Code, a few widespread language servers, etc.
      • bluGill 2y ago
        MS has long known developers were critical to their success. For a while they were worried that projects like Linux would take away their market, but it is now clearer to everyone where linux is going and so they don't have to worry as much. (so long as they are not stupid)
• ldayley 2y ago
  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
  • bluGill 2y ago
    I still miss hg. I migrated to github years ago because github is a much better workflow, but I miss hg which can answer questions that git cannot.
  • kccqzy 2y ago
    I learned git first because it was already very popular when I decided to learn it. But when I later learned hg for fun, I realized how much of a better user experience it is: * After using hg which doesn't have the concept of an index, I realize I don't miss it and the user experience is better without it. Seriously, even thinking about it is unnecessary mental overhead. * As someone who modifies history a whole lot, `hg evolve` has superior usability over anything in git. The mere fact that it understands that one commit is the result of amending another commit is powerful. Git doesn't remember it, and I've used way too much `git rebase --onto` (which is a poorer substitute) to be satisfied with this kind of workflow. * Some people, including the author, say cheap branching is a great feature of git. But what's even better is to eliminate the need to create branches at all. I don't need to use bookmarks in hg and I like it that way. I sometimes imagine an alternate universe where the founders of GitHub decided instead to found HgHub. I think overall there might be a productivity increase for everyone because hg commands are still more user friendly and people would be stuck less often.
• tanepiper 2y ago
  Around about that time, I was working on a Mercurial frontend https://github.com/tanepiper/hgfront 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 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 https://youtu.be/NARcsoPp4F8
  • schacon 2y ago
    Fun fact, I (original author), wrote the original version of Gist. That was my first project at GitHub. Gist #1 is my claim to fame: https://gist.github.com/schacon/1 https://gist.github.com/schacon/1
• SenHeng 2y ago
  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.
  • tootie 2y ago
    Idk, I loved BitBucket and I loved Mercurial. It was much easier to use and had native JIRA integration. I always thought (and still do) that github looks too cute and not very serious.
• ranger_danger 2y ago
  https://sfconservancy.org/GiveUpGitHub/ https://sfconservancy.org/GiveUpGitHub/
  • schacon 2y ago
    [flagged]
    • ranger_danger 2y ago
      I could be wrong but I don't think hyperbolic conjecture is going to swing anyone the other direction.
      • schacon 2y ago
        Which is ironic, because that entire article is hyperbolic conjecture.
    • jordigh 2y ago
      You only feel this way because it's written about something you worked on. * Co-Pilot is trained on copyrighted code without attribution: ludicrous? * Github works with ICE: incoherent? * All of Github's hosting code is proprietary and secret: ridiculous? * Github tries to discredit copyleft: hyperbolic? * Github is wholly owned by Microsoft who also doesn't like copyleft: conjecture? As to SFC not having anything better to do... this is exactly what their mandate says they should do. This is what they collect money to do: to point people towards free software. If you want SFC to find something better to do, I assume you want them to completely shut down their organisation and stop complaining about undermining copyleft and stop complaining about non-free code.
      • schacon 2y ago
        I don't particularly want to engage, but why not? * Co-Pilot is trained on copyrighted code without attribution: ludicrous? This is debatable, but yes, it's a ridiculous reason to not use github. If your code is on the internet, which it is with every other alternative host they mention, it will be crawled and used for training, just as it will be read by humans and learned from. We can have a fair use debate, but GitHub is not alone in this stance or problem set. * Github works with ICE: incoherent? No, I would file this under ridiculous. GitHub is a government contractor. It licenses it's software to lots of organizations. People can disagree with a lot of them, but trying to manage that and dictate changing political morality at a company level is insane. All of these other solutions are certainly used by organizations that are a lot more controversial than a major federal institution, as much as I may even personally disagree with policies under certain administrations. But again, singling out GitHub is just finding some reason to be mad, it's not GitHub specific. * All of Github's hosting code is proprietary and secret: ridiculous? The computers that you're writing your FOSS code on, that indeed they wrote this article on, have proprietary chips, have software you can't access. You think everyone at SFC uses a Stallman-esque laptop? They're probably happily typing away on their Macbooks, full of non-FOSS software. The software community is an ecosystem of lots of models, nobody is all-FOSS, it's not possible. GitHub has open sourced Electron, libgit2, a thousand other things. Core code was never helpful to anyone and would not be helpful today. Git isn't a lock-in proprietary thing, you can always easily transfer your code elsewhere. * Github tries to discredit copyleft: hyperbolic? It doesn't try to discredit copyleft as a corporate stance. Several individuals have pointed out weaknesses in copyleft vs permissive OSS licenses. But it's never that you should use closed instead of copyleft or something, it's always something like if you're using copyleft, it's generally better for the community to use MIT or Apache or something more permissive that doesn't need to involve lawyers and gives you more freedom. * Github is wholly owned by Microsoft who also doesn't like copyleft: conjecture? This is a 30 year old take on what Microsoft cares about. Microsoft probably never thinks about copyleft these days, any more than the rest of us do. MS contributes to Linux, contributes to Git, both GPL projects. Almost certainly they contribute more to GPL projects globally than you or I or the SFC do. > As to SFC not having anything better to do... this is exactly what their mandate says they should do My point was that they can actually help the Git project by sponsoring meetings, educating people in a useful way, etc. I have helped donate a fair amount to the SFC through GitHub events and was hoping the money would be better spent on actual community building and project fostering rather than cheap think-pieces like this.
• Bjorkbat 2y ago
  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.
  • darby_nine 2y ago
    sourcehut is always worth a mention, though I have never used it in a collaborative environment.
    • rapnie 2y ago
      sr.ht doesn't go for "fun" but brutal minimalism as their main selling point.
  • wood-porch 2y ago
    This. GitHub is a joy to use compared to its competitors. Using bitbucket at work is frustrating, and reminds me of a lot of Microsoft web interfaces, ironic, given that it’s GitHub and not Bitbucket that is owned by them now
  • bluGill 2y ago
    You don't need enterprise clients. Projects like KDE self host and are enough to keep you around and getting new features if you can get them on board. Plus enterprises often look at their bottom line and ask if something else is a better value so if you are "free" some of them will switch to you.
• nerdix 2y ago
  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.
  • nine_k 2y ago
    Not just that. They invented "pull requests" and offered (initially minimal) code review tools. This made contributing in the open.much easier, and making small contributions, vastly easier. Something like git had to take over svn / cvs / rcs. It could be Perforce, it could be BitKeeper which apparently pioneered the approach. But it had to be open-source, or at least free. Git won not just because it was technically superior; it also won because it was at the same time free software.
    • fweimer 2y ago
      Pull requests predate Git. The kernel developers used them in the Bitkeeper days: I exported this a patch and then imported onto a clone of Marcelo's tree, so it appears as a single cset where the changes that got un-done never happened. I've done some sanity tests on it, and will test it some more tomorrow. Take a look at it and let me know if I missed anything. When Andy is happy with it I'll leave it to him to re-issue a pull request from Marcelo. https://lore.kernel.org/linux-acpi/BF1FE1855350A0479097B3A0D2A80EE009FC7F@hdsmsx402.hd.intel.com/ https://lore.kernel.org/linux-acpi/BF1FE1855350A0479097B3A0D... I do not know to what extent Bitkeeper had browser-based workflows. Moving cross-repository merges away from the command line may actually have been innovative, but of course of little interest to kernel developers.
      • schacon 2y ago
        That's interesting. I know BK had "pulls", but iirc it didn't have a "request-pull" command, so clearly the "pull" terminology came from BK and the "request" part came from how people talked about it in email. I actually just shot a video showing how BitKeeper was used. I'll post that and a blog post on our GitButler blog soon.
• chx 2y ago
  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.
  • schacon 2y ago
    I think PR and network effects of GitHub definitely played a role in the success of Git over other options like bzr, but you should also remember that bzr had tons of issues. It was slower, there was no index/staging area, there was no rebasing, etc. Mercurial was very good too, but while there were pluses and minuses with all of them, I think there was a _lot_ of careful comparison too. None of them were clearly and in all aspects better than the others.
  • kstrauser 2y ago
    That's simply untrue. Bzr was dog slow on repos with lots of history. It had lots of early users and support from hosting services like Launchpad, Savannah, and SourceForge. I'm certain that everyone didn't migrate to git because of hype. I mean, it's not credible to say the Emacs team stopped using it because it wasn't fashionable. There were lots of DVCS projects at the time, like arch, darcs, and dcvs. People were running all kinds of experiments to explore the Cambrian explosion of new ideas. Some of them did some things better than git, but git handled most of those things reasonably well and it was fast. We all mostly ended up on git because it was generally the better option. It earned the hype, but the hype followed the adoption, not vice versa.
    • chx 2y ago
      So in exchange for a little speed we are stuck with one of the most user hostile tools out there. That's not the deal I would have wanted to make. The interface is atrocious as some switches change completely what the command does -- this was partially acknowledged and fixed in git switch but there's so much more, it loses work way too easily and some of the concepts are near impossible to grok. (I did learn git eventually but that doesn't mean I like it. It's more of an uneasy truce than a friendship.)
• gsliepen 2y ago
  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.
• transpute 2y ago
  > we won because we started at the right time and we had taste. 2012, https://a16z.com/announcement/github/ 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/2018/06/04/microsoft-buys-github-for-7-5-billion/ 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.
  • schacon 2y ago
    What is the point you're trying to make here?
    • transpute 2y ago
      Did $100M investment help Github to win, or had Github already won in 2012 with profitability and 3M git repos?
      • schacon 2y ago
        I would argue that GitHub already won in 2012. The investment helped us grow in a different way, but I don't think anyone involved in that deal would have said that we had almost any serious competitive threats at the time, which is to some degree why it was such a great deal.
        • transpute 2y ago
          Did the investment encourage corporate buyers to sign up for Github Enterprise, where corp developers were already using the free product?
• amtamt 2y ago
  vi: 1976 GNU Emacs : 1984 BIND: 1986 are (along with too many other projects) from way before Nov 1993, where "The Total Growth of Open Source" graph starts from 0.
  • schacon 2y ago
    It all depends on how you're counting. For one, "open source" was not a phrase before 1998, so there is some retrofitting of Free Software projects. But also, there isn't a registry, it's rather difficult to be more than approximate with this. The article is very specific about their methodology, I'm only using one graph as a general example.
    • amtamt 2y ago
      From the paper > "The database contains data from January 1990 until May 2007. Of this time horizon, we analyze the time frame from January 1995 to December 2006. We omit data before 1995 because it is too sparse to be useful" > "Large distributions like Debian are counted as one project. Popular projects such as GNU Emacs are counted as projects of their own, little known or obsolete packages such as the Zoo archive utility are ignored" So even though methodology is "very specific", it seems very incomplete/ inaccurate/ selective. Even Linux kernel, as per their source, started in 2005 (https://openhub.net/p/linux https://openhub.net/p/linux). Source: https://www.researchgate.net/publication/45813632_The_Total_Growth_of_Open_Source/download https://www.researchgate.net/publication/45813632_The_Total_...
• physicsguy 2y ago
  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.
• jarule 2y ago
  Why GitHub was started. To ease ass pain.
• deleted 2y ago
  [deleted]
• keybored 2y ago
  > 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.
• pictur 2y ago
  [dead]
• sunshowers 2y ago
  > 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 https://github.com/sunshowers/spr
  • juped 2y ago
    You can't even see a commit graph (no, the insane glacial-js "network" tab doesn't count). You can see it in bitbucket for heaven's sake. The basic data structure of git, invisible. On a GUI.
• sirspacey 2y ago
  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?
  • echelon 2y ago
    Have you used SourceForge or SVN? Or sent a zip of files named "v23_backup_(copy).zip" to other engineers? Compared to everything that came before, Github may as well have been Nirvana.
• scelerat 2y ago
  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.
• mikemitchelldev 2y ago
  I didn't realize Scott Chacon was a founder of Github. Did they all cash out equally?
• vander_elst 2y ago
  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?
• asnyder 2y ago
  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.
• sylware 2y ago
  Well, I can login and use core functions on github with a noscript/basic (x)html browser... gitlab... well...
• amir734jj 2y ago
  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
  • TheRealPomax 2y ago
    Want to expand on that second point? Github actions have more prebuilt workflows than I can shake a stick at; no copy pasting anything, you just say "uses: actions/whatever@v123" in your own yaml, configured with some "with" statements.
    • mdaniel 2y ago
      I'm not GP, but I firmly agree with the observation. I also readily admit that I'm for sure biased because I was on GitLab before GHA was even a dream in someone's eye The hazard to "prebuilt workflows" is that one needs to know about them, and load their assumptions into your head before using them, which can be true of any sprawling namespace but tends to be less true within a single organization. That's not even getting into the risk of folks who do both things: copy-paste someone else's "uses:" statement eliding the version pinning because "what's the worst that can happen," amirite?! As for the "for terraform, AWS, k8s" part, that is 110% why I am a GitLab fanboy because the platform natively speaks those technologies - I don't need to (deep sigh) set up an S3 bucket with a DynamoDB to have Terraform State - it ships with GL. I don't need to do crazy "uses:" with some rando shit to use AWS federated credentials, it ships with GL. I for sure don't need to do crazy "uses:" to have k8s rollouts, rollbacks, status checks, and review environments: they are built-in concepts in GLCI Also, unless something has gravely changed in the past little bit, how in the universe can anyone use GHA with a straight face without "show me the expanded and linted version of this yaml" as with https://docs.gitlab.com/ee/ci/yaml/lint.html#simulate-a-pipeline https://docs.gitlab.com/ee/ci/yaml/lint.html#simulate-a-pipe... I'll fully admit that $(gitlab-runner exec) is a cruel joke, but every time I hear someone claim that Act (or its like 50 forks over in Gitea/Forjeho-land) are "local GHA" I throw up in my mouth, so I consider that pretty much a wash --- ed: I realized this debate is also very similar to the Maven-vs-Gradle argument: do you want executable junk in your build process, or do you want declarative steps? I am firmly, 1000000000000000000% in the Maven camp, which also explains why the last thing I want is some minified .js files someone else wrote to be injected into my CICD process
• ThinkBeat 2y ago
  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
• chubot 2y ago
  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 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)
• codr7 2y ago
  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.
• below43 2y ago
  cough. its, not it's.
• thepra 2y ago
  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.
• righthand 2y ago
  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.
• mproud 2y ago
  its
• jillesvangurp 2y ago
  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.
• lkrubner 2y ago
  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.
• red_admiral 2y ago
  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.
• INTPenis 2y ago
  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 2y ago
  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.
• masa331 2y ago
  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
• langsoul-com 2y ago
  They had the timing, the name and the reputation boost. Though I wonder if bit bucket would win if they had githubs name
• cromulent 2y ago
  The guy who reverse-engineered the Bitkeeper protocol, triggering the creation of git, is the same guy who created rsync - Andrew Tridgell.
  • trelane 2y ago
    Also Samba. https://en.m.wikipedia.org/wiki/Andrew_Tridgell https://en.m.wikipedia.org/wiki/Andrew_Tridgell Reverse-engineering proprietary protocols is definitely one of his things.
• thom 2y ago
  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.
• trelane 2y ago
  LWN linked to a summary of the origin of git: https://lwn.net/Articles/974914/ https://lwn.net/Articles/974914/ They also provided a set of links to LWN articles from that era.
• pmarreck 2y ago
  And they STILL don't have IPv6 support >..<
  • mdaniel 2y ago
    I always enjoy replying to these comments with $ dig +short gitlab.com. AAAA 2606:4700:90:0:f22e:fbec:5bed:a9b9 and, just to pour more salt in that wound $ dig +short bitbucket.org. AAAA 2401:1d80:321c::bbc:1:df7c 2401:1d80:321c:2:0:bbc:1:df7c 2401:1d80:321c:1:0:bbc:1:df7c $ dig +short git.sr.ht. AAAA 2a03:6000:1813:1337::155 and it's not like Microsoft doesn't know how to run IPv6, both microsoft.com and portal.azure.com are on V6
    • pmarreck 2y ago
      I wish they even had some official statement as to why this hasn't been implemented yet, but from what I can tell, basically nothing has been said about it
• josefrichter 2y ago
  I am seriously worried about the Microsoft acquisition, because products acquired by MS almost never end up well.
• WhyNotHugo 2y ago
  I don't think that GitHub is the most popular forge because it is _good_. I have never heard anyone say "I use GitHub because it has a good UI", "... has good accessibility", "... is well designed", "... I prefer proprietary services" or anything remotely similar. 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.
• grifferz 2y ago
  > one of the Linux developers reverse engineered the protocol, breaking the licensing terms 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. https://lwn.net/Articles/969221/ https://lwn.net/Articles/969221/