Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

The quantity vs. quality lesson

by PetaMem (Priest)
on Jun 01, 2004 at 09:01 UTC ( #357967=perlmeditation: print w/ replies, xml ) Need Help??

Dear Monks,

I know, the issue of QA for CPAN has been brought up at least a thousand times, by far more experienced monks or perl adepts. It has also been answered that many times by even so experienced people - with the result CPAN staying CPAN.

I like CPAN and use it quite extensively, and contribute or "manage, that is being contributed". But now - again - for me the time has come to express my unsatisfaction about the "zero threshold" that is applied for module contribution to CPAN.

If this policy was/is here to allow for fast/seamless growth of the CPAN module repository, well - with several thousand modules in existence it has IMHO more than fulfilled this objective of quantitative growth.

But let's face it: There _IS_ crap on CPAN. And there _IS_ lots of duplicate modules and there _IS_ lots of modules whose functionality is nearly equivalent, but where you have to pick the "good one" from a set of existing. This has been discussed in length before, but evidence is, that the results of these discussions were void.

To me, the natural evolution of CPAN and the "must go" way is so clear, that the only explanation I have for it not happening, is something that will surely bring many - - from the zealots that are to be found in every monastery:

I wouldn't object to the theory, that the Perl community *fears*, that a rigorous evaluation and control of the CPAN modules would bring the poor condition of the CPAN repository to light.

I think we must not fear, but have faith. Yes, it will be painful to see, that 40% of the modules are crap and/or outdated and/or unfinished, another 20% being so-so, 20% being suboptimal, leaving 15% good/useful and 5% superb modules.

There exist hundreds of ideas - some also crap but others perfect - how to improve quality of CPAN. This is technical detail IMHO. What matters most, is to get the Perl community to accept such a project/shift. As for now, it seems like a holy cow where even providing download statistics or some kind of voting system is perceived as a hypothetic discrimination...

IMHO there is a golden way between the present laissez faire and "running the gauntlet" for module authors. My dream is, that we - the community - find and adopt it.

Update:

If I look at the comments to this post and really "listen" to them, I think I now understand the nature of CPAN more thoroughly. And this will help me do better decisions concerning it in the future. Thank you.

Bye
 PetaMem
    All Perl:   MT, NLP, NLU

Comment on The quantity vs. quality lesson
Re: The quantity vs. quality lesson
by borisz (Canon) on Jun 01, 2004 at 09:13 UTC
    There might be a lot of crap on CPAN, but who wants to appoint what is crap? And remove a module, that might be used by some people already? If you like to be helpfull to other people rate a module good or bad. This makes my choice more easy next time.
    Boris
      I have no problem in rating a module. I could do this day and night and not fear that I'm "discriminating" the author. But if I do this in some hidden thread @ PM (perlmonks), or in PM (personal mail), I will help an/several order(s) of magnitude less people, than if CPAN natively provided such a voting/commentary mechanism.

      E.g. comment for a given module:

      Tree::Nary

      • the author has not time to maintain it
      • it is written as a 1:1 transcript from a C implementation of Nary trees. Moreover it uses a hash for every node. If native Perl structures were used such as Lists, the memory requirements would go down 50% and the speed improve by a factor of 5.
      • if the module was rewritten more radically so an object would be a whole tree (using lists of lists) and not every leaf, this would give a memory requirement of 25% of the CPAN solution and a speed improvement by a factor of 38!
      How do I know? I have these implementations here. Will I contribute them? Not to this CPAN.

      Lingua::NL::Numbers

      • generates simply wrong output. Bug: 1100 is "duisend" (thousand)
      Lingua::IT::Numbers
      • requires 5.8.2 with no reason
      • The most bloated module I've ever seen. requires Regexp::Common::numbers for NO reason.

      Bye
       PetaMem
          All Perl:   MT, NLP, NLU

        I think CPAN is good enough for all this.
        • Tree::Nary is propably not the best module, but if you remove that _that_ might force to rewrite or reinvent what Tree::Nary does already.
        • If you have a better idea of the same module ask the author and maintain the module.
        • If your module is very different, since your interface change, release a new module. And describe the need for the new module in your pod.
        • If Lingua::NL::Numbers generates wrong output use http://rt.cpan.org/ to inform the author and others about the bug.
        • And for Lingua::IT::Numbers I recommend provide a patch to the author and put the patch and a discription on http://rt.cpan.org/.
        • Boris
        I will help an/several order(s) of magnitude less people, than if CPAN natively provided such a voting/commentary mechanism.

        Which it does. We have:

        All of which are integrated into http://search.cpan.org/.

        If the author doesn't have time to maintain it and you have a better solution, then why don't you offer to adopt the module and release your improved version? There are at least 10 modules I know of where this was the case.

        If you have thoughts about a module, THEN TELL THE AUTHOR. I would love to have this kind of feedback about my modules. But, you know what, people don't tell me! Why, I have no idea. (PDF::Template, Excel::Template, Graph::Template - in case you're wondering)

        ------
        We are the carpenters and bricklayers of the Information Age.

        Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

        I shouldn't have to say this, but any code, unless otherwise stated, is untested

        Let me add to the list of sinners another module which is not ripe for primetime:
        Lingua::DE::Num2Word

        Which is a CPAN Module provided by your Company and runs also on your companies website, It is only useable after reading the sourcecode and only if you know German, to understand your implementation of the cardinal number 1 . I for myself view the missing information about the handling of the number 1 at least as a documentation bug. So my advice as a reviewer is to not use this Module except for hobby projects.

        Expample: 4801 becomes viertausendachthundertein. This is not exactly wrong, but documentation is needed.
        How do I know? I have these implementations here. Will I contribute them? Not to this CPAN.

        Right, you write perfect software but you won't lower yourself to our level. What an excuse. As others have said, the best way of increasing the quality of CPAN is by contributing quality software. Also, if you submit the bugs and reviews through the proper channels instead of whining here you'll have a better change of getting them fixed.

