I can't help to think that Gitlab is more and more eating Github's lunch. I wonder why we see so little from Github to get out of that situation.
Being opensource is not normally an aspect that helps the income, actually the other way around. Opensource is the argument that wins for the customers that appreciate lack of vendor-lock-in.
By being open source and allowing people to run it on their own servers, they can potentially convert a massive amount of people to their platform that otherwise wouldn't make the switch. Now the next time these people don't want to run gitlab on their own servers for whatever reason, they'll use their service. And pay for it. because they know the tools, the logic, the UI etc.
The reason I'm arguing for this is because that's exactly what's happening with me. I'm a very happy github user, but I might need to run something similar on my own servers. If I do, I'll host a gitlab. And then, for my other projects where i don't need to run my own instance, I'll probably just use their webplatform. Because it takes me less time to navigate it now that I've run it.
So i can see myself paying for gitlab some day because they've open sourced it and got me 'hooked' on their product as a result.
I don't think GL will ever have anything much in the hosted sector, for two main reasons:
1. GH's infrastructure is far ahead of GL, and 2. the social factor also affects companies that have private repositories, but also public ones - it wouldn't make sense to only move the private repositories to save money
When we think about the self-hosted, then it's possible, but I'm not sure if that would significantly affect GH, which has a different business model.
At some point, a Boss who may or may not have Pointy Hair will look at the bill for GitHub, and the bill for the GitLab infrastructure, and say "Why am I paying for both?" At that point, the teams with code that can't leave the firewall have the trump card, and private repos on GitHub have to move off.
It's not the money itself that makes the argument, it's paying twice for the same thing.
Moving a significant part of the infrastructure is no joke, and requires extremely pressuring reasons. Licensing of course is one of those, but it's not necessarily the general case.
When it comes to GL vs. GH, right now, speed is also a factor - try to fork a large project on GH and on GL; the last time I did, I was worried that I triggered a bug on GL, given how long it was taking. I speculate GL will have significant hurdles, since they work in the cloud (GH is on metal, and the reason a lead engineer gave me is speed), and they may have troubles scaling while containing expenses.
I also doubt that there are so many companies with large projects on GH and small, "wildcat" projects on GL - GH dwarfs GL for hosted services.
If and when mass migrations will be a concern, GH will surely have the tooling ready.
Pointy hairs are not really relevant, since they may take any decision (even the opposite) for any whim.
> Moving a significant part of the infrastructure is no joke, and requires extremely pressuring reasons. Licensing of course is one of those, but it's not necessarily the general case.
"Extremely pressuring reasons" can be as simple as "we don't like that clause in the contract with supplier X, so we now have to move to supplier Y. Yes, I do mean everyone." We've gone through precisely this in another part of our estate, and it triggered a 10 month migration which is still in flight. IP constraints combined with "we must only pay once for a given function" is easily enough.
> I also doubt that there are so many companies with large projects on GH and small, "wildcat" projects on GL - GH dwarfs GL for hosted services.
I can only talk about what I can see: an enterprise, where external GH and internally hosted GL both started very small, and have now consolidated into a single GH org and two (or three? not sure) internal GL services. I'd be pushed to guess where more projects currently live.
Relevant to this conversation: as a company, we looked at GH Enterprise, and decided against it. Or probably more accurately, didn't decide for it. I don't know the reasoning (but I suspect cost).
> Pointy hairs are not really relevant, since they may take any decision (even the opposite) for any whim.
Since they are the ones making the decisions, their reasoning is extremely relevant. There is a logic to how they work, it's just not the one engineers on the ground would pick. So, for instance, they probably won't care about speed of forking unless it actually gets in the way of delivery.
Interestingly, one place GL is winning internally is GitLab CI.
So long as gitHub provides value we will stay there. Support is worth it when several thousand developers get an unplanned paid vacation every time a server goes down (of course git is distributed so the a few minutes of downtime will affect nobody, but much more than that and people notice).
However, I have seen a drastic decrease in interaction (PRs, issues, etc) with my self-hosted repos even though you can auth with your Github credentials.
While I'm a big fan of their team and culture approach, we yet to see better/respected GitLab.com SLA guarantees — it still feels like they're doing too much "testing on production".
Though I generally do like GitLab and favor Github alternatives over Github as I see it as a single point of failure for the FOSS community at this point.
> "testing in production" indeed. One of my repos has been stuck in limbo for over 2 months now
> after I attempted to migrate it to a group namespace from my own profile.
I'm not OP but I've got myself into basically the same problem; https://gitlab.com/gitlab-com/support-forum/issues/2291
I tried some various solutions via CURL to get the repository unstuck (basically rewriting the URL the request is sent to since the project settings page was pointing at the wrong repo) and it basically reports an empty repo on the target (which doesn't show up for me on my profile) and a 404 on the original (which does show up on my profile)
Agreed. However, if you need more reliability than gitlab.com it's not difficult to host GitLab yourself in a VM or on bare metal.
Many companies already have their own physical servers in a DC (either colocated or leasing). Hopefully the people managing these servers know what they're doing and can give the developers a good SLA. Although some additional work on file/DB syncing would be necessary to have a hot spare.
I like that Gitlab exists but I am willing to pay a lot of money to not have to manage yet another server
Certainly while github is occasionally down or misbehaving, there's no way any enterprise I've worked at could self-host with as much reliability as github.
We have a plan to address this and are kicking off our move to GCP shortly. Our top-level engineering department goal is to make gitlab.com ready for mission critical workloads and are targeting industry standard SLA's (e.g. three 9's). You can see our proposed architecture here if you're curious: https://about.gitlab.com/handbook/infrastructure/production-...
Other then that GitLab is amazing.
We're not done yet making GitLab faster but it is getting better quickly. Last big thing we're working on are merge requests with hundreds of comments. Should come out on a few months.
https://gitlab.com/gitlab-org/gitlab-ce/
Perhaps this is by design, to emphasise the code rather than the description of the code, but in my opinion the repo homepage is mostly for those new to the code to start becoming acquainted with it (other pages are more focused on the needs of regular contributors, as they should be), so it makes sense (to me at least) to make the readme more prominent.
I'm not going to suggest how to change it, as it's a decision that should be driven by the UI design team, but just flagging it as something to consider.