I don't think that's always true. A bug in library A might be referenced in project B with a fix in fork C.
Yes, a hyperlink works to show you where to find info. But it doesn't alert you when a PR on C is merged by A meaning that B is now unblocked.
That said, I don’t think that works well in a single centralized forge today either. Usually you still need A to actually make a release with the fix, which isn’t tracked by the issue/PR system.
That said, I'm very much in favour of people and projects moving away from GitHub.
There's value in related information being aggregated and linked across many projects.
I'd like it if people could contribute to the projects I host on my own personal GitLab, but not enough that I'm willing to deal with open registration.
Absolutely not. Social logins are unacceptable and I refuse to use sites that depend on them and do not provide a normal method to make an account.
Ideally projects like this can bring us a model where you don't need to login to some other forge to interact with a project but do it by forking it onto your own forge and submitting pull requests between forges.
A project’s issues and pull requests are only useful for that project.
The author mentions avoiding multiple logins and searching across forges. The former is already addressed by social logins / federated identity. The latter is not very useful today, on a centralized GitHub, aside from finding leaked credentials and vulnerable code.
In fact, the tiny barrier of entry for contributing in a new forge might be a desirable quality, to filter out low-effort contributions.