No, there are issues in practice. I have seen many published libraries getting neglected by their creators. Unless the community is actively channeled in this c

No, there are issues in practice. I have seen many published libraries getting neglected by their creators. Unless the community is actively channeled in this case, the result is a set of lackluster forks by people who only make some random changes. As a potential new user, you don't know what to pick. In the worst case, you need to create another fork, because none of the existing ones fixed the issues you encounter. If you take that public, the mess only gets bigger. This chaos can be reduced with a single "blessed" fork that actively accepts reasonable maintainance patches. There are fewer incentives for competing forks and dependencies (direct and transitive) of the original package can automatically benefit, too, because releases are made under the original package name. This is good because the neglect problem can be several levels deep. There is the issue of manpower. There are two arguments here: one is that the bar for package takeover needs to be set such that community interest in a fork is high enough and the fork needs to be managed by the package registry owner for several reasons. One is that maintainers need to be appointed through the registry provider to keep the nodel functional. Maintainer appointments can be passed on after extended inactivity. The other argument is that a package registry provider puts themselves into a trusted position by default and has to actively maintain that trust. Thus, the burden of managing forks and fork maintainers shouldn't necessarily be seen as inappropriate.