Here are some specific pain points, details that I think are important and possible solutions.
Disclaimer: It's mostly personal opinion. If you think any of the statements below are offensive, sorry, I haven't meant that. I believe that we should have a consensus on this, and not push toward any specific decision without a good understanding of the trade-offs (including SH itself).
This is the fact that no one can deny, like it or not: Go community is primarily on the Github. Because of this, it's easy to create issues, easy to contribute.
Go core team tried hard to keep away from Github, but now they allow contributions from it as well. The main tree is also hosted there, as well as countless Go projects.
Centralization is evil in many ways, but it's good for bringing the community together, especially if the service is free and distributed (Git always is).
Having said that, I think using open-source Git service is a very good idea. But there are better alternatives than SH, some also minimize the friction by trying to keep feature parity with Github. More on this later.
Sending patches by email is a pretty old way of sending changes to upstream. Most Git services nowadays provide automation for this (e.g. pull requests, merge requests). But let's put aside the "it's old" argument for a moment. Specifically, setting up Git to send email patches may not be as easy as one may assume.
First, there are still people using Windows to develop desktop/Android apps. Those people may freak out from just hearing "open the terminal and change those things". One may argue that those people probably won't contribute to Gio, but I think it's wrong. It's possible to contribute widgets without touching any low-level code.
Second, some people use IDEs which already have many convenient features for pushing changes/PRs as branches and for Git management in general. Those people would have to drop to the terminal every now and then and paste hashes instead of allowing IDE to deal with it. I would argue that user who care about UI may prefer to use IDEs, thus this category of users might grow significant in the long run.
"High-level" devs aside, let's talk about "low-level" devs. Dropping to CLI is not a problem, and setting SMTP configs per this guide is trivial. The problem is, the email is a pretty sensitive service, you may not want any apps to access it. If you attempt to follow the guide, for example, Git will store your email password unencrypted on the disk! Yikes!
Yes, there are ways around it, for example, you can enable keyring integration. But to be more specific, I personally never allow any apps to access my primary email. Ever. And I have no plans to maintain a separate email for the sake of SH way of doing things. And I believe there are other people that take this way more seriously, than I do.
Friction of setting those things up may discourage many potential contributors for no good reason.
"SH is still an alpha" is not a particularly good argument for using it in the first place, to be honest. Things tend to break, even Github has outages. And it's usually more true for new project like SH. But to be honest, most of us don't really care. We like the bleeding edge, so it's not a strong argument.
SH have a few things planned for the release, but it may take a considerable amount of time (year? two?) to develop and stabilize those. I believe that the Gio community should not suffer during this period due to missing core features, especially if there are better alternatives.
So instead of forcing contributions to happen on SH, it may be practical to use some other open-source and feature-complete alternative (e.g. Gitea) until SH hits the 1.0 milestone.
And yes, I mentioned that contributors will be forced to use SH to contribute to Gio. It is possible to send things to Gio without registering, but let's be honest, to effectively follow the project you'll need to register and visit SH from time to time. Which may be annoying since some useful features are missing.
I wouldn't get into details on missing features, because the list is quite long (SH is really simplistic), but you can open any of the pages from https://try.gitea.io/explore/repos and compare the number of buttons to the same page on SH. It may give a rough estimations of what's missing.
Also, during previous discussions it was mentioned that Gitea is a "no go" because it implies self-hosting and someone will need to pay for it. But if you read SH's plan for the release, you will notice that there is a clear statement: SH will be a payed service. So eventually someone will need to pay for hosting Gio on SH.
So I personally prefer to pick a feature-complete open alternative and self-host it (and yes, pay for it now), instead of picking alpha-quality service as the "source of truth" for the project (and paying the same cost in the future).
There is an awesome article by the founder of SH about how Github changed the meaning of the "fork":
https://drewdevault.com/2019/05/24/What-is-a-fork.html
It's a really good one, despite of the misleading name, and I highly recommend to read before arguing against SH. The chances that you are missing the SH's whole point are pretty high (I missed it too at first).
TL;DR: The article states that Github centralized things by introducing forks in a very specific way. I would say that author is highly subjective when mentioning Github, and blames it for a lot of things without giving enough credits for the positive effect. But if you ignore those occasional statements, author makes a very good point. Being enterprise-focused, Github unintentionally promoted a centralized model to the open-source world.
You see, Git shouldn't have a "central project repo". Instead, a project is a combination of all branches in all forks. Linux is mostly developed this way today, while still being hosted by Github. But most other developers embraced the centralized way by creating orgs and assigning canonical names to projects. Now there is always a small group of people controlling each project. Some have weird rules which doesn't make sense, but forking is usually not an option, because there still be a "canonical" project.
Sorry for a long explanation, but I think it's crucial for an understanding what SH is trying to achieve. They are trying to remove this centralization "feature" and promote a decentralized way. At least on their own platform. And here is the main "but" for this discussion, I think.
Both the intention and the core idea is awesome, but this specific thread in Gio indicates that it's easy to miss the point and impose a centralized way of managing things on the new platform as well. No offense here, we all are used to think in terms of orgs and ownership (in the centralized way). Which seems to be different from what SH promotes.
To give a specific example, the distributed approach would imply that ~eliasnaur/gio is a fork and is equal to my fork at Github, and your fork on Bitbucket. So the "contribute things to SH where Gio is hosted" approach doesn't makes sense in the SH's ideology. At least this is my understanding.
To make this work in practice, however, SH will need to implement a good integration with other Git hosting provides like Github, Bitbucket, or any private Git instances, really. But right now it's seems kind of the opposite. Remember the "on this new platform" argument? Without any integrations (email is not a good one), it's still a centralized/isolated model. But instead of Github, there is a SourceHut: you need to go here to track issues on the project, you need to go here to contribute. I hope this will change eventually, but it's not the case right now.
And going back to emails, why we as Gio community need to find ways to integrate our workflows with SH (e.g. syncing issues/PRs), rather than SH integrating with tools the broad open-source community uses? I'm pretty sure they have plans for it, but again, no offense here, I don't think it's practical to pick a tool that is still this deep in the development.
Some key takeaways, in my opinion:
- Go community is mostly on the Github. Picking anything too different creates friction.
- There is no way to contribute via SourceHut except emails (during alpha?).
- Setting up Git to send emails might not work for some people. Not necessarily a minority.
- Contributing issues is important. Creating/tracking those is harder on SourceHut.
- SourceHut is not yet there in terms of functionality. There are better open-source alternatives.
- SourceHut will be paid on release. There are better open-source alternatives for the same price.
- Gitea may be a good alternative. Open-source, feature-complete, less friction to switch for Github.
- Picking SourceHut from an idealistic perspective should imply a different management model.
- Different management model will imply allowing Github as a "peer". Doing so will shift contributions back to it.
- Using Github as a peer for SH is hard for now. Requires additional community effort to build integrations.
Again, personal opinion. Propose other options. From less hardcore to more hardcore:
-
Move the project to Github completely. It would be easier for others, but will defeat the decentralization again.
-
Setup self-hosted Gitea. Almost no friction. Github auth (optional), feature parity, similar UI. But we'll have to pay for hosting it.
-
"Bazaar" way (SourceHut ideology). Gio's forks on Github and SourceHut are equal. The one with less contributions merges from the one with more. May organically degrade to (1), (2) or (6) depending on the largest fork.
-
SourceHut is the source of truth. Sync with Github issues and PRs. Significant effort. May degrade to (6) since no one will probably have time to build the sync.
-
Gitea with modifications. Similar to (2), but also contribute code to Gitea (it's in Go) to enable anonymous email contributions as in SourceHut. Less effort than (4)? Supports Gophers. May degrade to (2).
-
Stick with SourceHut. Use emails until the release, pay for it afterwards. Probably lose contributors. If development will pause for too long, may degrade to (1) due to a new maintainer.
Great list. Well said.