ActivityPub is federated like git is distributed. You can add several remotes from different servers (or peers in case of single user instances hosted at home)
Even though other sites like GitLab exist that GitHub remains a near-monopoly default doesn't bode well for attempting to migrate to a completely decentralized system as default. There are decentralized extensions of git (like git-ssb).
Addenda: Git is also not well suited for a lot of decentralization due to how branches are modeled. Patch-theory based systems like darcs and pijul would need more adoption before code repositories could be decentralized.
Why wouldn't it be? Git itself is already decentralized, the main advantage of github is that it lets you discover/follow other projects. With activitypub, you could have people hosting their own servers (or outsourcing to someone like codeberg) and you could follow others no matter where they are.
> Git makes it easy to make copies, but its nature of having one designated "origin" remote per repository that serves as upstream source of truth (on platforms like github also across forks) makes it not really federated/decentralized the way Mastodon et al. are.
That makes sense. Each Activitypub server might also be considered the source of truth for any given post, but since you're usually going to fetch them from your own instance that your account lives on you're not getting it directly from there unless you specifically do it yourself.
> But that said, Mastodon/ActivityPub don't really feel like mature solutions yet.
Yeah, that makes sense. I think this is partly because Activitypub is both quite opinionated, but also gives you quite some wiggle room with how you implement different functionality, like defederation. And of course the most well known software in that space is effectively what all others have to follow.
Git is probably a more stable protocol, but then again ActivityPub is served over HTTP, which is also pretty stable. I believe the same issues would befall this as well, since Git, to me, doesn't seem to be the biggest factor in this, and more the append-only nature of it. I've never been a big fan of append-only social networks.
I've been running a Mastodon server for a couple of years now and have had relatively few federation issues, luckily. But I do agree that trudging through the logs and figuring out what's going on is not exactly ideal, not to mention debugging other issues like if something went wrong during the key exchange with your server and a remote one, or if you accidentally lose your key and suddenly can't talk to any other instance since they won't trust your old domain with the new key. But you might run into similar issues with this, right?
Edit: If it came across as downplaying the project or it's author then that wasn't my intention at all. These were just some thoughts that immediately popped into my head when I saw this. They may well have thought through answers to my not thought through questions, and I certainly don't mean to pretend like I know better.
I like the idea of closing the gap where GitHub might fail, and I love ActivityPub-based services and the federated web, but I think this isn't the best solution. Git is already decentralized to the extent necessary to be useful for projects. An open source project will generally have one and only one canonical upstream location. If that location needs to move, git is accomodating.
The better strategy is to work on encoding ticket tracking and such into git objects, in my opinion.
Git makes it easy to make copies, but its nature of having one designated "origin" remote per repository that serves as upstream source of truth (on platforms like github also across forks) makes it not really federated/decentralized the way Mastodon et al. are.
And I don't reaaally see how this tool solves that problem. Or any of the other problems you mentioned.
But that said, Mastodon/ActivityPub don't really feel like mature solutions yet. It's incredibly opaque how instances interact, and self-hosting is an exercise in frustration as you try to figure out why A sees your reactions but B does not and you can get notifications for C's reactions but not A's, but B's replies and not… I gave up after a while. It's more opaque than even email self-hosting, at least exim and postfix have fairly verbose error logging.
Git is already decentralized. So no, we don't need a fediverse equivalent. Crazy idea, but what if you hosted your code on your infrastructure, like the "old days"? Or, move to an independent forge, or stay where you are. The concern isn't about GitHub directly, but that everyone storing all their source code in one place is concerning.
Git is flexible. I'm kind of surprised at how ubiquitous GitHub is given how easy it is to host your own repositories and set up a mailing list to accept patches and discussion on.
If the web implementation of git could be as federated/decentralized/open as git is so that GitHub didn't exist, that would be my ideal "GitHub-Next". Please eliminate yourselves.
I think you're right about a general move towards a Git monoculture (as opposed to a GitHub one), but there are dozens of great Git repo hosting/collaboration companies - GitLab, Bitbucket & SourceForge to name a few of the bigger ones
What if you could make a federated/decentralized git that doesn't care whether the git repo is made available by github or my-fancy-federated-git-host?
BTW: There is work in progress to decentralize modern git based workflows by https://nlnet.nl/project/ForgeFed/ (paid for by the European Union), by decentralizing git not at the client level (which it obv. already has, but most people only use one origin), but also on the code forge level.
Being an active Fediverse user, I've realized that what people realize is that when they say they want to decentralize Git, they often aren't thinking about decentralizing Git; they are thinking about decentralizing GitHub/GitLab/Gitea/etc.. They want to decentralize the social aspect, the issues trackers, the ability to automatically pull fresh changes from other parts of the web via webhooks.
I can't tell if you're being ironic, but Git is already federated. Like, GitHub should be just another remote, and which remote happens to be the source of truth is a policy decision. The sticky part are the value-add, non-Git parts like GitHub actions, the issue tracker, wiki, static hosting, access management etc. But most of those are orthogonal and federating them (perhaps as git repos themselves) seems like a good idea.
(disclaimer: work for MS, not on GitHub, also hi again superkuh)
Git itself is decentralized. It is entirely agnostic from a centralized/decentralized point of view. We tend to centralize things to make life easier. Who wants to pull updates from each contributor as opposed to a hub?
So the real question is — what are the features of GitHub would you like to see decentralized? CI? Issues? Wikis? Because, you can self host many of these with gitea, GitLab, or sr.ht. That’s the best kind of decentralization, but it does add to your own personal overhead (maintenance, backups), and really limits discovery.
I think what you might be asking for is if there is a federated code repository that supports git. That’s an interesting question, and I don’t know if such a thing yet exists.
I agree that NNTP was a nicely federated system, and just a couple of days ago I was pondering the use of NNTP to publish Git pushes. Git's support for signed commits and content addressed objects is a great start for distributed, trustworthy collaboration. I still can't envision exactly how it would all function. There are lots of benefits to the GitHub model. They're a semi-trusted and well-funded entity who guarantee a highly available and fast synchronization. Sure, when it goes down everybody has a problem for a while... but with more distributed models you can get way more complicated failures, like "this object isn't seeded by a connected peer right now" or "this federated shard doesn't carry this repository" or whatever it may be.
I'm really interested in the future of distributed code collaboration. I just think it's not so trivial, and so it's very understandable that people have gravitated towards a semi-centralized model that already works.
https://github.com/git-federation/gitpub
reply