Re: The quantity vs. quality lesson
by Abigail-II (Bishop) on Jun 01, 2004 at 09:48 UTC
    There exist hundreds of ideas - some also crap but others perfect - how to improve quality of CPAN.
    By submitting high quality modules, increasing the overall quality of CPAN.
    I wouldn't object to the theory, that the Perl community *fears*, that a rigorous evaluation and control of the CPAN modules would bring the poor condition of the CPAN repository to light.
    Have all the theories you want, but CPAN isn't "owned" by "the Perl community". CPAN is a project of a few (Jarkko, Andreas, Elaine, ...). Anyone is free to contribute. Anyone is free to not contribute. Anyone is free to start another project, with a different policy. But CPAN's policy has always been that anything is welcome, as long as it's freely distributable (and Perl related). And the CPAN people have stated in the past that this will be the policy for the foreseeable future. Any sort of "control" over modules on CPAN will make that CPAN no longer is CPAN. CPAN is a huge success, and in my opinion one of the major reasons, if not the most important reason of the success of Perl. Even if you could, would you be willing to risk that?
    There exist hundreds of ideas - some also crap but others perfect - how to improve quality of CPAN. This is technical detail IMHO. What matters most, is to get the Perl community to accept such a project/shift. As for now, it seems like a holy cow where even providing download statistics or some kind of voting system is perceived as a hypothetic discrimination...

    IMHO there is a golden way between the present laissez faire and "running the gauntlet" for module authors. My dream is, that we - the community - find and adopt it.

    I really hate this kinds of posts. It's of the form "I don't like X. We should do something about it." But if offers zero suggestions of what should be done. And while it mentions "hundreds of ideas" from the past to change it, it discusses none. You probably rake in a fair amount of XP because of its emotional value, specially if some sucker frontpages it. You get a '--' from me though, because it's just whining, and calling others to solve your (perceived) problems.

    Abigail

      I take your argument, that CPAN is a project of a few, and has its policy. Probably I will start a CPAN2 at some point, probably it will be an "internal set of modules" that will not go to CPAN. Whatever will seem to be more apropriate.

      I wasn't discussing the "hundreds of ideas" in the first post, because I know of the lethargy of the communities (and that's not specific to the Perl community) when it comes to these things. So why waste time?

      The point is NOT "I don't like X, We should do something about it." But it is:

      "I have evidence, that X is far below where it could be, but I'm alone am not able to change it. If there are people out there who think similar, lets do something about it."

      Well - at least I think I'm not able to do it alone. We'll see.

      Bye
       PetaMem
          All Perl:   MT, NLP, NLU

        I don't think a CPAN2 is a good idea. It would be easier to make the current CPAN a better place. And thats quite easy by just writing another Gate to CPAN. So in your case, you could write a kind of search cpan e.g. for linguists which just returns trusted modules who passed your reviews. Thats all needed for a better CPAN, including only the part of CPAN you or your contributers are able to judge. Gateways for specialists like Linguists, Biologists or whatever seem to be a good way, to make CPAN a better place. That probably will not change the attitude of some writers, who advanced to lesson 2 of there beginners textbook of some foreign language, to immediately write crap modules, but at least we could find out, which modules we can trust or not.

        If you want to start such a project, I may volunteer to participate, if it does not become an aggressive page. This means, fair reviews even if this means "crap module" are fine to me, after the author had a change to correct his mistakes. Writing "crap module" without contacting the author in advance, is not the kind of style I could cope with.
