There a small bit of irony that it required a fully decentralized source control management in order to consolidate the market for OSS code/project hosting. The obvious caveat is that git allows any project to pack up and leave anytime they want, but the vendor lock-in came by means of the network effect and developer preference. There is an incentive on GitHub, at least, to provide a superior product to other alternatives like Gitlab or Bitbucket. Ultimately, it meant the risk of choosing GitHub was very low due to the nonexistent vendor lock-in.
During SourceForge’s decline, most OSS projects were either very prolific, general purpose libraries or full software packages, all of which had most of their infrastructure sorted. There were a number of other platforms, now mostly forgotten, that tried to acquire the displaced market shed from SF’s former userbase.
Almost every one of the new platforms wanted to just be a better SourceForge, but none of them wanted (or thought to) to tackle the problem of git hosting as their primary product they were selling to users - which ultimately proved to be what the market wanted. OSS devs with a project likely already had an issue tracker, website, discussion forums, etc, and they didn’t want to spend their day in a CRUD app manually managing releases and fielding support requests on a platform that different from what they setup already. GitHub offered public git repository hosting with a modern look that was betting on companies buying commercial-oriented features as a monetization strategy, rather than ads. Eventually, a-la-carte features such as issues, discussions, and wiki were added, but were able to be toggled at the project-level.
Meanwhile, SourceForge was too busy cramming more ads in, cluttering layout, trying out asinine social media integrations, and ultimately, accelerating their (at this point) well-deserved) death by packaging malware/adware in software distributions. It was easy to see in the moment (and even more in hindsight) how much of a loser strategy this was for SF. It’s almost comical how spectacularly they fucked up their own market share with short-term thinking and outright stupid ideas. Not much love was lost here by the end.
Without GitHub, npm would not have been successful (which itself inspired other package managers), CI/CD would either be a bigger mess or dominated by a single vendor (which enabled fun stuff like infrastructure-as-code), coding in general would not be as accessible, and git itself may not have won out as heavily as it did.
GitHub’s success is a good case study in a startup being at exactly the right place at the right time, with the right product. The result wasn’t the mass migration of prolific projects immediately moving in, rather it enabled this back-pressure of micro-OSS projects to thrive because now it became viable to build a library that does one thing really well without the admin work of managing a full-blown OSS project. A number of projects eventually moved in, but the driving force to adoption, in my opinion, were the tiniest projects that ultimately proved this platforms viability.
> The obvious caveat is that git allows any project to pack up and leave anytime they want...
People always say this but it just isn't even remotely true. Even if we ignore the "obvious" issue of, well, issues and other important project data that isn't part of your git repository, if you try to "pack up and leave" you will rapidly find that your github.com URL is now distributed around the entire internet as if it were your home page and is even embedded into other peoples' build scripts as the core problem was never the data you are hosting but is actually the identity and address of that data. The reality is that GitHub using git is no different from any other hosting platform, such as Instagram or YouTube. Yes: your content on YouTube is "merely" a bunch of video files and those video files could just as easily be hosted on any other video hosting provider as video files are about as boring and standardized and portable as can be imagined, yet obviously we wouldn't say anyone can trivially "pack up and leave" their decade of investment into a popular YouTube channel.
And that’s why your platform should be a website under your domain name. If I want to refer to a particular project, I go to their website first, and use the link there for the source code. There are too many mirrors repo on github to trust the first username I see. For most popular projects I use, I never care about their github page other for checking the code and issues page. It’s either their docs or the cloned version on my computer. The last project I interacted with was Authelia and I’ve not opened the github page once (if they even use github)
During SourceForge’s decline, most OSS projects were either very prolific, general purpose libraries or full software packages, all of which had most of their infrastructure sorted. There were a number of other platforms, now mostly forgotten, that tried to acquire the displaced market shed from SF’s former userbase. Almost every one of the new platforms wanted to just be a better SourceForge, but none of them wanted (or thought to) to tackle the problem of git hosting as their primary product they were selling to users - which ultimately proved to be what the market wanted. OSS devs with a project likely already had an issue tracker, website, discussion forums, etc, and they didn’t want to spend their day in a CRUD app manually managing releases and fielding support requests on a platform that different from what they setup already. GitHub offered public git repository hosting with a modern look that was betting on companies buying commercial-oriented features as a monetization strategy, rather than ads. Eventually, a-la-carte features such as issues, discussions, and wiki were added, but were able to be toggled at the project-level.
Meanwhile, SourceForge was too busy cramming more ads in, cluttering layout, trying out asinine social media integrations, and ultimately, accelerating their (at this point) well-deserved) death by packaging malware/adware in software distributions. It was easy to see in the moment (and even more in hindsight) how much of a loser strategy this was for SF. It’s almost comical how spectacularly they fucked up their own market share with short-term thinking and outright stupid ideas. Not much love was lost here by the end.
Without GitHub, npm would not have been successful (which itself inspired other package managers), CI/CD would either be a bigger mess or dominated by a single vendor (which enabled fun stuff like infrastructure-as-code), coding in general would not be as accessible, and git itself may not have won out as heavily as it did.
GitHub’s success is a good case study in a startup being at exactly the right place at the right time, with the right product. The result wasn’t the mass migration of prolific projects immediately moving in, rather it enabled this back-pressure of micro-OSS projects to thrive because now it became viable to build a library that does one thing really well without the admin work of managing a full-blown OSS project. A number of projects eventually moved in, but the driving force to adoption, in my opinion, were the tiniest projects that ultimately proved this platforms viability.