Products and Projects: What’s in a Name?

What makes a good open source project name, and what makes a good name for a product, or even a feature within a product? And, does it really matter in the world of open source software? From what I have seen, it matters a lot. In fact, poor understanding of technology naming nuances may impede the uptake of open source software.

Being a geek with a penchant for elocution, I have worked as a product manager, a product marketing manager. and an advanced technical trainer. These different roles have allowed me to examine the cultural and social aspects of product naming, and–more recently–of project naming. My best recent teacher in this area is Guy Lunardi, product manager for SUSE Linux Enterprise Desktop, although I don’t think that Guy knows how invaluable his occasional explanations and clarifications have been for me on this specific topic (or technology in general, for that matter). What have my interactions in software naming shown me? Let’s start with the names of open source projects.

Project Names: the Virtue of Being Inspecific
Most open source software projects use names that don’t tell much–if anything–about what the project aims to make possible. Perhaps one of the best examples is the Mono-based desktop search project known as “Beagle.” One can only defend the most esoteric relevance between the word “beagle” and the concept of desktop search. (“The H.M.S. Beagle went on a voyage of discovery,” or “Beagles are scent hounds, good for sniffing things out” are both statements that both seem to be a reach.) There’s nothing that functionally implicit about the name. Dozens of similar open source project naming examples exits. From what I have seen, non-descript project names are good for an open source project.

Let’s consider. Any name that implied or described well a particular project’s functionality goals would also intellectually constrain the project’s possibilities. If Beagle had been named something like “Desktop File Search”—or, more playfully, “File Ferret”–would its other extremely important search capabilities–such as indexing your email, photo meta tags, and instant message logs–have gotten passed over or been much delayed? I submit that using the esoteric name “Beagle” allowed developers to freely explore and the project’s capabilities to prosper.

To those who work in proprietary software development, the strategy of using of inspecific names is very familiar. Developers and product managers have long been used code names at the outset of a next-version development cycle. Microsoft used “Chicago” for Windows95. NetWare 5 was known as “Moab” until late in its development. You could rattle off other examples at length (a possibly enjoyable nostalgic excercise, but we’ll continue). The point is that there are advantages to using non-descript project.

I’ll put it in two simple imperatives, with brief rationales:

• Use a name unburdened by connotations.
  Codenames such as Titanic, Cancer, or Atheist are generally discouraged. (There is a classic story about Apple along these lines.)
• Don’t use a name that is overly glamorous, sexy, or otherwise catchy.
  If you invest a lot of pride in coming up with a catchy code name, the short term satisfaction will wane, and then you may later regret being so clever: A project with too good of a code name will be difficult to rename.

But why would it matter that the original project name or code name was too good? For that, we need to look at product and feature names.

Product and Feature Names Must be Human-Understandable
Too often in open source software, products and features within products become known by the name of the technology that underlies them–often a non-descript project name. I assert that this creates a problem for the adoption of Linux because it creates a lexicon of seemingly cryptic terminology that the new user has to learn. This creates an unnecessary psychological cognitive barrier to entry for any newbie who is trying to get started in understanding Linux and other open source software.

For example, if you tell a non-Linux user that Linux has AIGLX, your words won’t convey much meaning. AIGLX says nothing about AIGLX does. Worse, after you finish explaining the functionality is, the person then asks, “And what was that called again?” That question means that the name is a barrier. Finally, even though anyone can use AIGLX once it is enabled, many who hear the name will inevitably think that AIGLX is a technical thing for technical people. Simply put, the name sounds techie. (For the record, I should state that the name “Xgl” is equally bad. I’m not picking on AIGLX, even though the similar project called Xgl is funded by Novell. In fact, who really cares whether AIGLX or Xgl ultimately prevails? Some developers and enthusiasts may pick sides, but both projects enable Compiz. The point is that both “Xgl” and “AIGLX”–even “Compiz”–are names better left on the projects and not brought forward into the list of things a user must know about.)

So, why do many distributions that have so many very intelligent people involved in their making end up calling many of their features by the project namethat enable them? It actually makes sense how this happens. When the projects become part of a product, the names simply get overlooked. We seldom even consider that the obtuse project name may not be desirable in a product. My conjecture is that, at some point, the people who make the software stop noticing project names.

