Here's a few reasons:

1. When you are doing so in order to "have a presence on CPAN".
2. When you have not utilised the module for at least two, different, real projects that make substantial use of it.
3. When you are not in a position to test it on at least 2 disparate platforms.
4. When you are unlikely to ever take the module beyond the first flush of interest.

   Ie. It will forever remain as version 0.xxx so that you can get away with a disclaimer about "use at you own risk".

5. When you are entirely unconvinced by the process and procedures that make up what might loosely be termed the CPAN requirements.

With a few more minutes thought I could probably come up with another half dozen.

Of course, most of these fly in the face of Perl community/OSS doctrines that suggest, amongst other things, publishing early and often. And this post will probably be seen as a rail against those doctrines--it isn't--and down-voted accordingly--which is fine.

Of the modules that I have written for my own purposes that might be (IMO) suitable candidates for CPAN, I have either:

• Lost interest and therefore would resent spending time maintaining them.
• Found problems during my own testing and use that I have yet to find a good solution to.

  In one case, the premise of the module was that it would do what it does in a substantially more space efficient manner than the 'normal' mechanism, whilst retaining a reasonable level of performance (kind of the use less 'memory'; idea). Whilst it is more space efficient, and early in testing, it showed good promise for performance, once I started tackling the edge cases, adding the extra overheads of validation, and handling a full range of binary data, it meant that the performance fell off markedly.

  For my own purposes, I am, prepared to live without the edge case detection to benefit from the performance, but having written the code, I understand its limitations in use. For the general case, even documenting those limitations is not sufficient (IMO) to make the code usable in production environments, and with the edge case detection, the performance drops to the point where the benefits are questionable.

  In another case, the module functions fine, nine times out of 10, but on the 10th occasion it will throw a wobbly. Again, for my purpose, ie. the purpose for which I originally wrote it, it functioned fine and allowed me to do what I needed to do, but for it to be usable as a general purpose tool (in an already well represented category) I would need to find and correct that flaw.

  Given there are several existing tools that are well known, well used and well supported (including a core module), the major benefit mine has over those others is a niche requirement. So, I had to ask myself whether I was prepared for the work involved to bring the module up to the standards that I would like to expect from a module on CPAN. And would that effort be of great benefit in an already crowded market. My conclusion was no.

• Finally, there is an expectation of compliance with certain ways of presenting and delivering CPAN modules. I'm not referring to quality specifically, but more "the way things are done".

  I have a strong distaste for several of these ways of working. My objections are neither frivolous nor contrary. They are based upon my considered opinion formed over many years as a coder, and upon my few years of using Perl. Individually, no one of them would prevent me from complying with the 'standard practice', but cumulatively, they amount to an intense and constant irritation when I have to perpetuate them.

  I have expressed several of my reservations here in various posts over the last 3 1/2 years, and gauged the usually negative, often hostile, sometimes knee-jerk, reaction to them. I have, accordingly, re-considered my position on them several times. And mostly, each time reached the same position as I started with.

  Hence, I've decided that it simply isn't worth the perpetual irritation of complying with working practices with which I do not agree, for stuff I do as a hobby. Having spent the best part of 25 years complying with other peoples (often ill-judged) coding standards and working practices in order to earn a living, I feel no incentive to do so with stuff I write for fun, for my own education, and in the hope that it may occasionally be useful to others.

  In a democracy, the majority is always right. In my free-time, I am a majority of one.

  In the workplace, the boss, or the client, or the customer or entrenched dogma is right. The guy paying the money is the final arbiter and you choose your position and suffer your irritations accordingly. Working alone, in my own home, and in my own time, I do not have to suffer those irritations, or bend my position to the will of those others.

  This changes when in paid employment, or even unpaid collaboration. Though in the latter case, I would anticipate at least a hearing on an equal footing, before submerging my own opinions and preferences in favour of those of another.

So, when you make your decision about whether to publish your module, which to me seems a perfectly reasonable approach to a perpetual thorn in Perl's side--it's lack of compile-time signature checks combined with either repetitive manual parameter checking, or high overhead automated checks--consider your position carefully.

Given Perl's already tardy sub/method call performance, anything, that moves some of the overheads to compile-time has to be worthy of serious consideration. Even if it does rely upon a coding technique that is universally scorned because it imposes a need for a high level of care and testing upon the author and may impose an extra degree of care and limitation upon it users. That extra care will mostly relate to their choice of the forms of syntax and source code formatting they use. As your module is hardly likely to see great use in obfus or golf games, which are the only places that the most quirky and difficult areas of Perl's syntax usually see light of day, most production code should already be formatted to a level of cleanliness that should avoid most of the traps that befoul source-filters.

Assuming you exercise appropriate care in its construction and testing :)

Consider your position in the knowledge that, whilst PM is generally a tolerant and happy place to coexist, the wider Perl community has it's dogmas and can be pretty ruthlessly intolerant of even well considered contrary opinion to them. And, within that wider community, whilst there are several camps, of loosely grouped subsets of opinion, there are also some areas where the entire group will come together to ... what was that word I saw someone use recently... kibitz those that voice opinions contrary to the established dogmas.

Good luck with your module, and if possible, I would like to have a play with a copy--even if you decide not to make it generally available.