I don't think you should feel the need to apologise. I've just read the thread 3 times and see nothing much for you to apologise for:)

From my perspective, CPAN is a great idea, and much of what is on CPAN is great too, but some of it is not-so-great, and some is not good at all.

If there is one single critisism that I would level at CPAN--and I know I will take a hit for saying this out loud--it is a lack of coordinated design.

This manifests itself in several ways:

• Modules that provide one extremely useful and needed facility, that carry a burden of "flesh it out" code in order to justify the modules existance.

  I won't cite examples as I have stepped on toes before, but there are several modules that I have installed, and many more I have rejected, that provide something I need, but carry so many extras that I don't want or need.

  Would it not be possible to provide the core functionality as one module that is as light and efficient as possible, and where there are nice-to-have or logical-extensions to that functionality, then provide these as add-ons that sit below the main namespace and that can be installed as an option.

  This segregation would have several benefits:

  1. It would become clear from download statistics which parts are most used and which are not.
  2. It becomes easier to download and install.
  3. It becomes easier to document.
  4. It becomes easier to read the documentation.
  5. It becomes easier to maintain.
  
  
• Another problem is the lack of a coordinated style of interface.

  A couple of times I have tried to use two or more seperate modules from CPAN together, and found myself having to write glue-code in order to get them to work together. A typical examples is where source data is read from some source other than a file and then needs to be processed in some fashion by another modules that will only accept a filename or a filehandle as the source of its data.

  You might say that why complain about writing glue code if 90% of your application has been done for you, but the problem is often that the glue code required spends time undoing stuff that one module did, in order to supply the intermediate data to the second module which promptly redoes it.

  Okay, so I can modify the source to avoid this.

  The downside is that then that everyone ends up modifying the sources of the modules--each in a different way--to fit their particular needs, but it is impossible to feed these changes back into the original module as doing so would either:

  • Break existing applications.
  • Or add weight to the original module by providing multiple interfaces.
  
  
• There are often inconsistancies within the interface of a single module.

  Again avoiding directly naming them, but one of my favorite modules in terms of the functionality it provides, also gives me the screaming heebee-jeebeies every time I use it because the interface is so inconsistant. Some of the function names are CamelCased(), some of them are underscore_seperated(), some of them are A_Combination_Of_The_Two(). This forces me to have to look the details up each and every time I use the module--which in this case is itself not an easy task as the documentation is so volumnous, but I get to that next.

• Documentation.

  Many modules suffer from bad documentation. The ways in which it is bad span the whole spectrum. In some cases, it is too little, in others too much. In some, you have reference material mixed up with tutorial material with FAQ material, and in some cases volumous background and research materials.

  This isn't intended as critisism, it is simply meant as a statement of fact.

  Documentation is a thankless task. Not only is it hard to do, but no matter how you do it, it will always be subject to critisism.

• There is considerable duplication on CPAN.

  Not only duplication one whole module by another whole module, but also, and more difficult to address, duplicated functionality as small parts of several modules. Anyone care to count the number of different modules that could be used to do URL encoding? It should be possible to isolate those parts into a single, seperate module. It might make sense to then combine these seperated small functions into one or more 'utility' modules in much the same manner as the POSIX module, which despite its size and diverse function, imposes a relatively light overhead on programs that use it because of its design of only loading those functions requested. This is a model that could be used more.

• The is some proportion of the modules on CPAN that are badly implemented. Depending on what you read and where you read it, so the characterisation of the percentage involved varies, and no doubt that characterisation will vary upon individual experiences of using (or attempting to use) the modules in question.
• There are modules, including well used and well supported modules, that lump a great deal of functionality and in some cases multiple interfaces into a single monolithic lump. Wouldn't it be better to seperate this functionality into several modules? Perhaps the procedural interfaces in one module and a seperate module that wraps the procedural interface in an oo-style one?
• Last, but not least, there are quite a few modules on CPAN that have fallen out of support. It is not easy to determine which modules these are. How do you tell the difference between a module that hasn't be upgraded for a couple of years because the author lost interest, or the time to maintain it, or because the module is stable and efficient, or because it has been superceded and noone uses it anymore, so there are no bugs raised against it and so no incentive for upgrades?

Having nailed my colors to the mast on things CPAN related, it is tempting to try and propose solutions to the critisisms I have outlined. I will refrain from doing so as I am aware that my relative newness to the Perl community, and my total lack of contributions to CPAN will make any proposals I do have--which are many--come from a foundless base.

What I would like to do is see if there is anyway that I can contribute to a resolution to the issues I have identified and the first step is to enquire if there is sufficient support for starting a movement to address those issues.

Do enough people within the community consider some or all of the above to be problems?

Is there any support for moves to 'fix' those problems?

Is this a suitable forum for raising the issues and coordinating efforts to do so?

Often the biggest issues in attempting to resolve issues of this type are

1. Finding enough people with enough time to contribute to persuing the tasks.
2. Coordinating the efforts in a way that allows wide participation.
3. Embuing the efforts with sufficient authority to make the exercise worthwhile.

Personally, I can find time to contribute to the process, and I have had some experience that might contribute to the coordination and development of some solutions. The area where I can not contribute is that of authority. My lack of standing withing the community means that I could never lead such moves, but if there is any will to address the issues, I would be only to willing to contribute in any and every way I can.