Consider not self-hosting this repo

[silverwind]

I can't comment on #1029 as it's locked even to maintainers, but I'd like to raise concern that self-hosting will be detrimental to future contributions.

I would prefer these efforts to be stopped. GitHub is a low barrier of entry for many people and by self-hosting, we are essentially raising the barrier of entry to contributions to a level that I think will considerably reduce contributions as well as discoverability of the project.

gitea.com is especially painful for western users because of its hosting location in China. For me it's just not fun to work on because of the ~250ms latency that the service has because of location. GitHub for comparison has 20ms latency for me, it's definitely more fun to work with.

[delvh]

Well, what we could of course do is a bidirectional way: We still allow PRs from GitHub, but mirror them (somehow, perhaps manually) to Gitea.
Would be a bit more work, but might include the best of both worlds.

---

However, I do agree that using gitea.com in Europe is really painful from time to time.

[lunny]

I think we can have a new architecture that all contributors of the world could visit it fast. That will resolve most of the problem.
Some people think I cannot believe you if you cannot host yourself.

[jolheiser]

The Go project itself also does something similar, albeit for different reasons.
They import PRs as patchsets into Gerrit for review, and once merged they close the PR and push the changes to the GH mirror.

Honestly I think something like the above would be a good feature regardless of the main repo, as I agree that GH has far better discoverability, it's nearly ubiquitous with "git".

---

A service to do a more complete sync would be beneficial to anyone who wants to keep their codebase on a server they control, but also leverage the discoverability of GH.

[delvh]

@jolheiser what you effectively propose is #2280.

[McSinyx]

For me it's just not fun to work on because of the ~250ms latency that the service has because of location. GitHub for comparison has 20ms latency for me

Maybe it's because I lived my entire life with shitty connection, but for web browsing anything under 1000 ms of latency for complete rendering can be consider good enough.

Moreover, by principle, most self-hosted instances (with single physical location) will suffer higher latency in the majority of the world, and submitting to that means the entire point of Gitea development is meaningless for the public Internet, and everyone should just use GitHub instead.

I think we can have a new architecture that all contributors of the world could visit it fast.

How far is Gitea federation away from production use?

[earl-warren]

A software forge that does not host its own development is not what I would expect, which is essentially what @lunny says: it is a matter of credibility. Running Gitea.com on a more powerful machine with better connectivity is very easy and cheap.

I would also like to highlight that the GitHub terms of service, which exclude people from certain countries, should not be mandatory for people who want to participate in the development of Gitea.

For these two reason alone I think it would not be a good idea to keep hosting Gitea on GitHub.

[realaravinth]

Even if latency is a blocker now, it shouldn't be for long. Federation support in Gitea should allow devs to connect to a Gitea instance that is closer to them, which in theory should be faster than GH.

Plus, dogfooding will set up a feedback loop which benefit Gitea in the long run :)

[aschrijver]

The latency can be an issue, of course, but is something that can be worked on. But the network effects and FOMO of leaving Github because of their dominant position are exactly the reason why leaving and self-hosting is important. Places like Codeberg already prove how much people appreciate what Gitea has to offer. The extra barrier and activity there may be needed for the Gitea team and contributors to get noticed by folks in the Github sphere will only be a motivation to develop ways to overcome them and become an even greater FOSS development project :)

[wxiaoguang]

As a network expert (I think I am): latency is never the real problem. The real problem is packet loss.

If you have a network with 0% packet loss, even the latency is 400ms, it will be very fast for data transferring.

But if you have a network with 10-15% packet loss, you can barely transfer large data on it.

So, a good global CDN will resolve the network problem for all users in any country.

[realpixelcode]

GitHub is a low barrier of entry for many people and by self-hosting, we are essentially raising the barrier of entry to contributions to a level that I think will considerably reduce contributions as well as discoverability of the project.

If GitHub is already the best option for hosting source code, why develop a free, independent Git forge in the first place?

[deanleggo]

Latency is a very privileged point of view. Everything is hosted in USA so most of the world would have a lot higher then 200 ms, let alone 20 ms. Those tiny differences only make a difference if you have 100MBs or faster fibre. The loading of the content would be the bottle neck.

A few months ago I looked at using Gitea and kept using Gitlab BECAUSE they use Github!

The only benfit of Github is if you want drive-by stars so you can get VC money. If people want to make the effort to contribute to a project, a signup page is the least amount of effort.

If you want to contribute your time to a competitor to Github, not using Github should not be a blocker, but the opposite is a blocker.

If you want to use Github why would you ever use Gitea, let alone contribute to it.

The only issue people could have is with Gitea being hosted in a country they do not like for any number of reasons. The project can host the server and domain in any country.

[reviewher]

If you're worried about "discoverability", rest assured no one is going to GitHub to search for self-hosted alternatives to GitHub. It would be like using Google to search for alternative search engines or asking Elon Musk for alternative electric cars.

Migrating to a self-hosted Gitea instance forces the project to address some critical weaknesses. For example, it is easy to do a one-time import from GitHub, but there is no tooling for re-syncing new comments or new issues. Every impediment to migration represents a bug in Gitea that other users are also facing.

[Giszmo]

To not self-host because of the issues mentioned in this thread is the best example as to why others end up migrating back to GitHub but I also somewhat agree with OP and all his arguments.

Let me bring to your awareness a 10BTC bounty by Jack Dorsey for resolving the discoverability and mirroring between github/gitea/gitlab repos. In the linked document he's very quiet about implementation details and while my interest comes from my fascination for nostr, gitea's past efforts at building a federation - even without nostr - might satisfy Jack's requirements. Yes, he loves nostr but he's also pragmatic.

I took a shot at the problem and he "liked" it.

[hramrach]

Not sure hosting on github does anything for discoverability.

I discovered gitea because some rando linked to their site which included a gitea instance.

I don't even understand how you would discover anything on github. Most workflows only show a repository that you explicitly request. The only place where you get random links to other repositories is a small widget in the corner of the dashboard, and even there most stuff is part of your bubble anyway - not really new.

[silverwind]

Meanwhile there are more reasons for me personally to stay on GitHub for the meanwhile:

1. The review experience is better on GitHub, we are missing [Feature Request] Add code suggestion for PR review comments #14765 specifically which sees usage on almost every PR.
2. Some of our Github Actions do not work properly yet on Gitea Actions like paths-filter and some others will likely never be compatible like labeler. Also, [Actions] Support concurrency syntax #24769 is needed which is essential to reduce infrastructure load.

I understand it's a goal to dogfood, but doing so would slow down the development considerably and I can guarantee the number of new contributors will sharply decline as well because of said higher barrier of entry to register an account etc.

[lonix1]

Agreed, GitHub has the "network effect" - everything happens here.
Self hosting for no good reason is just vanity.

[hramrach]

Meanwhile the barrier to entry on github is insurmountable for some developers because some countries are completely blocked as already mentioned.

gitea.com has the option to use github as identity provider. I wonder what contribution people who cannot clear the barrier of linking their github account to gitea can really provide.

As for the other features - I don't work on github and don't use them so I would not know how damaging not having them really is to the project as a whole. Sure, not having some github conveniences is annoying but I suspect for some of the features the problem of not having them is inflated.

If self-hosting gitea would require that it implements all github features first it would never happen.

Clearly self-hosting does also have benefits, and at some point the drawbacks of missing out on some latest gihub bells and whistles will be outweighted by those.