deprecated has asked for the wisdom of the Perl Monks concerning the following question:

Hi, all. I am sort of new to the site, but not necessarily to perl, so please bear with me.

I have been working on the MP3::Napster module pretty extensively. I have added a couple hundred new lines of code to encompass a lot of the opennap server's functionality (which is missing in the Napster Inc. servers).

I have also changed the variable names around to reflect what they are actually called in the opennap source. It is my feeling that this is necessary because most users of the MP3::Napster module will also be at least marginally aware of the opennap server, and perhaps even the source therein. It is also much easier to keep track of it this way since I do a lot of work inside the server, and also in perl programming the client end of things.

I have created several (what I assume to be) useful scripts which help in maintaining the server, as well as a script which (while useful to me) would, I assume, be rather dangerous to release publicly (its a load tester which could be abused for a DOS-type attack).

I mailed the author quite a while ago about the module, and he never got back to me. I think the additions to the module are very useful, and indeed necessary, and I would like to submit it to CPAN or freshmeat. My experience with the module is pretty bug-free, but I cant be sure of that until I get other users to test it out. And herein lie the questions of ethics and utility. First, is this useful to anyone. In order to use MP3::Napster, you must have perl-threads installed, which is above and beyond the normal perl user (or opennap administrator)'s daily experience. Secondly, if the user _does_ have perl-threads installed, it is certainly possible that they are able to do all this programming on their own, and it isnt necessary for me to release this at all.

My feelings on the subject are that the module and associated scripts are necessary. There are enough opennap server owners out there (a quick look at http://www.napigator.com/list.php should reveal that), and the server software itself is buggy enough to merit external administration by a, er, smarter program. Which then leads me to two questions I guess. Just how far do I go with releasing it? The server software is not able to cope with perl's speed with regards to load testing, so if I release the software, should I add modest checks to the module to prevent the casual user from actually doing this (and indeed would a casual user be even using this software given the pretext of having to install perl-threads)? Secondly, I guess, is whether I redistribute this module or create a submodule? A submodule seems like a silly way to go about things since it is really just an update for the main module. Is there a sort of committee on modules or something I should be aware of?

I am new to the perl community, but I have actually been writing perl applications for quite some time. Is there somewhere I should go to find answers to questions like this? I am active on dalnet's #perl channel, and I've begun poking around here... Am I missing something?

thanks, all.
deprecated

--
i am not cool enough to have a signature.

Replies are listed 'Best First'.
(ichimunki) re: a question of utility and ethics...
by ichimunki (Priest) on Dec 23, 2000 at 00:10 UTC
    If the author of a Free software package (i.e. Artistic License, BSD or GPL) doesn't respond to correspondence, then you are certainly ethically able to do what you want.

    My primary suggestion is change the name from MP3::(registered trademark of a money-grubbing corporation)to MP3::Opennap and release it under that name.

    Added Later: Based on information supplied by others in this thread, I would definitely encourage patience with the author of the original package. I still think I would attempt to get a new name for the package with added functionality-- whether as a standalone or as a subclass.
      This certainly seems like the best way to go. This means that the MP3::Napster module retains its vanilla features (i.e., not supporting the extended features of opennap), and we all gain access to the 'extra stuff.' Okay, I've got a copy of Conway's book, I guess its time to start reading that sucker a little more closely. Any suggestions on how to get some free beta testing? :)

      dep

      --
      i am not cool enough to have a signature.

Re: a question of utility and ethics...
by KM (Priest) on Dec 23, 2000 at 01:37 UTC
    I am surprised Lincoln didn't respond, he is generally a responsive fellow. I would first suggest emailing him again, and getting his input. Otherwise, I would ask on modules@perl.org what they think about the namespace to use. If much of the MP3::Napster code has been left alone, a good place may be MP3::Napster::Opennap. Personally, I would suggest doing what you can to leave MP3::Napster alone, and simply subclass it with MP3::Napster::Opennap, overriding method names if you need to.

    Cheers,
    KM

      I am surprised Lincoln didn't respond, he is generally a responsive fellow.
      Please remember that Lincoln's entire setup got stolen from his home a few weeks back. His huge MP3 collection is gone, although he was able to restore most of the software for www.modperl.com from offsite backups, thank goodness.

      -- Randal L. Schwartz, Perl hacker

Re: a question of utility and ethics...
by Hrunting (Pilgrim) on Dec 23, 2000 at 01:01 UTC
    I'd suggest one of two options:

    Do as ichimunki suggested and release the code as a separate module. The suggestion of MP3::OpenNap was a good one. This gives the end user the choice of which module to use.

    Release a patch.

    Whatever you do, don't release that submodule if what you're really doing is rewriting large portions of the internals. Submodules (IMHO) should only use the standard documented interface of the module, inless you're explictly putting the module in ISA, in which case all bets are off (and even then, I'd still recommend using as much of the documented interface as possible).

Re: a question of utility and ethics...
by Albannach (Monsignor) on Dec 23, 2000 at 00:42 UTC
    if the user _does_ have perl-threads installed, it is certainly possible that they are able to do all this programming on their own, and it isnt necessary for me to release this at all.

    This of course is rubbish and I expect you know it *grin*! We'd all have very sore fingers (at least) if it weren't for the contributions of others (kinda plays into the recent "standing on the shoulders of giants" thing).

    This is all meant to say "Go deprecated!".

    --
    I'd like to be able to assign to an luser