Software names are brands, are marketing. These names aren't intended to be useful. Often, they aren't even unique. But they suggest positive associations, may be puns on other names, and (ideally) are quite clear in context.
I agree that such names are problematic. If you'd give me a random selection of package names from NPM, I would be unable to tell you what most of them are supposed to do. Here are the most starred NPM packages, sorted by whether I consider the name in itself self-explanatory or not.
- Self-explanatory (11): request, async, gulp-uglify*, gulp-concat*, nodemailer*, gulp-sass*, nodemon*, redis*, body-parser, mysql*, validator.
- Not self-explanatory (25): express, gulp, lodash, browserify, pm2, commander, mongoose, grunt, socket.io, moment, forever, mocha, bower, chalk, underscore, cheerio, debug, react, passport, bluebird, q, npm, colors, karma, yo.
* These items are not in themselves obvious, but I'll let them pass because the unclear names are references to other projects.
The Perl language has a name guideline that would be more to your liking:
What's in a name?
Make sure you choose an appropriate name for your module early on. This will help people find and remember your module, and make programming with your module more intuitive.
When naming your module, consider the following:
Be descriptive (i.e. accurately describes the purpose of the module).
Be consistent with existing modules.
Reflect the functionality of the module, not the implementation.
Avoid starting a new top-level hierarchy, especially if a suitable hierarchy already exists under which you could place your module.
— perldoc perlmodstyle
Providing Context: […] We can categorize modules, but that categorization lives outside the module and disappears once someone downloads it, blogs about it, or uses it in their code. […] In the author's mind, it's always obvious what the module does and what the name means. Other people don't have that context, and the name needs to provide it.
[…] Almost any abbreviation or acronym is going to be ambiguous. If the first page of Google hits for your initialization isn't about your topic, then you have the wrong name.
Describing Key Features: […] What does an HTML module do? Well, you really can't tell from that name. How about HTML::Parser, HTML::TreeBuilder, and HTML::SimpleLinkExtor? […]
Distinguishing characteristics: […] How many Config and Getopt modules can you find on CPAN? […] Why should people use your module over modules with very similar names?
— PAUSE: On the Naming of Modules
There are a couple of established top-level namespaces like
App::* that encourage authors to categorize their library. If the above unclear npm packages were using such a schema, they would become much clearer: App::gulp, Util::Lodash, Util::Underscore, DateTime::Moment, App::bower, Devel::Debug, Test::Mocha, Test::Karma, ….
Of course it's sometimes necessary to break out of that hierarchy:
Some projects, such as Moose, DBI, DateTime, and Catalyst, try to organize the activity under their namespace to ensure everything works together nicely. If you want to add a module to such a project, discuss it on their mailing list. […]
Names to avoid: Top level namespaces
[…] That doesn't mean that all top-level namespaces are bad. For frameworks like Moose, Catalyst, or DBI provide a functionality around an idea rather than a particular low-level or general task. They don't live in a hierarchy because they are large enough to stand on their own.
This still doesn't solve everything. People think that their framework is important enough to merit a top-level name, or they see an existing module that fits their needs and decide to rewrite it because they consider it over-engineered:
The terms Simple, Easy, Reduced, and Tiny are some of the worst parts of the names on CPAN. They all indicate that the module is a variation of another module, but why is that variation interesting? It's usually missing or hiding some features, less flexible than the original, and in most cases, tailored to the task the author needed. What is that task though? Making it easy for you doesn't mean it's easy for the next programmer.
All of this has worked somewhat well – for libraries. The audience of a library is a programmer who is going to reference that name all over their code. But for (user-oriented) applications, languages, or frameworks, a marketable name is more important. For example, why was the grep-like tool ack named ack?
What does ack mean?
Nothing. I wanted a name that was easy to type and that you could pronounce as a single syllable.
— Andy Lester