Personal Log »

Moving to GitLab

I have never liked the idea of centralising too many open source projects in the same hosting service. It didn’t go well long time ago with SourceForge and, over the time, I have seen GitHub going a similar route. Then the Microsoft acquisition happened, and I thought that it was unlikely things would change immediately. It is human nature to be lazy, I guess; so I didn’t do anything –because there was no reason, really–.

It has been almost three years, and in reality things haven’t changed much. GihHub has been involved in several controversies over the years, but none of them was enough to make me leave the service, because the network effects are too strong: everybody is in GitHub, a lot of important open source happens there, and the social aspects work because everybody is there.

The last controversy is the launch of a technical preview of GitHub Copilot, that is a machine learning powered autocomplete tool:

GitHub Copilot understands significantly more context than most code assistants. So, whether it’s in a docstring, comment, function name, or the code itself, GitHub Copilot uses the context you’ve provided and synthesizes code to match.

The tool has been fed billions of lines of public code, and in theory it synthesizes the code snippets and should never provide verbatim code, but there is an obvious concern here regarding open source and licenses. Open source doesn’t focus only on having access to the source code, it is the distribution terms what really makes it relevant. The fact that Copilot may not respect the licences is both bad for the original projects and the users introducing code in their own products without permission.

So it is complicated and, in my opinion, what is decided here and now about this matter –and in similar situations related to machine learning–, it will shape how these technologies could change our world.

Perhaps this is not enough to decide to rely less on GitHub, but it is yet another thing, and I have decided to move to a different service that perhaps may be better aligned with my philosophy, and at very least diversify and stop contributing to the centralising trend.

I know I’m going to lose things, specially regarding the social part of the hosting service, because I won’t have stars in my projects –or not that many– to measure popularity, and possibly not that many contributions –although I had close to zero anyway–, but at least functionality wise I’m aiming to have the same.

There are a good number of hosting services for open source projects, and most of them tick all my boxes.

  • SourceForge: under new ownership, the bad practices seem to be gone.
  • Launchpad: if I can be blunt, I don’t like Canonical. That’s a story for a different time.
  • Bitbucket: I like this one a lot as well, I use it for some things –including private repos–, but perhaps it is too close to GitHub ethos.
  • Sourcehut: very promising service, although it is a bit too different.
  • Gitea: and others. You can self-host this, but I don’t want to do that for now. Equally, you can find instances of these that accept external projects.

Finally I have decided to give GitLab a go. And I’m not saying that I have fully read (and understood) GitLab’s ToS, and I haven’t compared it with GitHub’s ToS, but the fact that you can download and have a self-hosted version (and it is developed in the open) is something that I like a lot.

For now I have moved two projects that I’m working on actively:

  • ubox MSX libs: as basic as it goes, git hosting and perhaps will be using issues as well.
  • Spacebeans: this one uses more features, including CI. Will write a post about that!

I hope this decision doesn’t disrupt too much anyone using these –the MSX libs in reality, nobody cares about my Gemini server–, and I know this is not changing anything in the great scheme of things, but there you go.

Would you like to discuss the post? You can send me an email!