Last time I checked, sr.ht was mostly an email based workflow, and many teams wanted an issue tracking system that is web based
https://todo.sr.ht/~sircmpwn/hare
The same goes for patches. You can submit changes directly via email, but you can also use our web interface. We're also working on web-based tools for code review built on top of our mailing lists, which will provide a complete experience similar to GitHub's pull requests, but built on top of the decentralized, standardized protocol that git was designed for.
That really seems the best way to dethrone GitHub, as it's moat is mainly carved via a social network.
The git repo is already decentralized, ForgeFed is a great way to integrate and decentralize the social part.
In the future gitea, srht, and many other implementations could interact with each other's users.
SourceHut is already federated: via email. Email is a standardized, federated protocol with thousands of implementations and a global fault-tolerant system already working in production for decades, and it's the approach git was designed to use. I think this is a better solution. You can already use SourceHut's tooling to contribute to projects like Linux, which don't use any forge software at all, thanks to this standardization.
Being able to bridge standalone gitea instances users with repos on your service would be a good step forward for federation.
It's pretty difficult to host a fediverse server, too. I want to make SourceHut easier to self-host post-beta, including dealing with email bits, but I also don't think the dream of federation involves everyone running their own servers. One of the advantages of the federation model is that it strikes a balance between total centralization and total de-centralization in that it allows a talented sysadmin to provide services for a large number of users. There are more ways to federate than ActivityPub.
As far as hosting difficulty goes, once Gitea supports ForgeFed, you'd be able to spin up your own instance as easy as running one program, and no worries about blacklisting.
I agree not everyone needs their own server, which is where shines sr.ht over Gitea, but a community developing a product sometimes wishes to run their own servers for their users. Sure they could run an email server, and users could use that, but it seems roundabout and outdated.
I agree there's more than one way to federate, but the goal is bridging everyone together. Those two aren't mutually exclusive if you support both protocols.
From the sounds of things he does not want the feature.
If you and several other people happen to have a hard requirement for a specific feature that he (or his buddy Simon) don't see fit for, you won't get that feature, even if you volunteer to implement and maintain it. The only thing you're left with is basically to fork SourceHut, host it yourself and maintain your feature all by yourself, dealing with continuously patching a very much still-in-development (and therefore ever changing) software. That is something you're probably not going to do, especially considering SourceHut's architecture and way of doing things.
SourceHut isn't exactly extensible/pluggable and hosting it as a one man show or even a small company becomes a huge PITA, as soon as you diverge from the holy grail that is Drew's way of doing things (Alpine, no containers, no good config management, no easy way to scale things, and the dedication to invest your blood and tears into maintaining this thing).
Hence I really cannot comprehend the current trend that is "let's all dump GitHub for this, and that, and SourceHut". So far, SourceHut really hasn't made an effort to prove itself worthy of the influx of OSS projects. And while I do see Drew commenting here, reassuring folks he won't ban anyone over any internet disagreement, reading the public mailing lists of the SourceHut repos doesn't really show much of a welcoming behavior either. I mean, he's the person behind what has become one of the most popular Gemini servers, and as soon as that was the case, he began threatening client apps to arbitrary block them for doing things that don't align with his values (in this case, [showing a favicon](https://github.com/makeworld-the-better-one/amfora/issues/19...)). And the cabal of elite internet Amish, that have been on SourceHut since its early days and that makes a large portion of the platform, aren't that different either.
I do agree with GitHub being the wrong place for OSS projects, but I don't agree with SourceHut being the right one. At least for as long as it doesn't become obvious that its founder and the community around him has changed and started to genuinely appreciate people for the work they're doing, regardless of their own ideological beliefs.
That being said, the devs of Gitea are in the process of adding AP support, and it has been mentioned on HN already: https://news.ycombinator.com/item?id=31934758
I understand and support his decision, but I will be going with Gitea because I'd prefer AP networking over email. To each their own for sure, but my main suggestion was to support both so the communities aren't fragmented, that would be a bigger threat to Github's network effect. Oh well.
I'll take another look.
The point I am trying to make here is - by default people spend their money with mega corps, because of brand awareness, convenience etc. Instead, it would be nice if the default is indie/small businesses.
In other words instead of "the mega corps aren't working for me, let me look for smaller/indie options instead", it would be nice if we all did "smaller indie options don't fit my requirements, let me go with Microsoft/Apple/etc instead".
Maybe this is too idealistic?
No but they will quit because an ideology most members of most teams was used to justify a decision that affected their work.
Let me start by telling you a story about me trying to buy clothes for the first time:
Back then, I have no idea of branding and the symbolism behind, I don't even have the idea of quality.
After many hours of browsing and comparing, I picked what I liked based on showcase pictures and user reviews, completely brand-blindly.
A week later when they arrived, I quickly discovered that few of them are false advertisments, some of them are in the wrong size and one got damaged during shipping. And for the rest items that were "just right", half of them ripped/deformed after half-year of use.
So, as a normal person would do, I created a table which consist of factors such as durability, price and styles etc to help me increase my "success rate". And after few years of iteration, that table ended up points me to just few brands that happens to be well-known and big.
I eventually settled on those brands with membership cards etc, and now whenever I need new clothes, I open their store page.
What I learned from my experience is that discovery itself generates cost, and the cost is nonrefundable. It is reasonable for an user to settle on a trusted brand. It's not brand loyalty, it's just rational decision making.
For most users, choose GitHub is rational, because it's the most trusted platform out there, and it provides good services (including the infrastructures and socials). You already knew what to expect before you even sign on, that's the level of trust GitHub delivers.
It's really hard to ask users to discover and move to the alternatives once their needs are well-fulfilled by the current one, even when the alternative provides the same level of service.
What makes it even harder is that services such as BitBucket, GitLab, SourceHut, Gitea etc can't provide the same level of service that GitHub offers for free. At this circumstances, the megacorp such as GitHub will always win even when the user is pro-indies by default.
But we are not completely dead in the water here. GitHub succeed because they created something new at the time, something better than what SourceForge offered.
I assume if someone wants to beat GitHub, they need to do the same. Don't just create alternatives, create something new that also does old things better.
Yes, you can say "well, your intended recipients shouldn't use mail providers that do that", but in reality that's not our choice.
I've had Google silently swallow emails before, both sending and receiving. It's not fun.
That was just one example, I've seen corporate Exchange systems do the same. Are they not professional?
If one of the biggest email providers on the planet can silently swallow and not deliver emails, then blanket statements saying emails never fail are just wrong. It's important to understand practical failure modes of the systems we use, and not pretend they're more perfect than they are in reality.