I have had it with your cute names for software.
It's a common joke that naming things is one of the hardest problems in computer science. Disturbingly, many software developers abdicate entirely their responsibility of naming software and end up naming it an arbitrary word or concept. I think this is bad news, especially when it's a project meant to be used by other developers.
This isn't to say that you should never give a project a cute name, or that developers should be the kinds of people that don't appreciate cuteness. I just think that developers should try to use good (read: any) judgment when naming things.
To aid you in this task, here's a list of heuristics you can use to name software. This list isn't exhaustive and these rules aren't hard and fast. They may even contradict eachother.
Great names
A great name describes what the thing does
- CVS (Concurrent Versions System) is a system for managing concurrent versions of code
- jQuery queries the DOM with j(avascript)
- CssMin minifies CSS
- observ-struct is an observable struct
A great name indicates aspects of how it does things
- OpenCV is open source
- NumPy and SciPy are both Python libraries
- ElasticSearch is a search that is somehow elastic (it's distributed)
- virtual-dom is a DOM that is virtual
If you're going to have a cute name
Absolute musts
You must do these things:
- Describe an aspect of the development style or computer science involved (React is a framework for reactive programming)
- Have good documentation which exceeds the code in size
- Have automated tests, maybe (for real though: good documentation is better)
Mitigating factors
Here are some other cool milestones you can hit before you start anthropomorphizing your particular collection of text files:
- Your software was already released to the public with a utilitarian name that was not cute (clojure-unity is now Arcadia)
- Your name is an organic iteration on a previous name (the somewhat descriptive Ruby on Rails is commonly referred to as Rails)
- You have gained at least one new contributor or 100 users since releasing your software
- Your code is stable enough to use in production
- You have a user-facing project that's not geared towards developers (it's a game, application, or website)
- You have paid real money to a third party to brand your software (support your artists!)
- Your software will obviously function as a namespace for other things (for example, it's a programming language like Ruby or Python)
That is all
Hopefully you will follow the spirit of this document rather than the letter. I have no experience developing with either Backbone.js or Ember.js, but I can tell you that one of the names implies some sort of skeletal structure; who knows what the other one does. Maybe it sets things on fire?