Hacker News new | past | comments | ask | show | jobs | submit login

Probably because Github is a closed-source company that can remove you, your repo, or your group at any time, for any reason. Committing to a hosted service is a bad idea (see: Sourceforge). That sort of thing isn't acceptable to a project like Gnome.



To be clear, despite this announcement being posted to gitlab.com (i.e. the "hosted GitLab", which can and will remove you/your/repo any group at any time), the GNOME project is self-hosting their own gitlab instance. So they are indeed insulated from such hypothetical damage.


And will? Are there examples where Gitlab removed users / projects for controversial reasons?


That's not the point. No matter how trustworthy Gitlab seems, The GNOME Project is still more trustworthy.


You'll get no argument on that from me. The way he phrased it though made it sound like this has happened in the past, and I was curious.


I would be shocked if there were not DMCA take-downs that left some people feeling raw - honestly how can you avoid that - but this sort of thing does not attract much notice these days.


Hate to bring up gamergate, but a project related to the movement was completely taken offline by a rogue github employee.

There are a number of sources, all of them biased, so I'd prefer not to link any.


> Probably because Github is a closed-source company that can remove you, your repo, or your group at any time, for any reason.

Any company providing a hosted service can do that, including Gitlab (the company) itself. They chose Gitlab (the product) because they are able to host their own instance (edit: and it’s open-source), that’s all.


Just curious, has this ever happened? Were there any cases where github removed someone's repo?


Yes, WebMConverter. However, I gather the employee responsible is no longer with them.


The C+Equality programming language was removed.


GitHub removed a Shadowsocks library after being targeted by China's great cannon.


PopcornTime I think got removed.


I feel like this is unfortunate. Github has a giant user-based, and using github would be a great way to reduce the friction of having first-time contributors submit a pull-request.

In my case, if KiCAD were hosted on github, I would have already contributed by now.

I think its a shame that more of these projects don't adopt a strategy of "let's try github, and if they screw us over, then we'll migrate to a platform with more freedom".


I think it's shame that lot of projects do. Why?

1.) Compared to Phabricator (which I used for almost last 4 years), github is really behind for code review (I didn't use gitlab, so can't compare). There is lot of missing features: I can't comment on selection of lines, see diff of subset of commits, do stacked pull request (one PR depends on another PR), view of open pull request is chaotic

Effect is that it's way harder to send small PR for review, unless you work on lot of unrelated things and multiplex.

2.) Github dominance is causing everybody using git, and stiffs competition in source control tools. For example, I find mercurial much better than git: it has similar set of features, but it's easier to use, my day-to-day chores I do with single command, and I am much less likely to screw up my repo.


Funnily, I ditched hg the moment it screwed my repo. But even then I was pretty sure git would win, and not for PR reasons.


> In my case, if KiCAD were hosted on github, I would have already contributed by now.

I suppose it's useful never to underestimate the role of culture and tradition when it comes to these things. For the Gnome project, it's probably very important not to rely on a closed-source system, and their developers have a long history of using very different tools anyway.

The barrier doesn't work that way for everyone, either. I "grew" up (programming-wise) before Github. It seems way less cumbersome for me to make changes and submit a patch via email or whatever than to go through Github's fork the repo - do the changes - make a pull request - sync the repos dance.