Re: The quantity vs. quality lesson
by PodMaster (Abbot) on Jun 01, 2004 at 09:50 UTC
    I know, the issue of QA for CPAN has been brought up at least a thousand times, by far more experienced monks or perl adepts. It has also been answered that many times by even so experienced people - with the result CPAN staying CPAN.
    Of course, otherwise CPAN would not be the Comprehensive Perl Archive Network, a large collection of Perl software and documentation.
    But let's face it: There _IS_ crap on CPAN. And there _IS_ lots of duplicate modules and there _IS_ lots of modules whose functionality is nearly equivalent, but where you have to pick the "good one" from a set of existing. This has been discussed in length before, but evidence is, that the results of these discussions were void.
    There's crap everywhere. I would not call DateTime void. I would not cpanratings void.
    I wouldn't object to the theory, that the Perl community *fears*, that a rigorous evaluation and control of the CPAN modules would bring the poor condition of the CPAN repository to light.
    Sure there is poor quality software there, but CPAN is practically in perfect condition (alive and well, plenty of mirrors...).

    As for fear? I'm all for rigorous evaluation and it goes on all time time, but control? NO CONTROL! If you want some kind of ogre-like control, start up your own network (rejecting modules from CPAN because they aren't quality software is not smart).

    how to improve quality of CPAN. This is technical detail IMHO.
    I think that is http://qa.perl.org/
    IMHO there is a golden way between the present laissez faire and "running the gauntlet" for module authors. My dream is, that we - the community - find and adopt it.
    There is nothing stopping the community (or you) from "running the gauntlet", but it should never stop an author from uploading some shabby (not shady) software.
    update: <--commented out leftover, added above sentance in its place

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

      but it should never stop an author from uploading some shabby (not shady) software.

      And on this I disagree.

      I would agree on your - now deleted - comment on crap on slashdot. I would also agree if someone would state, that the thousands of packages in linux distributions have also much crap "in between".

      How can you know of such a pollution, allow it to misguide interested newcommers and sleep well? :-)

      Bye
       PetaMem
          All Perl:   MT, NLP, NLU

        How can you know of such a pollution, allow it to misguide interested newcommers and sleep well? :-)
        How can you? Lingua-IT-Numbers still has no review or bug report. What's the hold up?

        MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
        I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
        ** The third rule of perl club is a statement of fact: pod is sexy.

Re: The quantity vs. quality lesson
by perlfan (Curate) on Jun 01, 2004 at 17:30 UTC
    Why can't one proactive soul start up a page/app somewhere to rate/comment/judge modules. If it is beneficial, then its use should increase and will it become part of the Perl family of websites. If it is not, then it will wither and die.

    We have a community based upon module release (CPAN.org), why can't we have a voluntary site based upon module quality?

    Perhaps positive peer pressure can be used to improve the situations that the author brings to light.
