I did the same. I'm replacing the README on GitHub with "Moved to https://gitlab.com/... and a description of what the software does. If people finds it interesting they will follow the link.

A fork between services becomes more complicate but not so much: git pull from GitLab and git push to GitHub or whatever. Everybody knows how to do it.

Right, one loses the "fork" link between the two repositories but really, who cares? We're writing software for work or for a cause, we shouldn't be playing a game of collecting stars and forks.

Even when I disregard the inate desire of humans for popularity, forks and esp. stars are a sometimes-useful signal for the size of your user base. If I have 10 repos with 1-3 stars and 1 repo with 100 stars, that is useful information to consider when planning the next project.

I'm not worried about myself with the stars and forks, I'm worried about the people who starred and forked my repo and the costs that moving my repo has on them.

For the stars, they presumably did it to get update notifications. I guess they'll get a notification if I update the README, and they can decide what to do about that. I'm making things just a little bit harder for each of these people though.

Forks are even easier to maintain than you're describing. You just need to do a change the url for your upstream. The issue for me is that I have several forks of other peoples projects and in almost every case it's because that's required to make a pull request. For each of these projects that moves, they're multiplying the small effort by the number of people who need to move their forks and/or learn how to make pull requests on the new service.

You sound like gitlab is the "right" choice.

Maybe, or maybe there is an emerging space for a service that would count stars, forks, etc on all versions of a repository and aggregate the values. But I would hate another centralized service.

Isn't GitLab a centralized service?

This could be a kind of git search hub.

This is in part some naming annoyance. Bitbucket let you once use your own domains for repos. Which was nice as you could migrate if you wanted.

The forks thing could be tackled. With a notification, something like I forked you. Or a code search engine which is clever enough to detect and link repos.

The user management gubbins, is the normal irritation of user management and access control.

The stars part is already a bit of a horror across all software - not knowing how to gauge the popularity and quality of a project. Nevermind searching for it.

I'm not the biggest user of these silo repos, but I do appreciate that thin barriers to entry, and improved usability or a good usability wrapper, is charming.

I don't mind not getting notifications or having my stars tracked. I just want people to be able to easily star/fork my repo if they want to keep track of or personalize it. That's harder when it's a moving target.

You could pull in all forks also.

I don't have control over forks people make of my projects. Luckily, this concern is more of a hypothetical for me, as only one person has forked one of my personal projects on GitHub. I'm much more concerned about stars and hyperlinks no longer leading to the real repo when people follow them.