6 ms·

I feel bad for GitLab. It's better than GitHub in almost every way. And yet GitHub is more popular both in open-source and enterprise. And in enterprise we are

I feel bad for GitLab. It's better than GitHub in almost every way. And yet GitHub is more popular both in open-source and enterprise. And in enterprise we are usually left with unholy combination of GitHub and JIRA because GitHub project management is a joke and they haven't done anything useful in that space for years. But for some reason pushing for anything other than GitHub is always an uphill battle. And the web interface GitHub offers isn't any good either; I can't use it without OctoTree (amazing stuff BTW, works with GH and GL! Kudos!). So what does GitHub really offer that makes it so popular? A friendly name? A cute OctoCat? And GL leads the way and GH copies their features some years down the line and GL fights and GH is still more successful. I think this is sad.

bdcravens 7y ago
A lot of the development ecosystem had integrations with Github, and haven't yet done so with Gitlab. Additionally, network effects matter, especially when if you add collaborators to your repo it's almost a given that they have a Github account.
- GreaterFool 7y ago
  I assume you're talking about CI? Not much more than that. But that only works in the most trivial cases. One repository, simple tests. I spent tons of time over the years always tweaking this and that to make whatever CI system we were using somehow work with GitHub. Lot's of setup, lots of trouble.
  - bdcravens 7y ago
    Not just CI. Various bug trackers, project management tools, static analysis tools, etc.
m0zg 7y ago
Last time I tried switching to it it was slow as molasses on the command line. Easily several times slower than GitHub. So I went back to GitHub. I still have a GitLab account, but I only keep my dotfiles there. I keep hearing they've improved performance, and maybe they did, but that's also what I heard last time I tried it, so now I'm kind of reluctant to give it another try. Unlike before, now it doesn't just have to be "as fast", for me to switch to it, it has to be noticeably faster. Feature-wise it's easily on par already, but performance is also an important feature, and I don't think codebase being primarily in Ruby inspires a lot of confidence, especially if scale is growing. You're basically running it at 1/10-1/30th the speed it could run if a proper language were used.
- lttlrck 7y ago
  self-hosted on a $40 digital ocean droplet performance is practically speaking indistinguishable from Github. No idea what gitlab.com is like, we picked gitlab because we could self-host.
  - m0zg 7y ago
    How is it maintenance-wise, BTW? How involved are the upgrades? I'm tempted to self-host, but don't want to go too far down the rabbit hole.
    - toupeira 7y ago
      The Omnibus package is very painless and internally uses Chef to apply configuration changes and data migrations. I maintained a (small) instance for a few years and never ran into any issues, all you need to do is upgrade the package through APT/yum etc. There's also support for zero-downtime upgrades [1] but I haven't tried it yet. [1] https://docs.gitlab.com/ee/update/#upgrading-without-downtime https://docs.gitlab.com/ee/update/#upgrading-without-downtim...
hn_throwaway_99 7y ago
I am not a GitLab user, so I'm not speaking from personal experience, but I've read more than a few comments here on HN that GitLab stability and performance is worse than GH. For a mission critical system like source control, stability and performance are more important than any other features.
- prh8 7y ago
  I asked about this in the Github thread, and it at least seems that Gitlab has minor issues but not the complete downtime that Github tends to have.
- emilycook 7y ago
  GitLab employee, this is somewhat of a drawback to how transparent we are about our issues. I know this might seem like I'm just trying to PR spin it, but it's a real phenomenon. We post about any little problem we have, and 99% percent of our Issues are public, so it probably seems like we have a lot of downtime and problems because of how often we talk about them
  - nerdwaller 7y ago
    Unfortunately the perception was earned a few years ago created not by running “more openly” but real user experience and breaking people of that experience over several months is a long uphill battle for GitLab. I’m involved with a large group of Python developers that echos the same feeling, even though generally speaking many of us find GitLab (performance and reliability aside) a better and more comprehensive product. I’d guess this was a consequence of a strategy decision that went against the plan (probably an expectation mismatch with users). I think the large part of the problem is the public GitLab instance is (was?) the beta environment, so a lot of issues popped up constantly while people were evaluating the options. In our group we are all volunteers, so when downtime impacts the little time we can dedicate (push code, review, deploy) it’s a fairly big deal. Our python group (pyslackers.com) runs in the open as much as we can, so for us we went where the exposure and ease to be involved is (Github), even though from a raw feature perspective we liked what we had on GitLab when it worked.
