Register your namespace!

Please, talk to other people (comp.lang.perl.modules, modules@perl.org or any mailing list that fits your problem domain) before you decide upon the namespace you're going to use for your module. Usually it's not considered the perl way to have beaurocratic conventions, but when it comes to namespace pollution, there is the need of coordination. Just like the InterNIC has to care for unique names for internet hosts, somebody has to (sort of) guarantee uniqueness, consistency, and sanity of module names. The modulelist is the place where all currently registered module names can be found and the email address modules@perl.org is an alias for a hand full of experienced volunteers who maintain the module list and--time permitting--try to give advice for the appropriate namespace for your modules.

Please consider the namespace you're going to occupy with all due sensitivity. Discuss it in the appropriate fora. Read what the modulelist has to say about this. Pay special attention to the hints about cutesy names. Reading these sections carefully will help you and us to greatly improve the usefulness of the CPAN and avoid cumbersome renaming at a later date.

Also: think carefully and honestly whether your module would be better off if it were integrated as an option into an already existing module. Sometimes it is for the best to put aside personal glory and join a collaborative effort: Perl itself is a good example of this. Contact the author of an existing module and ask whether your new features would fit into his framework. Even if you in the end decide to release the module as your very own, you really should know your 'competition', that is, know all the similar modules and the features they offer. Maybe you can learn from them, maybe you can help the users of your module better by giving them an overview about similar modules.

And please do consult the archives of modules@perl.org before you post a module proposal. The fulltext search capabilities of the archive should help you to find similar suggestions and contact addresses. modules@perl.org is low volume, so your search in the archive is quite targetted. modules@perl.org is not a mailing list. Please do not try to subscribe. We do not want to establish yet another perl mailing list. If we encounter hot topics, we move the discussion to the appropriate mailing lists. The traffic on modules@perl.org is archived at http://www.xray.mpe.mpg.de/mailing-lists/modules/. The module list maintainers themselves are mostly lurkers. You need not wait for a response. Generally a lack of response can be taken as acceptance of the module name being proposed.

When you're done with all your preparations, considerations, and investigations, visit the PAUSE and fill in the form for a new module namespace. Take your time filling in the rationale of the module proposal. Consider, your form will be posted to modules@perl.org too, so other developers will probably stumble over this description many years later. The better the decription, the better the chances that your module will actually be used.

You need not wait for approval. You can upload anytime, even before you fill in the form. Uploading and registering are only loosely coupled.

The indexes that are maintained automatically on CPAN all double check if the module names that are used in the uploaded packages are registered. The indexer unwraps all packages and scans the source code (namely all *.pm files) for package declarations. You run the risk of being ignored by the index generator if you do not talk to the modulelist maintainers about the namespace you are using.