(Edit: this is especially true for early contributions, or for late and complex contributions, where the review process is a little more, you know, long-winded. Github's review tool is quite atrocious.)

> I think its a shame that more of these projects don't adopt a strategy of "let's try github, and if they screw us over, then we'll migrate to a platform with more freedom".

That's a really risky thing to try. First, moving the entire infrastructure to Gitlab has been a pretty massive undertaking for Gnome -- and Gnome is one of those open source projects that really has resources. Most projects with Gnome's size and history can maybe afford to do that once every seven years, when there's a relatively quiet time and whatnot.

Second, you never really know how that "screw us over" thing is gonna happen. What if the way it happens is that, among other things, when they close your repos or whatever, they cut access to the API for your project? How are you going to migrate to a platform with more freedom then? Copy-paste every bug report ever?

IMHO, 10-15 years from now we'll be really happy that Gnome really understood that "there's no cloud, it's just someone else's computer" thing :-).


Github has dabbled a bit too much in politics in recent years TBH. It doesn't surprise me that projects like GNOME would take pause at that, among the other reasons people are listing.


When my company was evaluating open source cms/hosting solutions, Github was quicky removed from the list of candidates for this very reason. Their criteria for removing software projects was deemed too unstable to depend upon, and the company is too small to garner the same respect from github as bigger companies.


I can’t agree enough.


Possibly more important than any practical implications of GitHub being closed source is the simple fact that relying so intimately on a closed source product would be a really bad look for them, on account of what the first letter in GNOME stands for.


By committing to use GitHub, you’re only really committing to git. git supports multiple remotes for the purposes of mirroring — use that feature.


> you’re only really committing to git

You don't use github just for git.

You use it for issue tracking, pull requests and code review, CI hooks, wiki, github pages, kanban boards, bot integration, and so on.

That's all stuff that locks you in to Github, and is non-trivial to migrate to another provider.


It’s a given that the more GitHub features you use, the more difficult it is to move away from GitHub. It’s also a given that you can reasonably limit the extent to which you use GitHub and thereby limit the difficulty in transitioning to another solution.

The idea that it’s GitHub locking you in rather than you locking yourself in to GitHub is the argument I take issue with. But no quarrel at all with Gnome choosing GitLab, because GitLab is genuinely great.


The whole reason GNOME wanted to switch is because they wanted to have all the extra features (issues, etc) in a single place, as is provided by Github and Gitlab. Their old cgit interface already did a good job at hosting their git repositories.


> "You don't use github just for git."

Well, some people do. I don't, apparently you don't, probably most people don't. But you could and some people do. I've seen a few projects on github with notes to the effect of "don't bother submitting issues/PRs here, do it through our [mailing list/etc]"


The Linux kernel for example.


The kernel is just mirrored on GH, which is why they want PRs and bug reports sent to their mailing list.


And, with a whiff of irony, git itself.


Why is this ironic? Git predates github.


It's logical of course, but I see the irony. Or maybe it's not irony, nobody really knows what irony is, but it's mildly.. amusing? It makes half my face smile in a manner similar to but not quite like a smirk.


Is the Git project expected to uproot themselves and go chasing Github or Gitlab or Gogs or whatever else is fashionable?


Definitely not 'expected'. I like the mailing list bug tracking more than having that on git{hub,lab,whatever}.

git makes it even possible to host a repo on multiple git* hostings, but apparently nobody came up with a successful distributed pullreq/issue tracker yet.


Of course not.


Or Git itself


> By committing to use GitHub, you're only really committing to git.

Make sure you also tell your users not to use GitHub's comments, issue tracking, pull requests, release system, favorites/watches, or authentication.

So you're suggesting that the new home for the GNOME project's code be GitHub, without the GitHub.


Issue tracking is optional, if you disable it users wont be able to fill issues. You can easily ignore release system (by not using it) and I am not sure what you mean by authentication. As for pull requests, it is reasonable to expect contributors to submit them wherever your readme points to.

I don't mean to say that gnome should use github, I think that it is overall better if there is no single dominating company for open source. Just that organizing so that github is git hosting only is not that hard.


The whole point of the migration was to consolidate things to make onboarding new contributors easier. If they only used the git part of github, it would be little better than their existing cgit setup.


I don’t understand where in that comment you believe I suggested that the Gnome team should have chosen GitHub. Most likely because I made no suggestion.

Please try to be more careful with how you approach reading comments.


Gnome is already being mirrored to Github. You can do your pulls from there.

Meanwhile, they want to use the bug tracker and other features too.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: