• Categories

  • Wayback Machine

  • My Defunct Podcast

    The Bungee Line was an audio podcast for web developers, covering web API's, software development, and the creation of richly interactive web applications.

    podcast feed  Main Feed

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
link removedMost 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.”

Desktop Search iconThere 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.)

19 Responses

  1. Wow !!!
    how much time did it take to write down all of this ?
    My mind is spinning around badly.

    I admit i have to think a little about your annotations. I’ll come back later, promised ;-)

  2. Wow! Excellent post on an interesting topic.

    Being a ‘techie’, I’ve become fond & familiar with the obscure naming of open source projects in general. From a developer’s standpoint, it accomplishes the same thing as a versioned product’s codename: it simply & uniquely identifies the project, independent of other projects that are of the same lineage or similar function.

    On the other hand, applying ‘mundane’ project names (or versioning applications) does provide substantial value to the end user.

    I was particularly impressed with Novell’s use of the ‘Desktop Effects’ moniker. The idea of divorcing the functional name of a thing from the projects and code that make it happen provides a great deal of flexibility. Xgl/AIGLX is only a trivial example. From the desktop perspective, a feature is identified, and the implementation can vary, across versions, or in a more standard manner, across distributions and platforms. I think the KDE menu is another good example of this, with the Description/Cagetory sorting. If you have only one Web Browser, it’s what you get when you click on web browser, whether it’s Konqueror, Firefox, Mozilla, etc… ad infinitum. Or, if you have more than one option, they’re still categorized and described as ‘Web Browser’ (by default in a well configured distro).

    In my opinion, the only way to substantially improve the function/project separation would be to formally define a project’s function within a set of available functions; like a ‘mime-type’ for applications. So ‘Desktop Effects’ using Xgl+Compiz on SLED can be meaningfully compared to, say, ‘Desktop Effcts’ on Windows Vista, or ‘Desktop Effects’ using Sun’s Looking Glass.

  3. Using Beagle for the technology described as ‘Desktop search’ to the end user is a great thing for simplicity.

    However what happens when some middle layer tech guy at $corporation has heard all the great things that Beagle can do. They download $distrobution and can only find ‘Desktop search’.

    “They must have gotten rid of Beagle and gone to something else. So now I have to find a distro that has Beagle.”

    The other side to doing the switch without users being aware is those who script against a particular search tool only to have it changed out and replaced by an upgrade.

    ‘There’s an upgrade to desktop search. Let me get that’ and it changes the Beagle engine to the file-ferret engine.

  4. Chuck:
    I understand the concerns that you cite. I think I may have given you the impression that I am advocating that project names like “Beagle” becomes completely obfuscated. That would be bad.
    In SLED10, for example, the packages for Beagle are still called Beagle. Further, if you type “Beagle” in the filter on the Application Browser, the result produces “Desktop Search.” There are other examples. So, I make a clarification: when using functionally descriptive names for features and products, let’s not completely lose the project name. It does have value for technical users.
    That brings me to your script-dependency example: if the user writes scripts, he’s not the droids I’m looking for. In other words, the entire naming dialog I present is meant to open up Linux to new, less technical users. People who write scripts, or otherwise dwell in the CLI world do not apply. :)
    –T

  5. […] I’m still not sure how I feel about Ted’s post about project naming, but it feels significant, and is worth the read. […]

  6. […] Products and Projects: What’s in a Name? How to name your project. (tags: development) […]

  7. You forgot GIMP :)

    As much as I love it, it’s in painful need of a rename – who wants to put “The GIMP” on their product’s feature list?

  8. Very nice article. Although, I wish Novell had retained the NLD moniker. The “Desktop Search” should have a tag line of “by Beagle” or some such. Just my two cent.

  9. I agree with you Griff on the NLD name. It did have a certian ring to it. The SUSE name really deserved to be kept.

    Ted:
    Thanks for the clairification. One thing that didn’t even register with me until your reply is that if you have a project that is not from Novell and you obfuscate the origins. Not only is it valuable to technical users, but the origins are important for the original developers. After all, if they’re recognized through that software it could lead to other jobs and projects for them to develop on.

  10. […] Products and Projects: What’s in a Name? « Open Source Advocacy with Reverend Ted […]

  11. Great article Ted. While reading it, I immediately thought of Novell’s Bandit project. Although it’s identity services software, the name implies something less trustworthy.

    Identity information + Bandit (theif) = identity theft
    :)

  12. It was such an interesting article. It was mind- buggling and left me to think even after I have read it all . All I know is that names are very important because it is how we or anyhting is identified.

  13. Have a look at this discussion about the penguin, and as a matter of fact the suggestion of killing it: http://www.crn.com/nl/voices/showArticle.jhtml?articleId=192501076

  14. TenHoopen:
    Oddly enough, the Bandit project’s originally-proposed name was “Fido,” which was an acronym for something identity-related. They changed dog names. I think the idea of a masked bandit (identity masking) may have been a factor. Nevertheless, you raise a good point.
    –T

  15. […] Frank J. Ohlhorst of CRN recently published “Advice To Linux: Kill The Penguin,” which may seem in line with my recent comments about product and project naming. (Thanks for the tip off to reader Ray Epping!) […]

  16. “The Gimp” is a cultural thing, it means something completely different in English speaking countries like England (as opposed to its meaning in some former colonial territories – hey I just speak like this to wind Ted up).

    Cultural neutrality for a name is almost impossible to guarantee, just look for the history of “Google” in China.

    On the upside picking a nice English name, which means “we eat babies” in Mandarin Chinese guarantees you a lot of free publicity for years, even if you have to use another name in the Chinese market.

    As regards the “Kill the penguin”, this was done to death in /. a long while ago. When we pointed out that almost all GNU/Linux desktops already give better descriptive names than Microsoft Windows.

    Although I note that the default OpenOffice menu in Debian has regressed since then.

  17. Novell is really bad at using good names for their products.

    “IntraNetware” was merely an embarassement, but I still have no idea what products like iChain, Nsure and Nterprise do.

    Hello Marketing: Descriptive names are really important!

    –Bob.

  18. Is it too late to say, again, what a great piece this is?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: