Requesting Comments

Chapter 5 - Submitting Your Module to CPAN
by?Sam Tregar?
Apress ? 2002
Companion Web Site

The first step in submitting a new CPAN module is to introduce your idea to the Perl community. A common way to do this is to post a Request For Comments (RFC). An RFC is a message that describes your module and publicly solicits responses. It's common to post RFCs for new modules to the comp.lang.perl.modules Usenet^[1] newsgroup as well as any e-mail mailing lists that are relevant to your module. A typical RFC message looks something like:

 From: [e-mail] Subject: [RFC] Data::Counter Hello all - I've written a new module called Data::Counter that I'm planning to put on CPAN. Take a look at the documentation and tell me what you think. NAME     Data::Counter - a module that counts your data DESCRIPTION     ... 

An easy way to produce the content for the message is to use the pod2text script that comes with Perl to create a plaintext copy of your module's POD documentation.

Caution 

The perl5-porters mailing list is not a good place to send your RFC. The perl5-porters are responsible for developing Perl itself and are not very patient with people who mistake their mailing list for a general Perl discussion area.

If your RFC receives any replies, then it's likely that some of them will be negative.^[2] You should treat criticism seriously, but don't let it prevent you from releasing your module—there are plenty of successful CPAN modules that began their lives with controversy! On the other hand, if you receive no replies, you should take that as a sign that you haven't found your user community yet. Keep looking—your module will only be a success if people use it, and they'll need to hear about it first!

One of the most sensitive issues for a new CPAN module is the module's name. Since all CPAN modules share a global namespace, everyone has a stake in making sure modules are named appropriately. If you're not certain that you have the right name for your module, then you should include a section in your RFC discussing possible alternatives. Avoid the most common mistakes in module naming— creating new top-level namespaces needlessly (such as Profile::DBI instead of DBIx::Profile), cute or funny names (for example, D'oh), or ego-based names (for example, Sam::Template).

Your goal in naming your module is to provide potential users with a clear picture of what your module does even before they look at your documentation. This is often a difficult task, but it is so critical to your module's success that you should spend the time to do it right.

Be aware that some module namespaces are administrated by a particular person or group (Tk::, Apache::, and DBI::, among others). This information is usually contained in the documentation for the "root" module—for example, the DBI module contains contact information regarding the DBI:: and DBIx:: namespaces. Even when the author of a module hasn't explicitly laid claim to the module namespace, you should contact him or her before uploading. For example, it would be polite to contact that author of CGI::Application before releasing CGI::Application::BBS.

^[1]Usenet is a distributed messaging system that's been around almost as long as the Internet itself. You might have access to Usenet through your Internet service provider; if not, there are several Web sites that provide gateways to Usenet. One good one is http://www.groups.google.com.

^[2]Particularly true on Usenet!