You don't find often books of 1st grade students in the university libraries. That is - books that were written by them.

I dislike analogies since they often conceal as much as they reveal. However if we're going that route, you might want to consider some of these points:

I'd recommend giving The Zen of Comprehensive Archive Networks a read. A couple of relevant quotes:

Code quality? Ratings/reviews? Moderation/metamoderation? "Approved" SDKs? These all are hotly debated subjects and will not be addressed here since the CPAN is and will stay an open and free forum, where the authors decide what they upload. Any further selection belongs to different fora. Besides, adding any rating or approval processes creates bottlenecks, and bottlenecks are bad.

...

Another important credo is: Avoid bottlenecks and interdependencies. Decentralize. Create and encourage alternatives. For example, the most popular search engine of CPAN isn't actually part of CPAN proper: search.cpan.org just mirrors CPAN and from the data builds the search indices and searching/browsing interfaces. That's way there can be several seach engines of the same CPAN. Similarly, currently we use CPAN.pm + MakeMaker to install modules: but we are not committed to either, and the community is working on replacements. Keep things loosely connected. This allows for different people to work on their own enhancements without disturbing the other parts.

CPAN doesn't need gatekeepers.

What CPAN needs (if it needs anything at all) are editors and reviewers. Guides to what is good and bad. Specialist overviews like the perl-qa groups Summary of Test:: modules.

The good news is all the infrastructure is there. CPAN is open. CPAN Ratings is open. CPAN Testers is open. Gluing them together isn't that hard. If you feel that a peer reviewed view of CPAN is a good idea find some like minded individuals and implement. Don't try to control CPAN from the bottom. Add another layer on the top. To take a couple more quotes from TZOCAN:

There is no magic. All it takes is a few people that sit down and get first something running, a rough cut. Then iteratively enhance it. Don't try to create a master plan that will get everything right in one fell swoop. The only one that will get swooped is you.

One way to summarize most of the above is the priceless KISS principle-- Keep It Simple, Stupid. Avoid too complex setups. Start simple.

...

Perhaps the most demanding thing is commitment: someone must keep things running

People aren't afraid of improving the quality of modules (witness the Phalanx project). What people are afraid of are the unintentional side-effects of changing the way that CPAN works. Adding an approval bottleneck to all of CPAN is, IMHO, a really poor way of addressing the problem of poor quality.

I'm also not entirely sure if the 'problem' is more perceived than actual. People have been predicting that CPAN will become useless under the pressure of poor modules ever since I started using Perl (a good many years ago now). And yet progress continues apace and Perl just carries on getting more and more useful.

In reply to Re^3: The quantity vs. quality lesson by adrianh
in thread The quantity vs. quality lesson by PetaMem

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.