Open Source != Public
There has never been a requirement on github that public repositories had to be open source.
GitHub is giving away its core services for free and has slashed the price of its paid Team plan by more than half – from $9 per user to $4. The offer is generous. Before Microsoft acquired the biz, the deal with GitHub was that public (in other words, open-source) repositories were free, but private repositories were paid. …
I'm in the interesting position of using both. Github for my own stuff, been on there for nearly ten years, and Gitlab at work. I prefer the Github web UI but really like Gitlab CI. Github's CI is still a bit clunky for my liking. If I need to start doing a lot of CI then I will be switching. For me, that's the attractiveness of Gitlab...
Once employers started requiring developers to publish a portfolio on github it became attractive to the likes of MS.
Once MS started changing the direction of github so as to monetize it then the environment becomes ripe for someone else to spring up and compete with github for those who remember MS's many abuses.
Nothing here is suprising beyond the acceptance of developers to allow a third party to hold their IP which previously was protected by not only the law but also direct control by the developer of whom got to know it existed.
Personally I always preferred completely controlling what I owned rather than allowing third party "accidents" where my work could be stolen, alteast my way I knew exactly who I had given access to.
Github was monetized early. Here's an obvious example from 2011: Introducing GitHub Enterprise. Your bias is showing.
@"Your bias is showing." less bias than experience, perhaps if you had as much then you would understand.
When share holders are a company's only consideration then what you consider monetizing is but the tip of the iceberg i.e. the dangerous majority is hidden until you are wrecked upon it.
I would be quite happy if MS stepped off the road to hell if only to set free the abundance of excellent code written by all the third parties over decades for the windows platform but even Bill has given up in disgust and distanced himself.
I do use and like Gitea and it is indeed dead simple to deploy. On the other hand, it doesn't provide any continuous integration / delivery out of the box. You could roll your own by hooking into the Gitea API but at that point you are at a level of effort that exceeds that of deploying a GitLab instance.
Feature-wise, GitLab is also much more convenient for managing big, complex projects.
On the other hand, if mostly all you need is a Git repository viewer + bug tracker + wiki, Gitea does a perfectly good job with very low effort.
As for GitHub, I think the only thing it's got going for it is a critical mass of users who already have accounts in it, but that makes it more of a "social media" than a developer site. If you are a big open source project that for some reason needs lots of people hammering your issue tracker, then it might do the job, otherwise you're almost certainly better off with one of the other forges.
Horses for courses, etc.
I'm in the "lovely" position of using github (for opensource), gitlab (on-prem hosted), bitbucket (because we were using this before we were acquired, paid-for-private stuffs); oh, and some of the stuff on github is mirrored into gitlab.com.
We were all about (pre-acquisition) "use my own infrastructure" for doing the CI/CD; whether that's circleci/appveyor/travis-ci/ my very own jenkins or whatever. In fact I have circle-ci/appveyor/github-actions/travis-ci setup for most of our opensource projects to at least run tests: mainly because we can, but also because using multiple pipelines mean that when we have intermittent network-y style failures we can eyeball the PR and still approve it. If 3 out of 4 work, then it's probably an isolated problem that will eventually go-away... if none of them work, then we know it's a regression..
The org itself is in the process of standardising on gitlab on-prem; which means that we were going to move bitbucket into gitlab on prem; but now, we probably won't bother, we'll just move all the existing BB repos into github as private repos, since the opensource stuff will have to live somewhere...
Atlassian can't ignore github or gitlab, so jira/trello will always almost certainly have connectors for them; bitbucket may end up becoming unloved.
> The org itself is in the process of standardising on gitlab on-prem; which means that we were going to move bitbucket into gitlab on prem; but now, we probably won't bother, we'll just move all the existing BB repos into github as private repos, since the opensource stuff will have to live somewhere...
Assuming that your orga makes money, etc., moving on premises stuff ex-premises "because it's free" strikes me as a rather bizarre bit of decision making.
For us the sweet spot is in using GitLab.org and taking weekly backups, which ensures that if/when GitLab goes nasty (gets taken over, etc.) we can spin up our own instance and hopefully keep ticking. In the meanwhile, we save the cost and maintenance hassle of running our instance. We could do with the free plan but we actually pay a subscription because why not? They have mouths to feed too. Small, uncomplicated, one-off code bases live in self-hosted Gitea.