techntoke 7y ago
It is because GitHub employs a marketing strategy like Microsoft about selling something based on relationships but not product quality. They wine, dine and give kickbacks to those with the power to sign a multi-year contract.
sam0x17 7y ago
Things that make me not use gitlab (some of them are super shallow, stupid and relatively unfounded): 1. They used to use Azure, so even though I know Azure is actually an awesome cloud platform, I get this mental image of "Microsoft MVPs" constructing gitlab using VBScript macros because I come from the M$ era. 2. the very public data loss that happened a few years ago, that sounded like a mess, gives the lasting impression that repos are not lasting if they are in gitlab. 3. I never knew gitlab didn't just look like bitbucket, which I hate. In fact, I never would have looked at all if I wasn't writing this response, so I guess to get me they would have to lead with "Nothing like bitbucket!!" 4. I've spent so much time in github, that anything even slightly different pisses me off. 5. The logo looks like firefox porygon edition. GitLab is such a cool name, it could have a better logo, like the word "Git" followed by a chemistry beaker / "potion" thing. 6. The only marketing that would ever work on me would be "has an interface identical to github, does all the things github does, plus these 30 other things". Most of their marketing leads with the "30 other things", so I click away before I bother to read it. 7. If GitLab or anyone tried to do something innovative like writing an extended version of git that adds comments and pull requests to the underlying CLI, and bakes them into the repo itself in some way so we can just stay in CLI world all day, I'd be absolutely onboard, but no one does that for some reason even though that would be a huge differentiator. A similar strategy worked for Heroku if you think about it. 8. Every single open source project I use or contribute to uses github. If GitLab were to, say, add a github integration that lets me work with all the github repos I care about, but using Gitlab's UI, I would be intrigued.
- emilycook 7y ago
  > 8. Every single open source project I use or contribute to uses github. If GitLab were to, say, add a github integration that lets me work with all the github repos I care about, but using Gitlab's UI, I would be intrigued. This does exist: https://docs.gitlab.com/ee/user/project/import/github.html#mirroring-and-pipeline-status-sharing https://docs.gitlab.com/ee/user/project/import/github.html#m...
  - brodock 7y ago
    Depending on what you consider "work with github repos" here, you can import then as emily said above, and setup a push mirror, so whatever you do on gitlab is pushed back to Your fork on GitHub, so you can do PRs there. The way to interact between the two without this sort of functionality would be if both agreeded in some sort of federation access. I don't see GitHub allowing that anytime soon, as that would reduce their lock-in effect. We have an epic for Distributed Merge Requests: https://gitlab.com/groups/gitlab-org/-/epics/260 https://gitlab.com/groups/gitlab-org/-/epics/260 and an issue to discuss ideas about Federated GitLab: https://gitlab.com/gitlab-org/gitlab-ee/issues/6468 https://gitlab.com/gitlab-org/gitlab-ee/issues/6468

bdcravens 7y ago

A lot of the development ecosystem had integrations with Github, and haven't yet done so with Gitlab. Additionally, network effects matter, especially when if you add collaborators to your repo it's almost a given that they have a Github account.

GreaterFool 7y ago
I assume you're talking about CI? Not much more than that. But that only works in the most trivial cases. One repository, simple tests. I spent tons of time over the years always tweaking this and that to make whatever CI system we were using somehow work with GitHub. Lot's of setup, lots of trouble.
- bdcravens 7y ago
  Not just CI. Various bug trackers, project management tools, static analysis tools, etc.

m0zg 7y ago

Last time I tried switching to it it was slow as molasses on the command line. Easily several times slower than GitHub. So I went back to GitHub. I still have a GitLab account, but I only keep my dotfiles there. I keep hearing they've improved performance, and maybe they did, but that's also what I heard last time I tried it, so now I'm kind of reluctant to give it another try. Unlike before, now it doesn't just have to be "as fast", for me to switch to it, it has to be noticeably faster. Feature-wise it's easily on par already, but performance is also an important feature, and I don't think codebase being primarily in Ruby inspires a lot of confidence, especially if scale is growing. You're basically running it at 1/10-1/30th the speed it could run if a proper language were used.

lttlrck 7y ago
self-hosted on a $40 digital ocean droplet performance is practically speaking indistinguishable from Github. No idea what gitlab.com is like, we picked gitlab because we could self-host.
- m0zg 7y ago
  How is it maintenance-wise, BTW? How involved are the upgrades? I'm tempted to self-host, but don't want to go too far down the rabbit hole.
  - toupeira 7y ago
    The Omnibus package is very painless and internally uses Chef to apply configuration changes and data migrations. I maintained a (small) instance for a few years and never ran into any issues, all you need to do is upgrade the package through APT/yum etc. There's also support for zero-downtime upgrades [1] but I haven't tried it yet. [1] https://docs.gitlab.com/ee/update/#upgrading-without-downtime https://docs.gitlab.com/ee/update/#upgrading-without-downtim...

