It’s not the package managers who gatekeep, it’s their associated repository. People are free to create and host their own repositories (or, in Homebrew-speak, taps). Users are free to add those with no PRs involved whatsoever.
2. Yes, people are free to create brew taps. But you know humans are divided into 'I will do this' and 'I wont do this'
3. There are there roles: [software developer], [package maintainer], [user].
3. Most cases, [the software developer] is not the [package maintainer]. The software developer only push code, test code , build code. Like we know, build binary is a step of the software developer, but they don't like to create much more packages with apt-get/brew/pacman/etc, so many packages in the centralized PM are outdate. Examples are endless.
4. [User] is people who using software, they like less concepts thing. They just a user, not developer, not maintainer.
So like https://packagecloud.io/ ?
It hosts standard package repos which can internally do selection for distro/version/architecture.
The point I was trying to make was: as a 3rd-party package maintainer, why would I look into nami (rather than upload my package to a 3rd-party repository so users are free to use the package manager they already know?)
It's just too much administrative overhead in the long run. I don't run just one machine. This is not laziness, it's a mode of operation.
Also, it's a red flag. If you can't get into official repos, what else is wrong with you? Perhaps nothing, perhaps those gatekeepers are gatekeeping too hard. Still, I'm not going to invest my resources to figure it out.
There are many good reasons for a piece of software not to be included in a default repository.
First of all, it’s about prioritizing maintainer workload. It makes sense to draw the line somewhere in order to prevent the backlog from growing. A huge backlog is bad for everyone: it tends to burn out maintainers, causes important (security) updates to slip, and can be frustrating for users.
As a package maintenance team, what options do you have to draw a line? You may decide to narrow the scope somewhat arbitrarily (e. g. FOSS only, stable versions only, latest only), add some notability requirement (e. g. 50 or more GitHub stars), or streamline your process (e. g. exclude packages that would require downstream to write and maintain patches).
Anything of the above can cause a perfectly trustworthy package not to be included into a default/core repository, leaving 3rd-party repositories as a good enough option.
I think it’s super important to be extra vigilant when tapping into a 3rd-party repository. But it would be a little unfair to consider those packages (or their upstream projects) damaged goods.
Not saying you did imply the latter; I just felt like chiming in with my point of view.