Federation is a technique that can give network effects to coalitions of small platforms and thus make them competitive with big platforms (we think). It typically manifests in making users and content on one platform visible and interactable from other platforms.
One of my new favourite sites, https://arewedecentralizedyet.online/ , shows how grossly centralised code forges are. HHI is a metric for how concentrated a market is; this one is off the charts.
Git itself is federated. You can have two repositories on two different servers and share content between them. The user identity namespace is just email addresses.
The challenging part with code forges is all the features that aren't implemented in Git. For example, issue and project tracking, and pull request review.
One way to manage this is to implement these features as objects in Git. For example, have a separate branch called `issues` with e.g. one Markdown file per issue, and either separate or embedded comments and tracking metadata. There are projects like git-bug https://github.com/git-bug/git-bug that do this much better and at scale.
The other option is to use a general purpose data decentralisation protocol. Tangled is built on ATProto, and apparently is dogfooded by a number of ATProto projects, which is a good sign:
I haven't been using Forgejo. The name annoys me to no end -- by changing Esperanto forĝejo (a forge) into forgejo to drop the difficult ĝ letter that doesn't appear on a lot of keyboards, it looks like, "For, gejo!" or in English, "Gay person, begone!" I realize it's an unintentional error, but I don't like it anyway; I would have probably gone for a more literal anglicization, like "forjayo" or even "4JO".
And in Activitypub I'm sure there are a lot of features specific to code handling that likely aren't supported. That's why it seems to me that unless either protocol has a major rewrite with this specific usecase in mind, that we're going to have to Frankenstein this.
That said, I'm supportive of the project and I'd love to see it thrive. Coding is a social activity and it makes sense to use social networking protocols to do it.
This site probably shouldn't measure via Software Heritage. They aim to preserve full histories of repos. Limited mainly to GitHub, plus some approved others.
It's not an attempting to discover/crawl every self hosted repo. You can move to Forejo, and delete your GH, they'll still have a copy of your GH, no deduping, and never find your Forejo.
It includes thousands of mirrors and former repos under github/wikimedia. Harmless for preservation. But as a metric?
@krinkle@ricci Another option could be using a package repository like npm or PyPI. There's a pretty cool package for npm that does a lot of the heavy lifting (but doesn't calculate the HHI):
@krinkle@riccihttps://ecosyste.ms/ has data on the other package ecosystems, and they seem to also have a shitload of data on Git repositories. So... also interesting?
@evan@krinkle It seems to have information on fewer repos than software heritage ... which could be a good thing, if it doesn't count deleted or archival ones as Timo pointed out. I will give it a look. My intuition here is that these are going to be in the noise compared to the 400M+ repos getting tracked right now, but it's worth trying.
It will be much smaller, but far more representative. Complete view of any given ecosystem there, and all repo/hosts used within it, unbiased by what software/hosts you know, and with no incentive to limit discovery (eg cost of preserving full repos, would be out of scope).
There'll be some hosts where you probably can't determine the software used or where the host is down, but that's a good problem to have!
@krinkle@evan I'm actually not keen on the idea of looking at only repos referenced in package managers, as the set of repos that contain software that gets packaged is, I'm pretty sure, a pretty small subset of all public git repos - this feels a bit, in comparing to the social networks, a bit like only including "users who are verified" or something. Yes, this is a certain kind of useful, but it's likely to be skewed compared to the general population. My hypothesis is that these are going to be even more centralized on github, but we can test this! :)
I'm currently trying to extract this information from nixpkgs, which has about 140k packages in it, as a first test, we'll see how it goes!