Any good alternative to GitHub?

Offtopic
1

The quality of GitHub’s services has declined significantly in the last few months (or longer?). Are there any good alternatives for hosting Julia packages?

2

Codeberg is a good place to start. I’ve actually wondered if the Julia package server would be able to integrate Codeberg-hosted packages rather than Github, but I presume that is a non-starter.

3

The main automation tool, Registrator.jl, currently only supports GitHub and GitLab out of the box, not Codeberg.

Can this be fixed?

4

I think Codeberg support would be great to have. A (probably incomplete) list of steps is something like:

  1. Add Codeberg support to GitForge.jl
  2. Add Codeberg support to Registrator.jl (specifically to the web UI, which is the same code path that we currently use for GitLab)
  3. Work with the JuliaHub folks to get the new version of the Registrator web UI integrated into the JuliaHub product. (The JuliaHub folks graciously host the Registrator web UI for us.)
  4. Check to see if any other tooling (AutoMerge, TagBot, etc) needs to be patched.
5
  1. PR at Add Forgejo support with live Codeberg validation · Pull Request #55 · JuliaWeb/GitForge.jl, which presumably needs someone who is capable of reviewing it.
  2. PR at Add Codeberg support to the Web UI · Pull Request #478 · JuliaRegistries/Registrator.jl. I guess the status is about the same.
6

oh that’s neat, I had assumed that it would be more involved than that.

7

Do any of the Github alternatives have similar levels of free CI? Obviously Github’s CI is rather flaky to say the least, but at least it’s free.

8

Self-hosted Gitlab on my end. Anything Microsoft touches turns to !@#$ (LinkedIn, Github, etc).

9

So yes, they offer free CI. No, it is different. For example, as far as I understand, only Linux test runners are offered by default; for anything else, you must provide your own test runners.

10

Interesting. GitHub does not just have the problem of declining service quality.

Copilot was controversial from day one because it was trained on public code. GitHub itself described Copilot as being “trained on billions of lines of public code” back in 2021. But the April 24, 2026 Copilot data policy change feels like GitHub stopped pretending this is not an AI data pipeline.

From 2026-04-24 onward, GitHub uses Copilot interaction data from Copilot Free / Pro / Pro+ users by default to train and improve AI models, unless users opt out. This includes inputs, outputs, code snippets, and associated context. (The GitHub Blog)

So if you are on Copilot and have not opted out, your Copilot interactions may be used for AI model training by default. Personally, I find this a pretty serious trust issue.

11

Right. I’m using Woodpecker CI myself, and I’m fine with the hosted CI being Linux-only.

But until the two PRs GunnarFarneback mentioned are merged, Codeberg-hosted packages still need manual registration in General, e.g. via LocalRegistry.jl.

12

Is that the same with GitLab?

13

GitLab is not exactly a saint either. Its current “good policy” is largely the result of past backlash and GitHub shooting itself in the foot.

GitLab has its own history with data usage. In 2019, it planned to add product usage telemetry to GitLab.com and some proprietary self-managed packages, involving third-party analytics services like Pendo and Snowplow. Unsurprisingly, self-hosted users and the open source community pushed back hard. GitLab then rolled back the related Terms of Service change on 2019-10-24 and said it would not enable user-level product usage tracking on GitLab.com or self-managed instances before re-evaluating the plan. After Sid Sijbrandij’s apology, GitLab further narrowed the scope to GitLab.com only, explicitly stating that self-hosted customers would not be affected. Third-party media also summarized the incident as GitLab walking back its telemetry plan after user pushback.

The AI side also has some history. According to GitLab’s own Terms of Use history page, GitLab’s early AI Functionality Terms (V1 – V2, 2023-08-14 to 2024-08-29) classified AI feature Input / Output as Customer Content, but still did not clearly say, in today’s wording, that GitLab would not use customer code to train models.

The more obvious backlash happened around 2024-04-22, in the Hacker News discussion on GitLab Duo. At the time, GitLab Duo’s FAQ said: “GitLab does not train generative AI models based on private (non-public) data. The vendors we work with also do not train models based on private data.” That wording only protected private / non-public data, so people immediately pointed out the obvious implication: public code might not be protected.

Then on 2026-04-20, GitLab used GitHub Copilot’s policy change as an opportunity to fire back. In GitHub Copilot’s policy for AI training: A governance wake-up call, GitLab’s wording became much stronger: it does not train AI models on customer code at any tier, and its vendors are contractually prohibited from using customer inputs / outputs for their own purposes.

So yes, GitLab’s current “we don’t train on user code” stance is a commercial strategy to compete against GitHub. Codeberg’s position, on the other hand, is an ideological choice rooted in free software and community self-governance.