Hacker News Reader

Comment by rvz | Hacker News Reader

> Host all OpenJDK Git repositories at https://github.com/openjdk/.

Good choice from moving to Git [0], very risky move on moving to GitHub. If this was just a mirror then that would be fine but it is moving from Mecurial to Git and then the whole project to GitHub.

They should do what Xfce, GNOME and KDE have done and they have self-hosted their own repositories on Gitlab, which GitHub requires the Enterprise Edition for self-hosting. Not really an option, unless you want to pay for this.

The risks outweigh the pros for GitHub as I have said before [1] and will say it again. Self-hosting over 'centralising everything' on GitHub.

[0] https://openjdk.java.net/jeps/357

[1] https://news.ycombinator.com/item?id=23849565

View on HN

Gitlab’s community edition is a frustrating experience.

We created our private instance in 2012 or so, when Gitlab was bot looking for world domination and the entire project was promised to be open source forever, and they were gonna make money off the hosted service and support contracts.

Well, then the VC money hit and now navigating through basic features can be a confusing mess.

So after many years they released merge request reviews to the community edition. This would be great, except you don’t get access to enforcement. So the approval is a purely decorative feature (that would be as easily achieved earlier by simply having any approved hit the button).

To be able to develop any sort of collaborative project you have to install the proprietary version and at that point you’re hardly better off than Github except you’re paying more for less (although I’m not exactly sure of Github’s on prem pricing but the hosted Github is way more bang for the buck than either the hosted or on prem Gitlab). Gitlab also recommends installing the Proprietary edition and using the “free” tier over the community edition so you can upgrade to the paid features, which you cannot on the community edition. So if you don’t want to be blocked in the future you’re installing the proprietary version anyways.

And going with Gitlab you’re also rewarding the scammy bait and switch they pulled some years ago (I’m not sure when this changed because I stopped working with the company I setu it up at, but you can see the archive.org look at their website for the different focus earlier, and the off website messaging was also very different).

I work on OpenJDK. Here are some steps we've taken to not overly depend on GitHub:

1. Issues stay on a self-hosted JIRA.

2. All PRs get an automatically generated patch that's posted to the mailing list, and all comments are two-way mirrored between GH and the mailing list.

3. All links to commits in issues don't point directly at GH but at an indirection through our domain.

4. All bots work on both GH and GitLab

This means that we can move off of GH pretty much instantly if the need arises. But self hosting with GitLab just wouldn't serve our goals. We want speed all around the world, and we don't want to spend resources on administration.

Totally agree. Wasting time on infrastructure like self hosting gitlab to be less reliant on Github is not always a good idea.

If your project is setup in a way to just git push to another remote and then you're done, then I think it's fine to use Github.

Issues stay on a self-hosted JIRA. It's really sad as you will have order of magnitude less contributions on jira. Couldn't you autosynchronize github.com issues to jira ones? Otherwise, you're hurting the ecosystem as a whole

I do think it's an important concern, even though I absolutely love Github. Most importantly though, `git` is not centralised, and no service like Github, no matter what it does, can ever stop the decentralisation, roll-your-own-ability, or forkability of open-source software.

So probably it's OK for now for the majority of the community to use MS's platform Github, because other options exist and it's not hard to move to them or create new ones at any time. Github doesn't own our brains, nor can it do any harm to the powerful GNU GPL.

While you are right, there is more than just the code. In general one should be wary for lock-in when sculpting their development processes around the features that GH offers, i.e. the Issue tracker, Projects & Teams, Discussions and not to forget GH Actions. And besides that there is FOMO for many projects to leave GH due to its popularity. Does your contributor base move with you to another platform? Is it as easy to find new contributors, or even to find the project itself?

..which is why I am somewhat convinced that Github single-handedly increased participation in OSS by orders of magnitude.

I never figured out the processes to submit patches in the dark time of sourceforge and mailing lists. Since Github standardized this, I frequently contribute.

I agree with that and I have the same experience however it's important to also recognize the dangerous of the centralization and vendor lock-in not only the convenience.

Hence why running own infrastructure and mirror to Github makes a lot of sense for bigger open-source projects.

Yes, I agree. But I think the GH dominance can become something of a problem, similar to other big tech near-monopolies.

I hope for more decentralization of forges in the future in a more open market, and I have my eye on ForgeFed as means to achieve that.

https://forgefed.peers.community

