There is others boundaries. For example, handling of CoC tickets tend to be private, for several reasons, but I think the biggest one is about protections. Protection of the entity (especially when faced with people eager to claim libel, as I have seen), protection of the reporter (so that count as personal details for sure) and protection of the community itself (as we have seen that several high profile cases (Pycon 2013 Donglegate, Drupal one, etc) have become a network wide shitshow).
So they tend to default to private, which is IMHO a problem since now, the perception of handling disputes is of some shadowy cabal handling edicts from above, and not a lengthy discussion process.
Here, the problem seems to have been less with Travis/Github as proprietary systems and more about Github not working for free to untangle the governance of VoidLinux. The project would likely had faced the exact same type of problem with a registrar or a bank by asking “can we take over that domain/account, we have no structure to prove, but we are the good guys™”.
The obligation to have a structure to open a bank account is a interesting point. On one hand, this clearly add friction. On the other, this solve so much problems down the road that maybe this is something to replicate. For example, configure a forge so that you can’t create a org on a forge unless there is more than 2 admins. And make the forge do a regular check that the admins are alive and interested, on a regular basis.
The part of the issue with Github not being engineered for 10 000 repos is real, as is the question of load for Travis, but to be fair, that’s a engineering issue, and I think that it is not really a Github specific issue. If the community had not enough sysadmins to setup their own CI/Forge, Github being free software wouldn’t have changed that at all, and the problem was here before the governance crisis, and wasn’t created by that crisis, just made visible. If Void Linux decided to go on gitlab.com at the start, I feel their problem would have been the same. The same incentive to not spend too much time on non paying users would apply, the same lack of sysadmins would apply, the same scaling issue exist and the only difference would have been 1 specific API to change the parent of a repo.
Granted, this part is specific to Github, but I see that as a missing feature more than a fundamental limitation due to Github nature and/or stack, since Gitlab has a hidden API call to fix that, and github doesn’t. And I am not sure if Gitea has the same API (since the doc of /repository/repoEdit do not explicitely list parent as a field that can be changed).