4 ms·
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 wil
by regularfry 9y ago
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.
- icebraining 9y agoGithub does have a self-hosted version (Github Enterprise). Not open source, though.
- pizza234 9y agoThis is very speculative. 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.
- regularfry 9y agoIt'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.
- bluGill 9y agoMoney 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).