Re: The quantity vs. quality lesson
by mrpeabody (Friar) on Jun 01, 2004 at 18:12 UTC
    How do I know? I have these implementations here. Will I contribute them? Not to this CPAN.
    How does refusing to contribute high-quality modules serve your stated goal of improving the quality of CPAN? Are you trying to punish CPAN or the Perl community by withholding your modules? What would happen if everybody followed your example?

    The key point that you disagree on with me and at least some others in this thread is that "Unrestricted CPAN submission increases CPAN usefulness, Perl usefulness, and Perl popularity". As a CPAN user, I certainly appreciate being able to see everything that the contributors have to offer. If a module is crap or unmaintained, it's usually obvious pretty quickly. And even if it's not suitable for immediate use, I may be able to take some ideas or code from it, thereby making the job of re-implementing the module easier.

    As a CPAN contributor (which I am not now but may be someday), I will appreciate being able to contribute my module, even if it is not 100% perfect and bug-free. That way I can get the most feedback on my code and contribute to others' use of Perl.

Re: The quantity vs. quality lesson
by perrin (Chancellor) on Jun 01, 2004 at 18:31 UTC
    The most useful suggestion that I've heard in the past is to create a sort of distribution or SDK of selected modules which are known to be very high-quality. You can start it as a bundle, and eventually offer source and binary distributions for various platforms (RPMs, etc.). Then you can promote what is essentially a private CPAN with your own specific branding.
      Do you mean like p5ee? Been tried, didn't work.
        No, it has not been tried, at least not by p5ee. Setting up a mailing list and one web page does not amount to much. If you really want this to work, you need to promote it. You also have to have something to promote, i.e. more than just ideas. This would mean a starter set of modules, a clear set of criteria for how modules are chosen, a procedure for nominating and approving modules, and possibly a separate distribution source which provides ready-to-use binaries or at least a one-shot source download with an automated build script. The p5ee project had no clear goal, and there were many people who wanted to define a new set of APIs rather than choose existing CPAN modules.
Re: The quantity vs. quality lesson
by tilly (Archbishop) on Jun 01, 2004 at 23:57 UTC
    I'd suggest that you read up on End-To-End Arguments in System Design and then a few essays by Andrew Odlyzko. The point which nobody ever comes out and says, but is definitely true, is that the free-est tent is always the one that collects the most people. Once you get critical mass there, you definitely see a Worse is Better phenomena, where the structure that is clearly "worse" does better in the long-run through positive network effects.

    You might not draw the same conclusions that I do from those sources. I didn't until I spent a long time stewing with the ideas. And I don't have time and energy to really explain myself right now. However my conclusion after some thought is that the simplicity of CPAN that leads to your complaints also is what causes it to succeed. As much as we might like more form, imposing form imposes barriers to entry which would have kept CPAN from taking off.
      I fully agree with you. The strategy was (evidently) perfect for the growth and establishment of CPAN. My point is: I think we HAVE reached the critical mass already - probably long ago.

      In fact, I'd like to compare it with some economists view where the only solution to successfull further (market) growth is seen in qualitative growth and not quantitative growth.

      One must see that things are changing and adapt to the new situation. Times today are different from when CPAN was built. Perlmonks surely has a few hundred thousand nodes more than it had at the time... There are many experienced perl coders around who can (and I'm sure will) give contributors a helping hand. There's much more guidance in general as both the sw business in general and specifically perl have evolved.

      It wouldn't hurt IMHO to have focus on quality for some time. If the perl community starts to grow too old, because not enough "newbies" come to it, expect me being the first who'd again write the node number 1234492734 at perlmonks to propose to lower the standards.

      (And probably get beaten by 60-year old tilly: "But long ago you wrote...") :-)

      Bye
       PetaMem
          All Perl:   MT, NLP, NLU

        The right way to get quality is not killing the low level people, is creating ways to this people to be better! If you don't agree with that we just need to remove from the country all the people that are invalid or that doesn't have good graduation! In other words, we need to give opportunity for every one, and not to hide them.

        Tell me what is more important, have a bigger percentage of good modules or have more good modules?! in other words, what is better, have 90 good modules in 100 (90% of quality), or have 900 good modules in 10000 (9%)?

        Duh, 900 module, of course, since all the other bad modules are not creating problems to this 900 modules or authors!

        Graciliano M. P.
        "Creativity is the expression of the liberty".

