GitLab being open source and easy to run on your own hardware is a huge "selling" point. I don't think it's helping their income much, but it's growing the community of users and the money will probably come later. It's very hard for GitHub to compete with that. GitHub could introduce CI and other things that GitLab has, but it would be just one extra feature you have to pay for.
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.
I'd argue otherwise, but have no source to support my claims. Maybe someone can help. Here's my 2 cents:
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.
It's not so easy. Which lunch are you talking about? Self-hosted or hosted?
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.
The way I see it going is that many, many large companies will have a bunch of teams on GitHub (with good reason), with both public and private repos. They will also have a bunch of teams on GitLab instances that have been wildcatted into existence, possibly before GitHub had decent inroads, but more probably so the code doesn't leave the firewall.
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.
It's not that speculative. It's predictable from the direction the company I work for is going in.
> 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.
Money is not the only factor. IT informs me that we are getting great support from github for our enterprise instance. As a user I have no clue what support means, but the people in IT are the ones getting that help.
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).
Because github still has 99% of that market. Just look at how many repositories opened by Google, Facebook, Apple, Microsoft, NSA, GCHQ and 100s of others big players are on Github and how many on Gitlab.
That is true. But I reckon those big players just said "let's go with the flow and move some stuff to Github, good from the marketing point of view, etc". My point being that is just a trend. If Github is not careful, that trend can change anytime. Debian and GNOME are well known, big open source projects. This helps them a lot and pushes that trend a wee tiny bit in Gitlab's side.
People/companies go to GitHub to be social. It's the Facebook of computer code. That's why all the big players are there, so they can share/market themselves. It's also where a lot of programmers put their code so they can show it for interviews. That's why there are so many public repositories there.
Totally agree with this. This is the reason that I self-host with Gitea but mirror everything to Github.I essentially use Github as a forwarder to my Gitea instance.
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.
Yes but how many of those are just mirrors and sources for non-contributors to find the code. See Linux Kernel as an example, the Kernel is mirrored on GitHub but none of the actual development takes place there.
I don't think it's about mirror of source code being there, I think it's more about a community of people and developers being able to report issues there. Eg. steam client is not opensource, but it has github repo where we report distro/Xorg/Wayland/libs related issues, and they often respond.
While I'm glad to see competition gearing up, I don't think GitHub and GitLab are in the same ballpark yet.
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".
"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.
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 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)
> 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".
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.
Most non-huge companies are unlikely to be able provide _more_ reliability from a self-hosted installation than a cloud hosted installation. I suspect this is true of gitlab, but if it's not, it would speak negatively to gitlab's ability to provide a reliable service.
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-...
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.
I'm not sure what UI changes are in GitLab 10 but something that seems a little off for me is that when you're on a repo homepage, there can be quite a bit of scrolling before you get to the readme. For example:
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.
