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.