Re: The quantity vs. quality lesson
by baruch (Beadle) on Jun 02, 2004 at 01:53 UTC

    You've got a good point - is sheer volume worth the loss of quality? However, Borisz also pointed out two issues - 1) who's going to be the judge, and 2) what happens to if things break when supposedly poor-quality stuff is removed.

    Perhaps a way around this would be to have two sections on CPAN - one for general modules, and another for modules that have been "certified" or otherwise validated or recognized. I don't know how practical that would be, but at least it would reduce the likelihood of modules being removed that someone relies on.

    I didn't understand your comment about having a better implementation, but not being willing to contribute it to thisCPAN. Why not? I can't see that it would do you any harm. But of course, that's your decision...


    בּרוּך
      Clearly the removal of old modules is the biggest challenge. It is a well known fact, that a big portion of the software and hardware industry has to cope with "Legacy" CPAN and Perl are no exceptions.
      I see several prerequisites for that to be able to happen for every individual module:

      • The module must be OIR (old, infrequent, replaceable), that is: last update n years ago, maintainer has no time, not used often, another - better - module exists and there is a migration path. old2new, which the author of the new one provides (as sign of maintenance commitment). That was for old and replaceable. As for "infrequent" I *do*think, that quite raw download statistics do provide a hint. Yes I have read the statement in the FAQ, I have read the lanl.gov website, and i *do* think that this is the sort of pseudo-academic talk that can make every idea seem moldy.
      • The module gets a deprecated status for time t. In that time, it either gets improved by the original author, or a new maintainer is found, or a seamless migration path is built (1:1 API in a competitive module).
      • After that the module is moved to some CPAN-Nimbus. It is not quite deleted, but if you search on CPAN it is not visible by default.

      Bye
       PetaMem
          All Perl:   MT, NLP, NLU

        Difficult to judge wether a module is old and unmainted and therefore should be removed.

        Some people just get panic reading something like "last release 1998" , but it could be well written software which does not need any maintance, updates or whatever. The newest ist best! results quite often in usenet messages like "Is (n)vi abandoned?" which I view as a rather funny message. And, shame on me, I regularly use, as a part of my toolbelt, the unix command "diff" and don't even know wether its regularly updated, maintened or whatever.
