I'm pretty sure the actual forge we deserve at this point is one that is a membership organisation, eg, owned by its (paying) members.
Members elect the board which chooses the CEO. A cooperative, in other words. The tech is a solved problem, with lots of open source around to do it. Enough members means paid operations and development staff, or outsourcing one or both, or grants to open source devs, etc. The possibility is there.
That's how we prevent cultural drift: by actually controlling the company.
I personally just self-host. The project that I'm working on right now uses Gitea internally with an action runner.
I use Digital Ocean and run a Nomad cluster on top of that. Gitea and its action runner builds container images and then pushes nomad job definitions to the cluster. I have zero downtime deployment and rolling deploys. Dagger.io is in there somewhere to make local CI mirror what happens in the action runner.
Setting up Gitea was honestly just an afternoon of work. The sqlite database is backed up to Cloudflare R2 and the code is mirrored. It's unlikely that my project will take off to the point that I'll need to upgrade Gitea to something else, but it's extremely easy to setup, maintain, and build CI/CD on top of.
It seems ironic, that in the social media space, AT protocol based instances are basically centralised (Bluesky) and ActivityPub based instances (Fediverse, Mastodon) have a much healthier grade of federation.
Whereas in the "forges" space, it seems Tangled drives federation forward much faster than the ActivityPub-based federation features of Forgejo/Gitea (which are progressing really slow).
Tangled and Radicle are both really cool, but add too much mental gymnastics compared to just running Forgejo.
What I like about (the idea of) ForgeFed is that it lets existing forges speak to each other.
In practice I probably just need Forgejo and GitLab to be able to speak to each other.
I believe the future of GitHub, for me, is to solve two problems:
- Discoverability for public open-source projects
- Backup since self-hosting is fragile long-term
So many times when I try to visit the source code of some package uploaded to crates.io, the self-hosted git no longer exists.
GitHub repos sit stale for decades.
For day-to-day reliance, my self-hosted Forgejo and CI runners have better uptime.
Only pet peeve with Forgejo:
- It's a highly active project, RFCs, tons of PRs and issues.
- Becoming a daily user, I want to extend it, and in its beautiful simplicity, it's not highly extensible.
- So to avoid maintaining a fork of a very active project, extending it in unison is a social commitment.
What a luxury problem, but still.
I'd like to see more hosted Forgejo solutions pop up; it's very low-resource cost.
Very timely as I just set up Forgejo yesterday. There were immediate unexpected benefits moving off GitHub. It’s hosted on an Orbstack VM on a Mac Mini M4 on my local Tailscale network and the UI is incredibly snappy and quick to browse. Because it’s located inside my tailnet with no public access I don’t need to setup authentication, so agents running inside our network can clone a repo with no fuss (I just protect master branch pushes with a config rule). Github auth is a pain to securely distribute, when you self-host the problem just disappears. Also because it’s running inside our tailnet we can use Forgejo actions for infrastructure-related tasks: Ansible scripts that provision or maintain Mac Minis or Linux servers on the same tailnet over Tailscale SSH. Much simpler than Kubernetes which would be overkill for a small homelab/startup. And the Orbstack VM is literally two clicks to backup and restore or move to another host — I setup the VM running Forgejo on my local MacBook then a few minutes later exported the VM image and transferred it to a Mac Mini server in a few clicks. Backup and restore an entire server to a single file — that is the fastest and easiest server migration I ever performed. I literally can’t think of a single reason I would want to go back to GitHub. Forgejo is a joy to use.
I am indeed aware of them! To the best of my knowledge (please correct me if I am wrong) it's not actually usable functionality today and has been WIP for a long time, so it seems somewhat hypothetical. Their Mastodon account hasn't posted in over a year.
I really don’t see the benefit of forge federation. Why do people care that completely separate projects run in completely separate forges?
A project’s issues and pull requests are only useful for that project.
The author mentions avoiding multiple logins and searching across forges. The former is already addressed by social logins / federated identity. The latter is not very useful today, on a centralized GitHub, aside from finding leaked credentials and vulnerable code.
In fact, the tiny barrier of entry for contributing in a new forge might be a desirable quality, to filter out low-effort contributions.
You can accept issues and pull requests from users of other forges without requiring or even allowing new account signups on your forge.
I'd like it if people could contribute to the projects I host on my own personal GitLab, but not enough that I'm willing to deal with open registration.
> The author mentions avoiding multiple logins and searching across forges. The former is already addressed by social logins / federated identity. The latter is not very useful today, on a centralized GitHub, aside from finding leaked credentials and vulnerable code.
Absolutely not. Social logins are unacceptable and I refuse to use sites that depend on them and do not provide a normal method to make an account.
Ideally projects like this can bring us a model where you don't need to login to some other forge to interact with a project but do it by forking it onto your own forge and submitting pull requests between forges.
I've switched my git projects to push their objects into IPFS and their refs to pkkarr. That feels more distributed than the sorts of HTTP servers mentioned in TFA.
Anybody who cares about my repos potentially disappearing can contribute to their hosting by re-providing those repos from their own machines. (Note that only someone with the private key can create new records for a pkarr address).
That's mostly a side-benefit though: I mostly wanted something I can `git push` and `git pull`, that is self-hosted, and self-organises across a bunch of underpowered machines with unreliable network connections, with minimal coordination.
I'm currently looking to piece together a kubernetes native "forge" and there are major gaps in the ecosystem. Why do we need everything in one application like every single "forge" claims to be? What about when I want something that's not supported.
How about Forge compatible components? Or forgeables? Naming is hard but hopefully you get the point...
I'm an expert, I'll go to harbor freight and weld some stuff together. It will still break down in 5-10 years but maybe I will at the very least have some control over the way I pivot.
Overly naive. Most OSS projects need the CI to be free.
The issues/pr's/discussion are easily put elsewhere. We did that a couple of times already.
The CI also, as it worked fine before Github took the free Azure offer/testbed to add actions. But since Azure stepped in, all others stopped offereing their free OSS teers, just not Cirrus and Appveyor for Windows-only.
We can wait if the totally incompetent MS management can fix Azure (they cannot, as they have no idea. But they shouldn't block their devs/admins, as they did before), and only then move off.
23 comments
[ 2.5 ms ] story [ 43.5 ms ] threadI don't think it would take years for an AI first platform to enshittify, it would be instant.
* https://forgefed.org/
AFAICT there is no actually-existing ForgeFed instances that I could use today, but I'm keeping an eye on it - let a thousand flowers bloom :)
Members elect the board which chooses the CEO. A cooperative, in other words. The tech is a solved problem, with lots of open source around to do it. Enough members means paid operations and development staff, or outsourcing one or both, or grants to open source devs, etc. The possibility is there.
That's how we prevent cultural drift: by actually controlling the company.
How about some non-Git forges (like Mercurial forges)? That's what I'd like to see.
I use Digital Ocean and run a Nomad cluster on top of that. Gitea and its action runner builds container images and then pushes nomad job definitions to the cluster. I have zero downtime deployment and rolling deploys. Dagger.io is in there somewhere to make local CI mirror what happens in the action runner.
Setting up Gitea was honestly just an afternoon of work. The sqlite database is backed up to Cloudflare R2 and the code is mirrored. It's unlikely that my project will take off to the point that I'll need to upgrade Gitea to something else, but it's extremely easy to setup, maintain, and build CI/CD on top of.
Whereas in the "forges" space, it seems Tangled drives federation forward much faster than the ActivityPub-based federation features of Forgejo/Gitea (which are progressing really slow).
What I like about (the idea of) ForgeFed is that it lets existing forges speak to each other.
In practice I probably just need Forgejo and GitLab to be able to speak to each other.
I believe the future of GitHub, for me, is to solve two problems:
So many times when I try to visit the source code of some package uploaded to crates.io, the self-hosted git no longer exists.GitHub repos sit stale for decades.
For day-to-day reliance, my self-hosted Forgejo and CI runners have better uptime.
Only pet peeve with Forgejo:
What a luxury problem, but still.I'd like to see more hosted Forgejo solutions pop up; it's very low-resource cost.
https://forgefed.org/
Anyone remember that? It used to be such an important website and went down the tubes.
I'm not against VC funding everywhere, but I don't want it at the core of my development stack.
A project’s issues and pull requests are only useful for that project.
The author mentions avoiding multiple logins and searching across forges. The former is already addressed by social logins / federated identity. The latter is not very useful today, on a centralized GitHub, aside from finding leaked credentials and vulnerable code.
In fact, the tiny barrier of entry for contributing in a new forge might be a desirable quality, to filter out low-effort contributions.
I'd like it if people could contribute to the projects I host on my own personal GitLab, but not enough that I'm willing to deal with open registration.
Absolutely not. Social logins are unacceptable and I refuse to use sites that depend on them and do not provide a normal method to make an account.
Ideally projects like this can bring us a model where you don't need to login to some other forge to interact with a project but do it by forking it onto your own forge and submitting pull requests between forges.
Anybody who cares about my repos potentially disappearing can contribute to their hosting by re-providing those repos from their own machines. (Note that only someone with the private key can create new records for a pkarr address).
That's mostly a side-benefit though: I mostly wanted something I can `git push` and `git pull`, that is self-hosted, and self-organises across a bunch of underpowered machines with unreliable network connections, with minimal coordination.
How about Forge compatible components? Or forgeables? Naming is hard but hopefully you get the point...
I'm an expert, I'll go to harbor freight and weld some stuff together. It will still break down in 5-10 years but maybe I will at the very least have some control over the way I pivot.
We can wait if the totally incompetent MS management can fix Azure (they cannot, as they have no idea. But they shouldn't block their devs/admins, as they did before), and only then move off.