GitHub vs GitLab

Haskell Foundation
#1

In the proposal-process thread, @f-a writes

I am extremely glad you chose gitlab — an open source and community owned space — for this.

@ketzacoatl responds

It might be nice to see if more of the Haskell community infrastructure can be moved to GitLab - so there isn’t as much of a split (pick one or the other platform). I guess at the least we can also write some docs on which groups are on which platform.

This is worthy of its own conversation, and so I’ve broken this one question out to this separate thread. Before looking at the choice to make, I want to lay out what I see as the salient differences between the platforms.

  • GitHub has far more users than GitLab. This suggests that usage of GitHub will attract more contributors, who would not have to create a new account (though GitLab allows login via GitHub credentials).
  • In addition, more users will find GitHub’s interface more familiar (though both are quite similar).
  • GitLab is open-source and self-hosted. We (in the guise of the Haskell Infrastructure Admins) control all the data on gitlab.haskell.org.

So, what do we think the HF should do? I see three options:

A. All HF resources on GitHub
B. All HF resources on GitLab (specifically, gitlab.haskell.org)
C. A mix

Right now, we have ©. Our motivation for this is that we prefer GitLab, but recognize that using GitHub has a lower barrier to entry. So, roughly, we have figured that repos expecting a lot of community engagement can go on GitHub, while repos with less community engagement (e.g. the meta repo) would be on GitLab. Yet, of course, splitting between the two is also potentially confusing and obfuscating.

I don’t think there are hard technical requirements here – it all comes down to what we think is best for the community.

So, community, what’s best?

7 Likes
#2

I like (C), and I like the way you’ve described the breakdown. Drive-by webpage edits via an “edit on GitHub” button is great. I don’t expect drive by process proposals.

8 Likes
#3

I prefer GitLab because it doesn’t require using proprietary javascript (they even seem to be moving towards supporting LibreJS). And GitLab has no hidden telemetry; my ad blocker has to block two tracking urls when I access GitHub (one of which even contains personal information which might be in violation of the GDPR).

GitLab also has drive-by edits and even a web IDE.

5 Likes
#4

My longtime concern with github for process stuff (never resolved) is that while github is “open” in the sense that anyone can clone a repo, there is lock-in in that migrating all tickets, prs, etc. off github is not as straightforward. I’ve advocated, on-and-off, using the git-annex tool (written in haskell!) to ensure that all that data is kept as well in servers that aren’t simply cloud infra provided by BIGCO. As long as stuff stays on github, I’d like again to encourage that this be set up.

If we’re ready to commit to keeping the github going long term and ensuring its continued maintenance in some form (using someone else’s hosted infra has its advantages, especially with limited resources) then I’d tend to want to encourage a gradual migration to the gitlab.

But I also think the current situation is not particularly awful or screaming out “I must be fixed” (outside of my concern about using git-annex to archive off-github all the tickets, prs, discussions, etc.)

3 Likes
#5

I’m curious what options exist for not just archiving but completely decentralizing issue tracking, PRs, etc. If anyone is interested, I once collected a list of links to decentralized issue trackers though I haven’t evaluated them yet.

2 Likes
#6

I would like to offer a data point in favor of choosing Github due to its popularity: personally, 99% of the projects I use or am involved with are on Github, and when I stumble on a project that is on Gitlab, I feel less inclined to use/contribute to it - it is just the first impression I have, coming more from emotional place than the place of conscious reasoning.

I understand the danger of Github having monopoly and the lock-in effect and that caring if project is on Github or Gitlab is silly if you are interested in a project, but what I described above is still the first, off-the-bat reaction I get in such situations, and it is likely some others also have it.

I believe this is due to the unknown UI that somewhat reminds me of Atlassian + me being used to all the popular big projects (that I know of / use) being on Github.
If I see project on Gitlab, I wonder why is it not on Github, and first thoughts I get is that it is because authors probably care about privacy / hosting the code on their own, which makes me feel like they are ready to sacrifice practicality / ease of usage for the reasons that I personally don’t find important in practice, and that negatively biases me toward the project.

To help with possibly profiling the users that might care about this: my background is C/C++, Javascript, Haskell, and a little bit of everything else, and some examples of the bigger repos are Spacemacs, React, Angular, Rust, Prisma.io, commercialhaskell, hlint, … .

