Over the past few weeks, I’ve shared some thoughts about several of the most common branding issues we see in our work with open source companies at New Kind. I’ve covered how to vet the name you are considering for an open source project and outlined the pros and cons of some of the most popular company, product, and project brand architecture scenarios we see in the open source world.

Today I want to share one of the most common brand strategy mistakes I see open source project leaders make: the deep (possibly inherently human) need to name everything.

I have an awesome new idea!

So here’s the situation. You are a contributor on an open source project called SwizzleStax. You’ve been part of the SwizzleStax community for years, and lately, you just feel like SwizzleStax has started to get bogged down and overly enterprise-y. Not as much fun as it used to be, and certainly not as innovative as it was when you first got involved.

One night while you and a couple of friends are out tasting triple-hopped IPAs at the local microbrewery, you get an idea for a new module for SwizzleStax. You think this is just the thing to make SwizzleStax relevant again.

When you get home at 3 am that morning, you immediately start coding. By the following weekend, this new module is pretty much ready to roll. Now you start thinking about what to call it. The obvious choice would be SwizzleStax WidgetMaker (because that’s exactly what the thing does—it makes widgets in SwizzleStax). But you’ve put so much brainpower and energy into developing it… and you just don’t think the SwizzleStax brand is relevant enough anymore to capture just how awesome this new module really is. So you decide you can’t just call it WidgetMaker. You have to give it a name that delivers on the potential you see in this new baby of yours. And then the perfect name hits you:

Zopple!

As a name, Zopple is everything that SwizzleStax isn’t. It’s cool, it’s forward-thinking, and it’s fresh. You can’t wait to share your shiny new module with the world.

You know where this goes next.

A few months later, another contributor develops his own Swizzlestax module. Because he saw how much interest naming Zopple created, he wants to name his module too. He calls it Freakr. So now SwizzleStax has modules called Zopple and Freakr. And then we are on the crazy naming train. Before you know it, Swizzlestax has 20 different branded modules, each with its own unique name.

So who loses?

Why is this a bad thing? Why shouldn’t every project module have its own brand name?

The big loser in this scenario is the main project itself. In this case, Swizzlestax. In most situations, we recommend creating unique brand names for as few things as possible. There are two key reasons:

Reason 1: The mental brand tax

Each brand name requires additional space in people’s memory.

Getting someone to understand that Zopple is a widget-making module adds one mental hoop people have to jump through. If you simply called it what it is (WidgetMaker), you would eliminate this hurdle. There is also the additional mental effort required to associate Zopple with Swizzlestax to consider.

Multiply that by 20 other brand names that each require you to remember what the brand name means, and you have a certain recipe for complete confusion about the whole project. Not to mention that having a bunch of different brand names can be exclusionary to those who do not have the time to figure out what they all are and what they all do.

Reason 2: Branding economies of scale

Each new brand you create takes both financial and human energy to support. So every second you spend building a brand for Zopple or Freakr is a second you can’t invest in building the greater Swizzlestax brand.

Take the auto industry as an example of doing a good job taking advantage of branding economies of scale. Most automobile manufacturers have switched from naming every single car (remember the Pontiac Fiero, Grand Am, Firebird, etc.?) to focusing their energy on one main brand, with simple descriptors for the cars themselves (think BMW 3, 5, 7 series). It saves money, saves time, and focuses brand energy on the most important core brand.

These two reasons are why Swizzlestax is the big loser in our scenario. Rather than having one brand that all of your branding energy is invested in, you have 20 different brand names, each sapping energy from the core Swizzlestax brand. If you let this go on, before you know it, Swizzlestax will become a hollow shell of its former self—a weak confederation of branded modules all competing for attention.

R.I.P, Swizzlestax.

So what’s the alternative?

The alternative is simple. Choose descriptive names for project modules, libraries, and tools rather than inventing new brand names whenever you can. This ensures that you are always refocusing brand energy back to the core brand.

The new module you built for Swizzlestax? By calling it WidgetMaker, a basic descriptive name that says what it does, you ensure that the focus remains on the Swizzlestax brand. You also remove that extra layer of required meaning (because WidgetMaker clearly describes what the module does).

And perhaps the biggest bonus? By associating your new module with the SwizzleStax brand, you actually begin the process of making the Swizzlestax brand cool again. If all of those other 19 cool new modules also choose descriptive names, the core brand will become more powerful and relevant than ever.

In summary

• Invest your limited brand energy in as few brands as possible to make those brands stronger. Each new brand name you add takes energy to support and saps power and meaning from your most important brand(s). If you are interested in learning more about why this is the case, study up on the differences between a branded house and a house of brands.
• Think twice before adding a new brand name and ensure you have a great reason to do it. If you are naming something because the existing core brand isn’t cool enough, ask yourself whether the addition of this new module could help to make it cooler? In most cases, reinvesting in an existing brand where you’ve already invested a lot of energy will pay off more in the long run than creating yet another brand to support.
• Simple descriptive names may not seem that fun or interesting, but they are actually very powerful. Two key reasons: 1) They remove a layer of required meaning—you immediately get what they represent without having to interpret a brand name (see also: call a duck a duck). 2) They create branding economies of scale. By investing more energy in your core brand(s), you make the entire project hang together more tightly, and the new module will gain from the focused investment and the association with the core brand.
• Sometimes the most powerful naming strategy is an un-naming strategy. Some of the best brand decisions we’ve made over the years are helping organizations un-name things they had previously branded. Just because you have a weak confederation of unsupported brands today doesn’t mean you can’t change. Try killing some brand names, replacing them with descriptors, and channel that power back into your core brand.