Personally, I really like the solution that Go has come up with. Go does have the huge downside that its system needs some centralized servers (and possibly wor

Personally, I really like the solution that Go has come up with. Go does have the huge downside that its system needs some centralized servers (and possibly worse depending on how you look at it, defaults to Google's for them), but it has the huge upside that it avoids any particular single point of failure. If you are using a module proxy (like the default,) you can still fetch dependencies from GitHub packages when GitHub is down since it can grab through the module proxy. But if the module proxy is down, it can just fetch the package from GitHub instead. It's also possible to add multiple proxies to the GOPROXY variable, if you wanted extra redundancy. But what makes this design especially nice, in my opinion, is that it means that you can host Go modules anywhere, so as long as you follow some conventions. And because of the GOPROXY mechanism, even if your site is a little unreliable, it shouldn't generally be much of an issue. The sumdb and lockfiles additionally helps ensure that the integrity of existing published versions of packages can't be compromised even if e.g. somebody acquires the domain later on. I'm not saying this is perfect, but it's a really nice blend of properties. If you're going to have to have a centralized entity that provides package services, making it work like this prevents a hard-dependency on a centralized party to handle package management while reducing some of the security and reliability concerns of self-hosting package repositories. Admittedly, this would lose some of its luster if a lot of packages became unavailable because the GOPROXY stopped caching them and they were long removed from the Internet; but OTOH, things eventually disappearing is always going to be a concern on the Internet, as the act of keeping things online is an active effort that requires time and money. As of today, I think this remains a sensible compromise. This doesn't solve curation at all, but that's kind of the thing; if programming language package management is the wrong place to gate insecure or potentially even malicious packages packages, then they may as well not colocate packages to specific central locations, either.