hn_throwaway_99 7y ago

I am not a GitLab user, so I'm not speaking from personal experience, but I've read more than a few comments here on HN that GitLab stability and performance is worse than GH. For a mission critical system like source control, stability and performance are more important than any other features.

prh8 7y ago
I asked about this in the Github thread, and it at least seems that Gitlab has minor issues but not the complete downtime that Github tends to have.
emilycook 7y ago
GitLab employee, this is somewhat of a drawback to how transparent we are about our issues. I know this might seem like I'm just trying to PR spin it, but it's a real phenomenon. We post about any little problem we have, and 99% percent of our Issues are public, so it probably seems like we have a lot of downtime and problems because of how often we talk about them
- nerdwaller 7y ago
  Unfortunately the perception was earned a few years ago created not by running “more openly” but real user experience and breaking people of that experience over several months is a long uphill battle for GitLab. I’m involved with a large group of Python developers that echos the same feeling, even though generally speaking many of us find GitLab (performance and reliability aside) a better and more comprehensive product. I’d guess this was a consequence of a strategy decision that went against the plan (probably an expectation mismatch with users). I think the large part of the problem is the public GitLab instance is (was?) the beta environment, so a lot of issues popped up constantly while people were evaluating the options. In our group we are all volunteers, so when downtime impacts the little time we can dedicate (push code, review, deploy) it’s a fairly big deal. Our python group (pyslackers.com) runs in the open as much as we can, so for us we went where the exposure and ease to be involved is (Github), even though from a raw feature perspective we liked what we had on GitLab when it worked.

techntoke 7y ago

It is because GitHub employs a marketing strategy like Microsoft about selling something based on relationships but not product quality. They wine, dine and give kickbacks to those with the power to sign a multi-year contract.

sam0x17 7y ago

Things that make me not use gitlab (some of them are super shallow, stupid and relatively unfounded): 1. They used to use Azure, so even though I know Azure is actually an awesome cloud platform, I get this mental image of "Microsoft MVPs" constructing gitlab using VBScript macros because I come from the M$ era. 2. the very public data loss that happened a few years ago, that sounded like a mess, gives the lasting impression that repos are not lasting if they are in gitlab. 3. I never knew gitlab didn't just look like bitbucket, which I hate. In fact, I never would have looked at all if I wasn't writing this response, so I guess to get me they would have to lead with "Nothing like bitbucket!!" 4. I've spent so much time in github, that anything even slightly different pisses me off. 5. The logo looks like firefox porygon edition. GitLab is such a cool name, it could have a better logo, like the word "Git" followed by a chemistry beaker / "potion" thing. 6. The only marketing that would ever work on me would be "has an interface identical to github, does all the things github does, plus these 30 other things". Most of their marketing leads with the "30 other things", so I click away before I bother to read it. 7. If GitLab or anyone tried to do something innovative like writing an extended version of git that adds comments and pull requests to the underlying CLI, and bakes them into the repo itself in some way so we can just stay in CLI world all day, I'd be absolutely onboard, but no one does that for some reason even though that would be a huge differentiator. A similar strategy worked for Heroku if you think about it. 8. Every single open source project I use or contribute to uses github. If GitLab were to, say, add a github integration that lets me work with all the github repos I care about, but using Gitlab's UI, I would be intrigued.

emilycook 7y ago
> 8. Every single open source project I use or contribute to uses github. If GitLab were to, say, add a github integration that lets me work with all the github repos I care about, but using Gitlab's UI, I would be intrigued. This does exist: https://docs.gitlab.com/ee/user/project/import/github.html#mirroring-and-pipeline-status-sharing https://docs.gitlab.com/ee/user/project/import/github.html#m...
- brodock 7y ago
  Depending on what you consider "work with github repos" here, you can import then as emily said above, and setup a push mirror, so whatever you do on gitlab is pushed back to Your fork on GitHub, so you can do PRs there. The way to interact between the two without this sort of functionality would be if both agreeded in some sort of federation access. I don't see GitHub allowing that anytime soon, as that would reduce their lock-in effect. We have an epic for Distributed Merge Requests: https://gitlab.com/groups/gitlab-org/-/epics/260 https://gitlab.com/groups/gitlab-org/-/epics/260 and an issue to discuss ideas about Federated GitLab: https://gitlab.com/gitlab-org/gitlab-ee/issues/6468 https://gitlab.com/gitlab-org/gitlab-ee/issues/6468