Consider the lifecycle of a popular open source project. The name of a really useful or innovative project, such as “Beagle,” often gets celebrated for the promise that the technology shows. As the project matures toward being put to actual work, developers, hackers and enthusiasts proudly demonstrate the projects growing capabilities and thereby adding to the project’s notoriety. Community anticipation builds and the name becomes known more widely. By the time the project has matured to be included as a reliable feature (or perhaps even deliver as a standalone product), the project name has excellent familiarity within the community.

Enter the marketers. Trained to ride what appears to be good “buzz,” marketers often overlook that the familiar names within the community may work rather poorly in the actual market. “The community knows all about Beagle, and apparently they think it’s really great. We better emphasize how our distro includes Beagle!” Following this path, newer users end up confronted with some oddball thing called “Beagle” in their desktop interface. “I don’t know what that is. I had better leave it alone.”

There are a couple examples of effective renaming in SUSE Linux Enterprise Desktop. In a related blog post, I mentioned that Novell chose to call Xgl/Compiz “Desktop Effects.” For an end user, the change arguably provides a much more memorable and intuitive name (despite perhaps sounding a bit mundane). A similar name was applied to the Beagle interfaces. Instead of using “Beagle” or “Beagle Search,” the product team chose to call it simply “Search” or “Desktop Search” in most interfaces. While the name may not have pizzaz, you get an immediate idea of what it does, and there’s not much to learning the name.

Another bonus to naming a feature for what it does rather than after its enabling technology project is that it allows you to swap underlying components without disrupting the user experience (interfaces, documentation, etc). If you use the name “Beagle” in end-user interfaces, and then later decide to use a different underlying search architecture, its not just your documentation and training that have to be changed. The hardest adjustment is your user base’s knowledge, which is only partly in your control. (For an example we can look to the Novell user community. Many of us still regularly refer to “ZENworks for Desktops” and “NDS,” both names that have long since been retired for newer names on those technology lines.) If Novell ever were to decide that AIGLX has matured enough for us to drop development on Xgl, their use of the name “Desktop Effects” will continue to serve end users well.

Yeah, But…
There are exceptions. When a project name is actually descriptive, it might work well for a feature name. Even moreso for a product name. Also, when a non-descript project name is well-enough known to a general audience that it has attained eponymous stature, by all means, why use anything else? Apache is the best example I can come up with. Once upon a time, “Apache” wasn’t synonymous with “webserver.” To rename it would make things more difficult. (And, Apache itself is not a layperson tool, which puts it well outside of the domain I am addressing.)

Conclusion
Anyone working in open source software, especially product managers, developers and marketers, should consider the importance of the naming of technology. There is a good argument with a lot of precedence for having non-descript or seemingly obtuse project names. Explicit names can constrain the directions a project might take. Using too catchy of a name can yield short term pride in having a good name, but ultimately slow a project’s uptake among a less-technical user base.

When it comes to naming the features that a project might provide in a final product, it pays to think of the users who are not “in” with the community lexicon. (Unless, you don’t care about adoption by anyone but techies. I’m assuming the target audience.) In particular, marketers have to avoid the project name pitfall that can result from simply accepting the terms that engineers and hackers might use. Chances are that your developers and hackers speak with other developers and hackers a lot more than they do with the next wave of end user adopters. Rolling their terminology into a product’s positioning documents or feature description statements is not necessarily the optimal route for market performance. (In fact, it is here that open source developers really need marketers to contribute.) Feature names need to speak to end users simply and plainly so that they can use the product effectively.

——-
Afterthought: Beware the Beavis
One other thing on all naming: watch out on initialisms and acronyms. Novell once codenamed a product “Border Services.” The initialism was rather unfortunate, so it was changed to BorderManager. Going from B.S. to B.M. is not much of an improvement.

My recommendation is that every company should designate at least one “Corporate Beavis” for such reviewing potentially embarrassing names. It takes a special person to fill such a niche, but I think most of us know exactly what kind of person upon whom this highly esteemed role should be bestowed. (Otherwise, my services can be contracted.)