Products and Projects: What's in a Name?
,----[ Quote ]
| 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.
`----
http://reverendted.wordpress.com/2006/08/30/products-and-projects-whats-in-a-name/
|
|
