This is an response to https://news.ycombinator.com/item?id=8712035 but I fear that the "dominating" voice in that thread would probably bash this down to the hell before anyone notices; plus it's a separate concern and discussion that "forks" from the original debate on (roughly) the responsibility of maintainer (which I belive is NOTHING with a small caveat that I'll describe below). So here we go:
I fully agree with Mr. Lodwick in one point, namely his last paragraph (emphasis re-added by me):
I like your gem otherwise, but it's called "emoji", implying that it's the Ruby library for handling those characters. The facts that it only handles some of them, and that you already knew about this issue but didn't tell us is bad form and frankly rude to your users.
Please don't try to tell me that the name of the library doesn't matter. Suppose I just came to the Ruby world and had a need to deal with Emoji. My first reaction would be to reach for the exact match, gem emoji, right? "The FOSS people always tell us to RTFM. Cool." So I would read the README.md. Cool -- "it does just what I had wanted and looks really neat..."
Except when it didn't.
It would take me one innocent link to https://github.com/Genshin/PhantomOpenEmoji, RTFM, before I could realize that the library was INCOMPLETE and there was no easy way for me (on the "consumer end") to fix it. A few more searches later (perhaps in the Issues section of the repo) before I find the gemoji which (according to Mr. Lodwick) finally works.
Two obvious remedies to the problem:
- The author of the library puts up a visible "LIMITATIONS" section in the README
- Rely on 3rd-party compiled set of "best in category" libraries (it's actually pretty common in the javascript/node/npm world) which includes a few most popular Emoji libraries
In both cases it would become trivial for me to realize the ironic fact that had I wanted to deal with the COMPLETE Emoji set, I should probably not use this very aptly named library. Hmph!
You could bash me down because of my lack of experience in maintaining one of these popular open-source projects, but as someone who constantly benefit from while gaining frustration over these projects, I am increasingly worried about something I name "name-squatting" in these "no namespace" library managers (e.g. npm and gem). On one hand, if I were the first to make a library in the namespace-less npm registry to deal with some well-established building block "XYZ", I don't think there would be any reason for me not to name the library "XYZ". And of course it's MY UNDISPUTABLE RIGHT to dictate what happens to the development, since I'm the maintainer, right?
Except that, do I now carry responsibilities for making this THE library for dealing with "XYZ"? Of course this is debatable. My view is: "Yes, but there should be an way out of burnout" and my proposed way of reducing burnout is for the central registry to offer (if it doesn't already) yielding a repo name. Of course there would be many complications but I believe that proper semver can partially settle this (after all we have Angular 1 vs. 2 here).
(...which made me realize the merits of package managers that does not have a global namespace, such as go get, which of course is another topic...)