I think it’s better to let Hex focus on serving packages. It would be too much work for me to go through 2800 packages and evaluate if they are good or bad and then decide which ones are the “best” in each category. The other alternative would be to have the “community” vote, but it’s not clear from your post how that should actually work. I don’t think it should be part of Hex either since Hex should focus on its core features, which is publishing and serving packages. There’s a lot of work running and maintaining a package manager and the core team has a long list of more important enhancements and features to work on before we can focus on curation or community voting.

It’s not a bad idea to have a place where you can find recommended packages. There is GitHub - h4cc/awesome-elixir: A curated list of amazingly awesome Elixir and Erlang libraries, resources and shiny things. Updates: · GitHub and http://toolbox.elixir.pm/ already that does similar things. Maybe you can help out on those efforts? Both those projects use the HTTP API from the specifications and you should be able to build a service with the API that would be just as good as if the service was part of Hex.

This is the takeaway here. Asking for some sort of committee that will rank packages is like requesting someone else to do your job. How will this committee even be able to judge all packages that go into Hex about Phoenix, GraphQL, Databases, Elastic Search, Nerves, C extensions, etc? Each of those require specific domain knowledge.

Instead we need to discuss how to assess the health and quality of a project. README, documentation, usage, number of committers depending on the project size and if the team is responsive on new issues. Then there is a whole series of aspects related to your current domain: are the APIs well designed? Is the code tested? Does it use meta-programming only when absolutely necessary?

FWIW, I strongly dislike any measure that includes commit activity. What if the package is just… done?

The problem is that there’s no solution.

Hex’s only job is to server and store packages. No one in the Hex team wants to review packages, especially as Elixir gains traction and we get hundreds+ a week. They also don’t want a high barrier of entry for people to publish stuff either. Remember, Hex is an open source project done for fun, not anyone’s day job (correct me if I’m wrong).

The community is made up of tons of people. People are impossible to get together to agree on many things, especially tools and software. It happens very rarely and only for very big things like Phoenix or Express in Node (even then, many want Koa or Hapi).

Maintainers come and go and projects die after a few years. It’s an extra burden to keep track of which projects go unmaintained. Some projects don’t need maintenance at all after 1.0.0 because they’re simple.

Also, it’s not that bad. I get stuff done in Node all the time and rarely have a problem finding good libraries. I use npms which I linked above—their algorithm takes into account stuff you’ve mentioned and returns great results. Someone could build the same for Hex. After a few projects you just know which packages and people are good.

Phoenix, HTTPoison, Poison, Plug, Poolboy, Ecto (just naming a few) are all set in stone for years to come and the community has already decided on them, but I can go and publish 20 mediocre JSON parsers on Hex right now if I want. But you’ll never find them or use them with a good search system because you’ll get Poison instead. That’s my only solution: Have a good search algorithm and keep up with the community. Or have your own site that lists curated packages based on some algorithm you come up with.

You can’t stop people from publishing trash unless you hire someone to review packages 24/7, and then you’ll be known as the language that’s not friendly to beginners/people experimenting with packages and new ways to do stuff. I’ve even seen people accidentally publishing their Phoenix web app on Hex! Some programmers hate using dependencies, some like reinventing the wheel. People will always be silly

Anyway, that’s my rantish answer. Let me just say I do agree with you and I’d love to have a perfect package repository with only the best stuff on it, but it’s just not going to happen.