For the record, I have the complete opposite experience. It used to be possible to just e-mail someone a description of your code fix, with a diff output inlined or attached. Nowadays, when I try that, people ignore the code you wrote and say “No, please patch is a git patch” (actual quote), or they require a pull request on GitHub. (I don’t have an account on GitHub, and I seriously doubt that I’ll ever get one.)

My experience is that they want even more, an actual pull request. And when you do submit it as a PR, they want you to go back and "rebase" over latest again. For someone thats not so familiar with the process it's intimidating.

>>> Most importantly though, `git` is not centralised

Not the most important thing... Basically all project I work on still relies on a "central peer" ...

I would be more sympathetic to this position if GitHub allowed user-provided domains as CNAMES; and I mean in both directions: redirecting you off github.com to the user's domain name, allowing true federated independence from the centralized platform. Without this feature, the argument is nonsense: you may as well be making the same claim about any other hosting service, as you can almost always pick up your content and put it somewhere... the question is how to update the hundreds, thousands, or even hundreds of thousands of links to your content once you decide to (or are forced to) migrate :/.

As much as I hate that the web, like many memory unsafe languages, permits dangling pointers, I feel like it would be a huge phishing/open redirect/some other web security buzzwords if this happens. Plus, can you even CNAME a specific URL (as opposed to redirecting it)?

I don't understand what "CNAME a specific URL" means. (If you are thinking "can this be done in any reasonable way without GitHub adding the feature", the answer is "no": they would have to provide the feature on their end, to provide the right content given the right hostname, the same way many other companies have over the years, including Medium, which is but one of many possible specific examples I mostly bring up as I hear they recently stopped allowing this and it has correctly made people say others should no longer use the platform due to URL lock-in.)

I'm talking about CNAME, which as I understand lets you do something like "saagarjha.github.com" → "saagarjha.com" but not "github.com/saagarjha" → "saagarjha.com". Of course, GitHub would need to support this on their end, but I don't think the second is possible using CNAMEs, which is what you would really want?

Why is it risky?

I followed your link, which said that projects can self-host. True. Oracle can self-host if they want to. Should they want to?

I followed your link in that one, which says you should self-host to avoid GitHub-related downtime. So does the next link in the recursive trail, and most of the ones in there. It's true that if you aren't on GitHub, you'll avoid GitHub-related downtime - but how much downtime will your alternative incur, and what is the cost of the staffing needed to reach that point? And what is the downside of being unable to access GitHub briefly for a project like this, such that it becomes worth investing in that staffing?

There's this reply to your comment that I see you didn't reply to: https://news.ycombinator.com/item?id=23818307

> I used to help maintain Xfce's svn and then git server. I'm not going to say it was hard, but it was work, and it was work that took time (time that was volunteer free time) away from working on Xfce itself. [...] That was a foolish attitude that took time away from the actual goal, which was making Xfce better.

I will certainly agree that you should not host your primary website on GitHub; there are services that are designed for reliable website hosting. For something like Java, I'd also say you shouldn't host your releases on GitHub. But Oracle Java remains on Oracle's website, and OpenJDK binaries aren't hosted on GitHub - AdoptOpenJDK's website is behind Cloudflare.

I do also think people should have a strategy for moving off their code hosting provider, including making backups of things like issues/pull requests. But that applies even if (perhaps especially if) you self-host, and I don't know anyone who actually does that, regardless of provider. If you're just interested in the code itself, the nice thing about git is that every developer's laptop is an effective backup, so you can put off figuring out a business continuity plan until an actual problem arises.

A few links in (https://news.ycombinator.com/item?id=23102942), you seem to claim that GitHub is insecure because Microsoft's org account was "hacked". It turns out that one account belonging to an MS employee who was a member of that org was broken into https://www.zdnet.com/article/hacker-gains-access-to-a-small... . That risk doesn't seem particularly fundamentally different with self-hosting, since the attack was on the user account, not the service itself.

One link beyond that (https://news.ycombinator.com/item?id=23057769), you point out that you'd need to trust GitHub not to snoop on your private data, which is true, but irrelevant in this context.

Let me be clear - I am not an advocate of moving things to "the cloud" / hosted services for its own sake, and in fact, I believe that most of the time, people are better-served by putting a couple of servers in colo than by using some public cloud service. (My own employer runs an internal GitLab instance and spends a decent bit of staff time on keeping it operational and upgraded, and I think that's a great idea for us and for our needs!) But that's because I believe it's actually better for them to do so. I don't see the argument that people are actually better off running their own git hosting for open-source projects, in general.

Reply on news.ycombinator.com