Re: The quantity vs. quality lesson [my MANIFESTO]
by gmpassos (Priest) on Jun 02, 2004 at 06:39 UTC
    This is my MANIFESTO:

    First, CPAN is free, made just by the goodwill of hundreds, ops, thousands, of developers in all the world!

    Since CPAN is made by people, that don't need to ask for someone a licence to improve it, since Perl is here to always defend freedom, freedom to do what we want, from the source of our code to our ideas, CPAN will work as a ecosystem, that have good and bad things.

    A developer to create it's 1st module need to start from some point, a point where the probability to build something that is a "crap", as you said, is huge. But since it's free to make this module and improve it, and to show it's "crap" to the world, it can learn how to build better things.

    We also can get the "crap" of other people, take a deep look in that, and find something useful to use with our modules or project, or just to send some upgrades to the author of the "crap".

    But the most important thing is, what is "crap" for one can be gold for other! This is valid for any system, from CPAN to our global ecosystem. So, who can think that is God to tell what is good or bad? No one! Just no one! At least I don't have courage to say that the work of someone, hours or not, is "crap" and need to be banish from the world! Well, history knows some crazy man that thought that was God, and his name was Hitler, and this man really made CRAP, not creating "crap", but trying to say what is crap and banishing what it doesn't like from the world. Today we know that this man was a real CRAP, but in hist time, hundreds, ops, thousands of thousands, of people thought that it was the better and thought that this man knew what it was doing. What was a shame...

    You pointed a important thing, the value of the things in CPAN. Well, we can't control the things that we have in CPAN or we can kill the start point of very good ideas, or maybe kill very good developers. What we really have, is some difficulty to find a good module, or the best module, to do what we want. Well, we are still free to try any module in CPAN, and we have http://cpanratings.perl.org. I can guarantee that is better to test 10 modules and can choose what is best for what I need, that have only 1 module, that some "coporation" says that is the best made by the better, and have only one solution projected for only one problem.

    Actually the first man to point that was Darwing. Darwing showed to us that nature, in million of years, chose a very good strategy called diversity. Diversity will guarantee that a species have much more ways to vanquish a challenge presented by the nature if this species have more diversity. But this is valid for all the levels, from a species to all the ecosystem. This is how every life in this world was build, including us.

    So, I prefer to think that maybe CPAN depends of diversity to exists as a system that can resolve almost all the problems that the world shows. ;-P

    And think that someone have all the wisdom needed to can analyze what can be banished or not from the world just because it's not good enough is just very stupid, since let the evolution work is much more smart.

    And don't forget, if you don't like a module that you "buy" from CPAN, ask for your money back! Stop to think that you win something as the judge of CPAN modules, and star to test them before choose what you will use! Than vote for it on cpanrating to show to the others that it's good. Or help that main author to improve his module. If you don't like this ideas, just let me remember you that this is how the Perl community was made, including CPAN. And if some day someone start to kill modules from CPAN just because they think that it's not good enough I will be the 1st to create FCPAN, Free Comprehensive Perl Archive Network!!!! CPAN is much more big than you think, much more big that any of us! It has 3650 authors and 6443 modules! Have you tried all this module to can say the amount of crap on it?! You are just saing things before really know about what you are talking.

    I prefer to have 900 good modules in 10000 modules (9% of quality), that have only 90 module in 100 (90% of quality), since more modules don't create problems for the other modules or authors! Diversity is the key!!!!

    Graciliano M. P.
    "Creativity is the expression of the liberty".

      So, who can think that is God to tell what is good or bad? No one! Just no one!

      This is pathetic. Sorry. There are objective measures to software quality. I plea for "The internet is free" If you want to upload your (please denote here "your" as purely syntactic) sw-crap, you can push it on your website.

      You should not be able to piss in the church.

      Darwin(g)... diversity...

      The main thing, that Darwin pointed out, was "survival of the fittest". You cannot as of now compare CPAN to a true ecosystem, because this cleaning of the dead corpses is what's missing on CPAN. It starts to stink because of the many corpses lying out there, fouling, with no worms, bacteriae, janitors cleaning them up.

      And that's not about ONE to decide, but MANY. And be it only the set of contributors to CPAN. Democracy.

      And don't forget, if you don't like a module that you "buy" from CPAN, ask for your money back!

      A well known but wrong argument. It is not about money, it is not about modules being free, it is about the sum of wrong modules polluting the space where also good reside. And if I am allowed to be for a second undiplomatically honest: This argument is the biggest bullshit, and I've heard it in the OSS sector so many times! If an author starts to excuse the poor quality of his software with the fact that it is free - well - then IMHO he is doing SW *just* for his own fun and that's ok, as long as he doesn't bother anyone else with it.

      Thats my manifesto.

      Bye
       PetaMem
          All Perl:   MT, NLP, NLU

        *sigh* you consistently keep missing the point. To change the spirit of CPAN is for CPAN to stop being CPAN. The creators of CPAN simply won't let that happen. Stop yelling at the congregation and pissing on the bible.
      I prefer to have 900 good modules in 10000 modules (9% of quality), that have only 90 module in 100 (90% of quality)
      Who is to say this is the bar? This is a weak argument. The problem with CPAN is it lies in anarchy as compared to other languages "core", and often it is hackish or bug-ridden or incomplete, or documentation is woefully inaccurate or missing. And this is somehow ok. Well, yes, CPAN is a public happy place... but there is this phenomenon of the "tragedy of the commons", and CPAN is thus full of proverbial space junk. Can we fix it? Yes. Should we? Perhaps not... but we need to raise the bar and move to a more Debian-like system of maintainers -- and a system where orphaned packages can be adopted if the owner is gone. We should also work on solid frameworks to limit the "TIMTOWTDI" phenomenon. More than one way is fine, but I don't want incompatibile ways ... i.e. this module has an OO interface, this one doesn't, this one uses this module ... it just results in code looking sloppy. Perl is a very powerful language, but I wish the community had higher standards. I'm not embarassed for asking for it, and this isn't a knock at Perl.
        Maybe is time to do this on Perl6! How about a CPAN for Perl6? Actually need to be for Parrot, since Parrot is much more that only Perl6.

        Graciliano M. P.
        "Creativity is the expression of the liberty".

