CPAN is full of joke modules and I'm not talking about them, we all know ACME::, those are serious projects centered around fun.

What I'm talking about is research modules, something that you're working on, you've got some part working, you would like some feedback from community, but eventually it is supposed to be merged into some other project or re-written?

The important thing here is - if it's going to be merged, and in the meantime someone started using your module, they'd be left out in the cold. How should one warn people about experimental status of one's code?

I think a CPAN module should be the result of someone having solved a certain task by writing some code for the given problem. Even if that problem is very small, or very specific, or the solution is limited in scope or still incomplete, that code could potentially help ( or in the case of Acme modules, entertain) someone else, so it should be on CPAN.

Now, if the task is not solved yet, and the author is still looking for a good way to tackle the problem or is not even sure if he wants to finish this at all, it is IMHO better left outside of CPAN, for example in a Perl monk scratchpad.

If it's experimental or alpha code CPAN will ignore it if there's an underscore in the distribution name (blah-0.01_01). It'll be available through CPAN.pm but the user will need to explicitly say install A/AU/AUTHOR/blah-0.01_01.tar.gz rather than just install Blah.

Well, CPAN doesn't need any "modules of type X". CPAN is just a repository (and perhaps a delivery mechanism). But, despite your title, that's not the question you are asking. Your question is is it acceptable to upload modules of type X, or should I refrain from doing so, where X is something you call "research".

I can't come up with a reason why you shouldn't. If I'm interested in your module, I can download it. Or else, I just ignore it. The few bytes it cost me in the increased index files residing in my .cpan directory I can live with.

I'm not sure users of a no longer maintained module are entirely 'out in the cold'. OK, they're stuck at a certain point, but as long as you don't delete your original file, they face a choice:

1) Update their dependent code to reflect any interface changes with the new merged module

2) Stick with the old module (risking new versions of other modules or perl deprecating some of the code)

In the latter case, we have to assume that an experimental module isn't likely to be a huge complex undertaking like DBI, and a few code fixes to get around deprecated useages are not too much of a problem.

I do think you are right and that users should be clearly warned that the code is experimental though. If it was stated in the POD, readme and filename that would be pretty clear.

I like the underscore idea as well - forcing a user to follow an extra step in installation highlights the experimental nature of the code quite nicely and reduces the likelihood that casual users will inadvertently install it.

You're not the only one to wonder about this. Whenever I do something that results in something greater than just a few lines, I want to share it. CPAN would be the ideal place, but its infrastructure isn't really suited as it is right now.

One solution might be the introduction of a new top level namespace, like SandBox, or whatever. And in that, anything can be dropped, with even less guarantees than the total lack of guarantees a module usually has :)

Of course, Perl Monks at first sight is a better idea. After all, it has several sections just for posting code. However, CPAN is nicer. Via search.cpan.org, documentation can be read, and any project can easily be downloaded by people who want to try it. Besides that, you can upload distributions, in which you can do a whole lot more than in anything you can copy and paste into a simple textarea.

Strictly, a new namespace isn't necessary. But it would help for scripts like minicpan, so they can easily see which distributions to exclude.

Short answer: Yes, upload anything you think others might find useful. Long answer: Seek advice from other module authors before uploading a new module. I find the CPAN module-authors mailing list perfect for this sort of thing. Send an email to module-authors-info <at> perl <dot> org to learn how to subscribe. People frequently request code reviews, naming help, etc on this list.

What I'm talking about is research modules, something that you're working on, you've got some part working, you would like some feedback from community, but eventually it is supposed to be merged into some other project or re-written?

Have you considered Sourceforge? It would seem to be a logical place for projects that are just in the research phase.

Then, as your code gets more solid, I would consult re module name on the module-authors list as another monk suggested.

I don't think Sourceforge is a good idea. It is really intended for full scale projects, and is likely to be even less suited to a small module than CPAN.

However, there is a problem with proliferation of modules on CPAN. It's getting harder, in my experience, to find interesting new modules, just because of the sheer size of CPAN. Also, often modules appear with no prior discussion on the mailing list. I don't think this is helpful, at least in general.

Some kind of peer review of CPAN modules would be useful. probably informal, like the XP system here, rather than a formal (and costly) system, like that used in the scientific literature.