Project naming
April 18, 2014 community, freesoftware 6 CommentsNumber two in an occasional series of “time I wish I could have back” topics related to releasing proprietary software projects as free software.
What’s in a name?
It was famously said that there are 2 hard problems in computer programming: Cache invalidation, naming things, and off by one errors.
Naming a project is a pain. Everyone has their favourite, everyone’s an expert, and there are a dozen different creative processes that people will suggest. Also, project names are subject to approval by legal and brand departments often, which are 2 departments most engineers don’t want anything to do with. So how do you come up with an acceptable name without spending weeks talking about it? Here are some guidelines.
Avoid anything related to the company name or products
You don’t want to have corporate trademark guidelines, certification programmes, etc impacting the way your community can use the project name, and avoiding names related to company assets will make it easier to transfer trademark ownership to an independent non-profit, should you decide to do that in the future. In terms of maintaining a clear separation in people’s minds between the community project and your company’s products, it’s also a good idea to avoid “line extension” by reusing a product name
Outside of that, the number one thing to remember is:
Projects names are not the most important thing about your project
What’s important is what problems you solve, and how well you solve them. The name will grow on people if they’re using the project regularly. You can even end up with interesting discussions like “is it pronounced Lee-nooks or Lie-nucks?” which can galvanise a nascent community. Also, remember that:
Project names can be changed
How many projects fall foul of existing trademarks, end up rebranding soon after launch, or are forced to change names because of a change of corporate sponsor or a fork? Firefox, Jitsi, WildFly, Jenkins, LibreOffice, Joomla, Inkscape all started life under different names, and a rename has not prevented them from going on to be very successful projects. The important thing, in an open source project, is to start small so that you don’t have a huge amount invested in the old name, if circumstances require you to change it.
Avoid a few pitfalls
Avoid using anything which is related to the trademarks of competing companies or projects, unless it is pretty abstract (Avid to Diva, Mozilla to Mosaic Killer, Eclipse to Sun).
That said, don’t worry too much about trademarks. Yes, do a quick search for related projects when you have a shortlist, and check out USPTO. But just because there is a Gnome Chestnut Farms in Bend, Oregon doesn’t mean you can’t call your free software desktop environment GNOME. Domain of use is a powerful constraint, take advantage of it.
Avoid potentially politically incorrect or “bad language” words. Also, avoid artificially smart acronyms. The Flexible Add-on Release Tracker might seem like a good idea, but… don’t. GIMP is a notable exception here to both rules, and countless days have been spent defending the choice of name over the years.
Do worry about the domain name. This will be the primary promotion mechanism. People shouldn’t spend time trying to figure out if your project is hosted at “sandbla.st” or “sandblast.org” or “ProjectSandblast.org”. Make sure you get a good domain name.
Empower a small group to choose
The decision on a name should belong to 1, 2 or 3 people. No more. Once you realise that names are not the most important thing, and that the name can be changed if you mess up badly, that frees you from getting buy-in from everyone on the development team. The “committee” should include the project leaders (the person or people who will be identified as the maintainers afterwards), and one person who is good at facilitating naming discussions (perhaps someone from your Brand department to ensure their buy-in for the result). Beyond that, do not consider surveys, general calls for names, or any other process which gives a sense of ownership of the process to more than 2 or 3 people. This way lies many weeks and months of bikeshedding arguments.
Have a process
- Start with a concept and work from there. Break out the Thesaurus, make a list of related concepts.
- Names can be abstract or prosaic, it doesn’t really matter. Discourse is one of the most wonderfully prosaic project names I’ve seen, but StackOverflow has nothing to do with a questions & answers forum. Ansible is a made up word, Puppet and Chef both evoke wonderfully orchestration while being dictionary words.
- Keep the shortlist to names which are short and pronounceable in multiple languages.
- Cull ruthlessly – don’t keep “maybe” names. If you get to the end, go back to the concepts list and start again.
- If you get to a shortlist of 2 or 3 and can’t decide, use random() to pick the winner or go with the choice of the project leader.
In general, don’t spend too much time on it. You should be able to get a couple of candidate names in a few days of discussion, submit them to Legal for a trademark review, and spend your time on what really matters, understanding your users’ problems and solving them as well as you can.
Of course, this is easier said than done – good luck!
