The convention I use is to use a unique word: salza, skippy, zs3, etc. I don t really try to have a direct relationship to the library functionality. I try to avoid generic words that others might use like "zlib" or "zip" or "png".

Edi Weitz uses Frank Zappa-related words to name many of his packages: Hunchentoot, Drakma, etc.

Some people use Java-style org.foo.bar reversed domain naming.

So, the direct answer is no, there isn t a common, agreed-upon convention that everyone uses.

One convention that you see sometimes is packages which provide a thin compatibility wrapper over routinely implemented but non-standardized functionality are often called TRIVIAL-SOMETHING.

This leads to some really wonderful names: the library for working with *FEATURES* in a implementation-independent way is called TRIVIAL-FEATURES; even better, the library for interacting with the garbage collector in a standardized way is called TRIVIAL-GARBAGE.

There s no general convention, but there are a few patterns:

1. When the library is a port from some other language, a wrapper or an interface library it is often prefixed with cl-, like cl-gtk2 or cl-ppcre. Although there was a time, when this prefix got abused, and there are a lot of packages (e.g. cl-who), that implement a unique functionality, but still use it.
2. If the package is implementation-specific, it s prefixed with implementation shorthand (most notably: sb-), like sb-queue or lw-compat.
3. If the package is a compatibility layer between implementations, it is often prefixed with trivial-, like trivial-backtrace or trivial-garbage
4. There s also s- prefix, which may stand for symbolic , like s-xml, but it s rarely used.

These prefixes help making the name of the package unique and thus simplify finding information about it on the web.

Otherwise there are no specific conventions, but the general rule is to favor short, unique and, probably, descriptive names. For the reasons of ease of remembering, usage and finding information.

If the package happens to have a long name it s handy to provide a shorter nickname, because more often, than not people will use package s symbols qualified by their names. For example in my code I add a nickname re to cl-ppcre, and it makes the client code much more understandable and clear. Although caution should be applied, so that nicknames didn t cause name-conflicts.