views:

736

answers:

13

I work on a variety of projects using different languages and platforms. Parts of them I abstract out into their own separate projects, and I want to open some of these up to the public.

What gets me stuck is the christening.

So, does it matter? Should I just choose something and stick with it?

And if it does matter, what's better: a cool-sounding name that's memorable, or a descriptive name that's easier to find?

A: 

Would be hard to suggest a name to use if we don't know what the product is.

Also, this sounds a lot like a marketing question. I would say something cool and memorable but is descriptive as well. iTunes comes to mind.

Nick Stinemates
Although it's a bit iFormulaic, don't you iThink?
MusiGenesis
Fair enough, it also detracts from the main question, so I removed that line. iTunes is a nice balance though.
Aupajo
+4  A: 

I've decided to go with generic names to start because I'd rather get started quick programming and worry about names later.

This Web 2.0 Name Generator is entertaining.

Brandon
A: 

You could do both. A good example would be Shoes for Ruby. it was originally going to be called (Or so they say) "MIDAS MACLEAN'S WINDOWS OF GOOD FORTUNE" but then he decided on Shoes.

The toolkit/library has nothing to do with shoes.

joshhunt
Never heard of shoes (not a ruby person) but would think slippers would make more sense for ruby - Cf. the movie - The Wizard of Oz
jmucchiello
+3  A: 

Yes, I think it matters (having been in the same position myself). I think the name either needs to be cool/memorable or obvious/simple - not necessarily both. As a rule of thumb, imagine you were looking for a program/library that does what yours does. Would the name you've given it encourage you or put you off and would you remember it? That's really all that matters.

Draemon
+18  A: 

I think naming is an important part of getting ideas to spread. What I look for in a name are:

  1. Memorable. It should be different than other names but easy to remember.
  2. Accurate. It is helpful if the name reflects something about the project.
  3. Positive. It is helpful if the opposite of the name is unattractive. For example, Structured Programming follows this rule because no one wants to be unstructured.
  4. Clever. Clever is optional, but it helps make a name memorable when you achieve it. Clever ages badly, though.

It's not worth waiting to program until you have cool name. The more experience you have with the project, the easier it is to name. JUnit wasn't christened until several months after its debut.

For more information about naming, I highly recommend "Words That Work: It's Not What You Say, It's What People Hear" by Frank Luntz. He is an amoral political operative, but he loves language and communicates that love effectively.

One last point about "sticky" projects: be sure to tell the "creation myth" frequently, the story of how the project got started. Every project I've seen that has had long-term impact has had an oft-repeated story about its genesis.

Kent Beck
Re point 3: I have been seriously put off using FCKEditor in a professional capacity for obvious reasons.
Draemon
+1 for Words That Work, great book, left or right.
dimo414
+2  A: 

If you look at the history of products in general, there are numerous examples of poorly-chosen names that become part of the language (Kleenex, Tasty-Freez, Wisker-Biskit), so I don't think it matters much at all from a marketing perspective. You do want something that's easy to type and spell over the phone, though. I work for company with a weird name with lots of Ss that sound like Fs, and it's a nightmare.

MusiGenesis
+2  A: 

It matters if you care about other people using your code. Prefer memorable names. They may be memorable because they are descriptive, or because they are "cool", or for another reason. If you are putting your code on the net, it should include a description that will show up in relevant searches.

ejgottl
+2  A: 

Before settling on a name for your app, you may want to check to see if the domain name is available.

BoltBait
A: 

I've seen project naming be a big problem. I've managed around 20 programmers working on maybe 40 projects, and it got to be a real problem when you have a project named X, a virtual directory named Y, a Visual Studio project named Z, etc. When an application writes to the error log, which project is it? Who does it belong to? We created a project database to capture all this, but it would have been better to have conventions, because the project database is not always complete and up to date.

I resisted this idea, but it may be best to have project numbers. It seems better to have mnemonic project names, but if you have a lot of projects, you run into questions of mnemonic for whom.

John D. Cook
We have project codenames chosen from mythology: Centaur, Orion, etc.
Joe White
+4  A: 

If the name is to be used publicly at all - marketing, on the web, etc., just be sure you pick a name that someone else isn’t already using for anything at all similar. At least do a Google search. And before you spend money on advertising or anything like that, spend a few bucks to get a search done in one of the more specialized name and trademark databases. At least in the US, being first with a name gives you legal rights and it’s cheaper to do the search than to have to change your name later.

Of course before you go too far, make sure the domain name is available, too.

For stronger legal rights in the name, pick something that’s made up and not just a generic reference to what your product does. Somebody like Microsoft can spend oceans of money to get legal protection of something like “Word” or “Windows” - you probably can’t.

Will M
+1  A: 

I absolutely think that naming is important for your project. A lot of open-source projects have this problem that makes them get names that look cool on the screen but are hard to pronounce. This means that at minimum your website has to have a pronunciation guide, and that a lot of people will be confused about how to pronounce your project. A name with difficult pronunciation can introduce some cognitive dissonance as people try to think about your project. Is it Cool, Cooyil, Coowheel, Coil or what? What's wrong with these people that they can't name their project? If they can't name a project something that is easily readable by sane human beings in the intended target audience, can we really trust them to make a good product?

Wait to pick a good name until you have something good to name your project. Don't feel bad about changing to an awesome name once you find it, there's no need to remain tied to whatever name you were using in development.

James Thompson
+2  A: 

Google Friendly

  • Something unique (or at least something you can get your homepage in the first 10 results)
  • Easy to spell
dr. evil
IBM recently renamed one of their product ranges to "IBM i" because it was easier to search for than the previous name. What is so sad is that that range was originally named "AS/400"...
Thorbjørn Ravn Andersen
+1  A: 

A point not always considered is how easily you can google your project. This may or not be a factor, but you may have an interest in keeping tabs on what the community/press is saying about your project.

If it's called "Project X", "e" , "Raptor", or "Purple Windows", unambiguous searches are near impossible. Over and above the domain name availability issue, picking a name that's not used in any other context allows you to do useful stuff like set up automatic alerts for tweets/blogs comments on your project.

Sadly most of these names are hard to pronounce/spell unambiguously, so it's a tradeoff.

Nik