How to make CPAN a better place
by Hanamaki (Chaplain) on Jun 02, 2004 at 08:32 UTC
    No question, CPAN has a lot of jewels, good stuff and crap in it. So, IMHO, a disscusion about how to make CPAN a better place is not wasted time and hopefully this discussion will motivate a view fellow monks to spend some time to actually get something done in that matter.

    The best thing you can do, is to talk to the author if something smells rotten. And I can promise you, most authors won't kill you, but will hapilly listen to your advice. Before I got replaced by a computer (1) , I was probably one of the most active CPAN testers of the "Next Generation" (2) . During that time I exchanged mails with a few hundred CPAN authors including topics like bugs, documentation bugs, makefile problems, etc. pp.
    People viewed by many as the gods , authors who have a reputation to be a little difficult in the perl community , newbee authors, etc., usually are quit happy to get well thought bug reports or critics on their module. With some authors I spent much over a week until they got there module right, some authors corrected the problems within one hour and I can only remember one single author who repeatedly ignored my and others advice, but only changed something if the critic was made public.

    For a while I made CPAN a better place and have the experience to make some general remarks about authors and there attitude to react friendly. So go ahead and talk to the authors. If that does not help, there are other possibilities; all discussed in this thread.

    (1) Don't take that to serious.
    (2) Viewing Paul Schinder as the leading tester of the "first Generation", who is probably still unbeaten in quantity and quality and Randy Kobes as one of the most active testers besides me, while I was doing it.
Re: The quantity vs. quality lesson
by Solo (Deacon) on Jun 02, 2004 at 17:39 UTC
    In Real Analysis, I was taught at least 5 ways to test whether a series converged or not. They were complicated and you had to know when to apply which method.

    Two years later I was taught how to test convergence using Complex Analysis. There was one method for every case. It was pure, simple and beautiful.

    I asked (well, demanded to know really) why I wasn't just taught this method from the beginning?!

    The answers were:

    • clearly you need the practice anyway
    • how the tests were developed in response to each new problem is important
    • you don't truly appreciate the C::A convergence test until you've used the others extensively
    • you could have developed this method yourself two years ago--why'd you wait for us to show you?

    The moral of this story is left as an exercise for the reader.

    --Solo

    --

    You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.

      Very valid point - although a bit prosaic (but that's good).

      The question is then: Is CPAN school? Or is it a programmers ressource?

      Your point makes sense, but only if we accept CPAN as being also tutorial ground. I have to admit, that I have problems with this. You don't find often books of 1st grade students in the university libraries. That is - books that were written by them.

      Bye
       PetaMem
          All Perl:   MT, NLP, NLU

        "You don't find often books of 1st grade students in the university libraries"

        Awesome point. Very concise. You should have led with it as it would make your argument for "levels of CPAN" more clear. Perhaps (though I have alluded to it), we should have varying levels of approval, such as in the Debian system, where private packages can be seperated from the "uber packages", making it easier to tell what you are downloading. That sort of direction is *definitely* an improvement and is doable, much easier than just begging for quality.

        I am disappointed your requests for quality are falling on deaf ears and we're hearing "but I should be allowed to upload my buggy code and bad designs!". I think, once, CPAN served a place like that. But this is horrific on the users, and that time has gone. If we want to establish a CPAN experimental, unstable, testing, and stable, that's fine, and I will gladly set my configuration files to not search through it!

        Anyhow, if Perl is to grow up, it needs to take on a better goal of quality, not quantity. Quantity is for first graders, and I want rock-solid code, because I write rock-solid code. Modules that are halfway-implemented source filters or broken implementations do not intest me, and we need a way to seperate the wheat from the chaff. Not to grade the wheat and the chaff, mind you, but to organize it.

        Something also needs to be done about namespace sprawl to confine modules to more logical places.

        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:

        • How many good books didn't get onto the university library bookshelves because the cost of publishing them was too high, or because the authors didn't know the right sort of people.
        • How many bad/average books had vastly improved second, third, fourth, etc. editions because they managed to get published and had useful feedback and reviews.
        • How many good books are inspired by bad/average books
        • The books on the university libraries shelves are a small subset of the total number of books published in the world. Yet the librarians managed to select the 'good' from the 'bad' without preventing the 'bad' books being published.

        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://357967]
Approved by davido
Front-paged by adrianh
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (4)
As of 2014-11-01 09:51 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (229 votes), past polls