give up github!

This commit is contained in:
Wouter Groeneveld 2022-07-06 16:28:20 +02:00
parent ae9612a669
commit 9bb5dbf8d5
2 changed files with 82 additions and 1 deletions

View File

@ -0,0 +1,81 @@
---
title: "Give Up GitHub!"
date: 2022-07-06T16:26:00+02:00
categories:
- software
tags:
- open source
---
_Give Up GitHub!_---a clear message that the Software Freedom Conservancy started spreading to open source software (FOSS) developers on 29 June via https://giveupgithub.org. Why? The whole story is available on their website, but the gist is that recently, GitHub yet again proved that they don't really care about FOSS, or about the privacy or licensing choices of their users. Their newest product called [GitHub Copilot](https://github.com/features/copilot) is "trained on billions of lines of code, GitHub Copilot turns natural language prompts into coding suggestions across dozens of languages.", as the landing page suggests. That is, they used _your_ code, with or without your consent, and while it used to be FOSS, now it's converted into a closed-source product you have to pay for. If you have a repository hosted on GitHub, I urge you to read what the Conservancy has to say about this.
I presume many of you have looked into leaving GitHub after the Microsoft acquisition in 2018. I did so too, but it was too hard, I wasn't in _that_ place yet, and didn't possess the needed knowledge of tools that could make the transition easier. I do now (a bit more), and after encountering the `giveupgithub.org` link at several places last week, I finally made an effort.
I left GitHub. The result is https://git.brainbaking.com/.
It's far from perfect, and it's not GitHub. The problem is that GitHub has become ubiquitous for `git`---our computing students think that GitHub _is_ git, while the power of it lies in its decentralizing capabilities, not its centralized ones. Still, GitHub has steadily added layers upon layers of superb user experiences such as:
1. A pleasant web-based UI to work with;
2. A boatload of repo-based statistics built-in with little effort to add more;
3. A boatload of yearly global statistics on popular tools, frameworks, and languages;
4. Continuous Integration (CI) capabilities;
5. GitHub Pages that can serve static websites;
6. Artifact release repositories with automatic storage;
7. The possibility to financially support repo maintainers;
8. Tools upon tools upon tools, such as GitHub Classroom which I do use for lab assignments;
9. Above all: a vibrant community.
What are the alternatives? There are a couple of viable options, but none of them offer everything GitHub has to offer (for "free!" if we forget that both our usage and code data is being processed for profit). **GitLab** is the main competitor to GitHub and is another "enterprise-level" heavyweight that aims to provide as much functionality as possible. I have limited experience with it, but I've encountered many rants of other users complaining about the speed and amount of weird bugs. Without self-hosting such an instance, in a few years, it'll become the next GitHub, so no thanks.
**[Source Hut](https://sourcehut.org/)** is a "hacker's forge", they claim---the next Source Forge, yay! Remember what happened with Source Forge? It suddenly went closed source. People fled. It died. Right. Anyway, Source Hut seems to come with a lot of interesting features such as powerful CI features, including SSH access. What's more, it doesn't require contributors to register an account. Patch reviews and issues can be discussed using mailing lists. As for where it's hosted: somewhere in the US, `sr.ht` is a LLC. I'm all for mailing lists when interacting with hundreds of developers, but for my own small projects, it seems overkill, and the UI is less intuitive than Gitea-clones.
**[Codeberg](https://codeberg.org/)** is essentially a Gitea-powered hosted solution that welcomes free software and is a German non-profit organization with servers hosted in the EU. At the moment, CI integration---one of the prime reasons for me to lean towards a hosted solution---is very wonky and based on a fork of Drone. What eventually turned me to other solutions is the weird https://join.codeberg.org/ page where "dues" (financial membership support) have to be selected. I don't mind paying at all but that page feels confusing (read: amateurish) and if at the time of writing Codeberg offers little extra besides a Gitea instance, I'll pass.
**[Gitea](https://gitea.io/en-us/)** is "Git with a cup of tea", or "a painless self-hosted Git service" (there are hosting options available). It's essentially a single binary that'll get you setup in no-time, provided you choose SQLite as your back-end database (again, other options are available). THe UI is obviously inspired by what GitHub does. The downside is that Gitea is a Git server coated with an easy-going UI---it's not a statistic generator, CI server, artifact repository, ... So yeah, I do miss that: now I have to install a Drone instance that builds and runs my Go tests.
---
I have two Gitea instances running: one on our internal NAS, and one on our external VPS. I initially didn't want to install a second one but the VPS needs `git` access to my sites as part of the build workflow. The VPS is essentially a web server, not a source code or integration server, and mixing responsibilities is never a great idea. Yet it still had ample juice left and since my projects are neither rocket science nor very popular, I figured I'd spin up a second Gitea instance. It currently holds about `820 MB` on data, which is still manageable to backup. A tarball is pulled weekly from the VPS into the NAS---that's good enough, as most important repositories are checked out anyway on different computers here.
The biggest downside of giving up GitHub---and especially self-hosting---is that you're essentially leaving (yet another) social media. How are potential contributors going to find you? GitHub is explored, scoured, and rummaged through daily. Source Hut and Codeberg are doing their best to build a community. Federated Gitea systems do not exist, and by that I don't mean the `git` protocol itself.
Suppose you want to create a new issue on my Go-Jamming repository, at https://git.brainbaking.com/wgroeneveld/go-jamming/issues. You press "New Issue" and are redirected to the sign-in page. But I don't want you to create an account, and you're likely to pass up on that too. After a bit of config file fiddling, I managed to enable OAuth2 and "Sign In With GitHub". That way, you can simply use your existing account to interact with my source repositories, even if those aren't hosted on GitHub anymore. Behind the screens, Gitea automatically creates a user in its local DB and links your GitHub profile to it.
It required the following alterations in `/etc/gitea/app.ini`, after scanning the [Configuration Cheat Sheet](https://docs.gitea.io/en-us/config-cheat-sheet/):
```
[service]
REGISTER_EMAIL_CONFIRM = true
ENABLE_NOTIFY_MAIL = false
DISABLE_REGISTRATION = false
ALLOW_ONLY_EXTERNAL_REGISTRATION = true
ENABLE_CAPTCHA = false
REQUIRE_SIGNIN_VIEW = false
[oauth2_client]
REGISTER_EMAIL_CONFIRM = false
ENABLE_AUTO_REGISTRATION = true
[openid]
ENABLE_OPENID_SIGNIN = true
ENABLE_OPENID_SIGNUP = true
```
Then, add an Authentication Source in your Site Administration panel (type OAuth2, protocol GitHub), and register a new app at https://github.com/settings/applications/new to acquire a Client ID and Secret. If you carefully follow the instructions, it should work out of the box, provided the above `oauth2_client` settings were added.
Another thing I modified was increasing the maximum upload size:
```
[attachment]
MAX_SIZE=5000
```
That alone won't cut it if you're using Nginx as a reverse proxy: also add `client_max_body_size 50M;` in-between your `server {}` definition. This allowed me to upload a release binary, like Go-Jamming v2.0.2 at https://git.brainbaking.com/wgroeneveld/go-jamming/releases/tag/2.0.2. GitHub does this automatically based on CI Workflows. There's an API available, but I haven't set up a CI just yet. I wonder if it's worth all that trouble (and extra load) for just a few small repos. Ideally, I'd hire another VPS to separate web server from CI/Git server concepts. Again, we'll see.
---
Migrating the repositories themselves was dead easy: `git remote set-url origin ssh://git@brainbaking.com/wgroeneveld/go-jamming.git` and `git push`. Done. (Don't forget to adjust custom SSH ports accordingly) I chose to be radical and deleted a lot of older repositories at GitHub and archived the more popular ones with a link to the new URL. For me, there's no need to add a second remote URL and work in mirror mode.
I guess it'll be up to me now to promote my own coding work, instead of letting GitHub/Microsoft do that. Oh noes, all those lost stars and followers! What shall I do?
Yo check it out: https://git.brainbaking.com/. Contributions welcome!

File diff suppressed because one or more lines are too long