in reply to Gathering module usage statistics

I also have been curious in this way about my modules on CPAN. *ponders* I'm thinking that many authors are curious, as would be other users. If I see that modules X and Y might satisfy my needs, but X has 10k installs in the past month and Y has 10 ... I know which I'm going to try out first. Also, it would be useful to also know what versions of Perl and what OS's a module has been installed on. (I know I have this annoying problem where I have access to very few OS's ...)

Maybe, that website should be usage.cpan.org and it should be a part of MakeMaker?

------
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

Replies are listed 'Best First'.
Re: Re: Gathering module usage statistics
by Juerd (Abbot) on May 04, 2004 at 19:11 UTC

    Maybe, that website should be usage.cpan.org and it should be a part of MakeMaker?

    I like that idea very much! It could be used by MakeMaker, Module::Build, etcetera. Maybe even by PPM.

    However, it will take long before people upgrade their current versions.

    Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

      Yeah, well, that's the issue with any rollout to remote locations. :-)

      Now, what we could do in our modules is require the appropriate versions of MakeMaker, etc. That would force the reload the moment our modules are used. Plus, it would happen for all new installs of Perl. So, I s'pose, it would roll out relatively quickly. The numbers would be useful within 3-6 months.

      ------
      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

Re: Re: Gathering module usage statistics
by hossman (Prior) on May 04, 2004 at 20:34 UTC
    Maybe, that website should be usage.cpan.org and it should be a part of MakeMaker?

    The idea of hooking this into MakeMaker, and/or making it automatic on install by any means, scares me for a variety of reasons that will either seem obvious, or paranoid depending on the readers personality.

    In general, this whole thread reminds be of the Debian PopCon package/database. Perhaps someone could whip up a perl/CPAN equivilent that submits data from perl -V and perllocal to a central repository, which people could choose to install on their system if they want to participate.

      In general, this whole thread reminds be of the Debian PopCon package/database. (...) choose to install on their system if they want to participate.

      That works only if your user base in greater than very huge. There have been MILLIONS of Debian installations, while only less than 5000 were counted by PopCon.

      scares me for a variety of reasons that will either seem obvious, or paranoid depending on the readers personality.

      I'd like to know those reasons. What is wrong with letting others know your OS and version of Perl? No paths, personal information or anything non-static will be sent. $^O and $] are compiled into perl (in fact, $^O is not the platform perl *runs* on, but the one it was *compiled* on) and the module's name plus version are not computed, but hardcoded information. What is your objection to sharing this non-personal, non-identifying information, and why isn't opt-out good enough for you?

      Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

        1. The benefit is not in knowing absolute numbers of installation base, it's in knowing the ratio of installations to sample size. if 50% of all participating users have Foo installed, ant 20% of all participating users have Bar installed, you should be able to gain a high level of confidence that Foo is more prevelant "in the wild" then Bar
        2. At no point prior to your message has any one described a way by which this functionality could be hooked into MakeMaker, with an Opt-Out, which would be obvious to people who don't know they should look for it because they just upgraded module Foo without any idea that the new version of Foo is submitting this data.

          furthermore, I'd be impressed to here any such description that sounds more intuitive and easy for users to do then to have an "Opt-In" instead.

        3. In general, I'm a big believer of "Opt-In". I rarely encounter something that's "Opt-Out" which doesn't piss me off by the nature of being "Opt-Out"