We changed the MELPA website's package pages so that "Homepage" links go to the URL named in the package's Homepage or URL header, instead of directly to the source code. Hope that helps you explore more conveniently!— MELPA (@melpa_emacs) May 26, 2020
What the MEPLA people are doing that I don't like: * Never communicate with the developers of the Emms in any way. * Omit many files that come with Emms. * Associate Emms with several Emms extensions that live only on MELPA and that we, the Emms developers, have never heard about. This would give anyone accessing Emms via MELPA that those extensions are somehow a part of Emms, when they are not. Maybe those extensions are good, in which case I would love for the developers to contact us, the Emms developers. But Maybe those extensions are bad, don't work, are out of date, or connect with non-free services. * Not even linking to the Emms home page (https://www.gnu.org/software/emms/).
Ideas for improvement: * Encourage people to speak to the developers of a project before packaging it. * Find a way of packaging a project as-is. For instance, Emms could be distributed as is, and the M/ELPA software could simply point at where Emms keeps its .el files for Emacs to find. This is instead of how I see ELPA working now, which is to force the software through a kind of a sieve (I think ELPA calls it a recipe) where only a select few files come out the other end. Emms doesn't need a recipe; it already comes organized and packaged for working with Emacs. It makes me think of taking bread, crumbling it up, the mushing those crumbs back together to re-form a new loaf of bread.