So maybe Github + Gitlab is a good combination, since edge-facing projects on Github will be more appealing to newcomers and have lower barrier of entry, while core projects that anyway will not be so interesting to newcomers will be appealing to the more experience Haskellers which seem to prefer Gitlab.

7 Likes
#7

This is a good point against going all-GitHub :slight_smile:

When you arrive to a GitLab instance you’re usually one click away from using your GitHub credentials. Yes, there are differences in UI. But, as you said, one comes for a project, not for its hosting.
You wouldn’t flinch from the different room layout and wallpaper color while being a guest at somebody’s, would you?

#8

GHC has existed long before git, much less github. Though it seems hard to imagine, past history has shown that github will one day go the way of sourceforge or the like. I would like to imagine that GHC still will continue to exist well past that date. One does not want whatever occurred over the interval when github did exist to be lost and gone. What may not seem concerning to individuals in the immediate sense may well be important in the long scale over which projects should concern themselves.

Again, this is not a “don’t use github” argument – it is just to make clear that lock-in effects may have real problems that affect everyone, eventually.

4 Likes
#9

Despite the wording of my comment about this previouosly, I don’t have a strong opinion on GitHub/GitLab. I just think it would be nice to make it easier to navigate who/which project is where, or for it to consume fewer cycles in the contributor’s process.

#10

Sure, that makes absolute sense! I was really offering a perspective of a consumer of the repo, not maintainer.
On the other hand, Rust has its main repo on Github! How is that hm?
Go-lang is interesting -> they have main repo hosted on their own, but they have mirror on Github which seems to be used normally (issues, PRs).

1 Like
#11

Well that is a good question, but while colors are more about the taste and I personally don’t care much about it, I do have certain prejudices about repos on Gitlab vs Github. They may be wrong and unfair, and maybe I should work on dispelling them, but I wanted to share that point of view in case it might be relevant due to others possibly also having same prejudices.
And yes, if interest in project is significant, then it probably doesn’t matter that much, but often interest grows with time and the first time you encounter a project you don’t know yet and you are developing your opinion about it, and it that case it might matter, which is why I said this is most relevant for newcomers.
All of this stuff is very subjective and I am not trying to argue here that what I am saying is the truth, I am just trying to offer a different perspective from somebody who was still recently a newcomer and might have different views than experienced haskellers.

5 Likes
#12

GitLab may also support drive-by edits, but no one’s driving by.

Personally I find GitLab’s interface much more confusing than GitHub’s, and I can never find the thing I’m looking for, and that makes contributing much more painful, whereas most developers of open source (and commercial) code, for better or worse, know GitHub’s interface, workflows etc. well.

I agree that keeping anything that is likely to receive casual PRs from people wanting to fix things should stay on GitHub, because that’s where people go to find them. Infrastructure stuff, meta repos etc are fine to remain/move to GitLab, as long as there’s appropriate direction in any READMEs which might need to point to the GitLab repos.

6 Likes
#13

Is there any compelling reason to change the status quo, and justify this discussion? We don’t want to descend into bikeshedding and agonising over details at the expense of things that do matter.

2 Likes
#14

I agree with Ari, though I believe there is one good change that could come out of this discussion: There should be a page on haskell.org that helps us find the repos for core projects.

Which GitHub/GitLab platform then doesn’t matter, we can look at the docs to find what we’re looking for. As it is now, navigating the GitHub/GitLab split costs us time in finding what we’re looking for (sometimes we don’t even know what repo we’re looking for), so I believe a curated list (on haskell.org) of those projects/repos, would be a small but significant change.

3 Likes
#15

Strongly agree, I often have trouble finding the appropriate discussion venue for a given issue or proposal. Another function such a central resource might have would be to point out when one is supposed to post to a mailing list somewhere, rather than open an issue on a repo.

1 Like
#16

For decentralizing Git hosting itself, there is https://radicle.xyz - however it is still in its nascent form. I hope for the day wherein we can decentralize not only repo hosting, but also that of project tracking (issues), PRs, wikis, CIs, repo discovery, etc.

1 Like