Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

How to complain about changes to a module? (And what good would it do?)

by BrowserUk (Pope)
on Aug 28, 2008 at 11:56 UTC ( #707455=perlquestion: print w/replies, xml ) Need Help??

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

If the new maintainer of a well-established, reliable, bug-free module, makes changes that are

  1. unnecessary;
  2. go against both its design philospophy and purpose;
  3. introduce dependancies upon other modules that same author has already ruined.
  • What can be done about it?
  • To whom does one complain?
  • And would it do any good?
  • What other options are open to curtail or rollback such changes.

Note: I don't want to discuss the specifics of any particular module here, I'm just wondering what options are open to me.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
  • Comment on How to complain about changes to a module? (And what good would it do?)

Replies are listed 'Best First'.
Re: How to complain about changes to a module? (And what good would it do?)
by moritz (Cardinal) on Aug 28, 2008 at 12:17 UTC

    I assume that you already asked the author politely to revert his changes. If not, that's the first step (and maybe the only), and you don't need to read on.

    unnecessary;

    Your chances are not good at this one: if the author thought the cange was unnecessary, he wouldn't have done it.

    go against both its design philospophy and purpose;

    That's something you can try to come up with; if you do it politely and well reasoned, maybe you can convince the author. Politely implies...

    introduce dependancies upon other modules that same author has already ruined.

    ... not mentioning that you think the author ruined anything. Even it might be the case, you won't make any friends by saying it.

    If the author introduced another dependency, you can be fairly sure that he didn't think it was unnecessary, so most certainly you lost on your first point already.

    What can be done about it?

    Either cope with your frustration and don't do anything about it, or fork the module.

    To whom does one complain?

    To good friends in real life, or your significant other, if you happen to have one. Don't complain to the module author, it will make things worse.

    And would it do any good?

    No. Technical discussions might be helpful, but complaints are most certainly not. It only helps you to deal with your frustration, thus if you complain to anybody, make sure it's somebody who doesn't have any influence on the situation, and just listens.

    What other options are open to curtail or rollback such changes.

    Fork the module. Or keep using a patched version. Or take over the module, if the author agrees.


    I can very much understand your situation. We geeks tend to have strong opinions on technical matters, and the more we are familiar with them, the stronger they are. As a user of a good piece of software it hurts to see it being crippled, and as an author you feel pretty sure that you're improving it. Unfortunately there's no silver bullet solution.

Re: How to complain about changes to a module? (And what good would it do?)
by Corion (Pope) on Aug 28, 2008 at 12:05 UTC

    There once were complaints about how base.pm had accrued bloat and feature creep, and the only way that was seen by p5p was to let it rot as the dead carcass it is and to elect a slimmer, fitter substitute into the core. The better solution would've been to cut away the cancer but neither the author nor p5p followed through on that.

    So my view on such situations isn't all positive, even though I got a talk out of it and a module into the core that way. Possibly, if you were to name names, it could frustrate the unnamed frameworking author so that you get assigned maintainership. This would be the most positive alternative I see. Actually, while we're dreaming crack pipe dreams, maybe you can enter a fruitful discussion with the author (note: avoid terms like "ruined", "unnecessary") and either you realize that the author was right all the time or the author realizes that his extensions should go into a subclass.

    So, I see little gain in complaining. You can always fork the module in question.

      and either you realize that the author was right all the time or the author realizes that his extensions should go into a subclass.

      I suspect that you are aware of more than is in the OP. You've hit the nail exactly on the head with your "should be a subclass" comment.

      So, I see little gain in complaining. You can always fork the module in question.

      The purpose of a complaint (as opposed to moaning) is to try and change things. But it's kind of hard being as the maintainer has cut himself off from the (this) community.

      At the basic level, forking the module in question is trivial, the original is a 30 line pure perl module. The problems start with choosing a new namespace.

      At the deeper level, to do the job right would require forking a couple of other distinctly non-trivial, XS modules with huge platform dependancies which I would have no way of testing never mind supporting. Also, I find getting XS code correct to be closely akin to black magic. A set of barely documented incantations that when they work, you're never quite sure why they do, and when they don't they are all but impossible to debug. Trying to corrolate disassembled assembler or C back to XS is nigh impossible. And getting help even harder.

      If you can find an existing module that does something similar, and stick to existing patterns of code, you can sometime get stuff to work. But if you look at the time it took for the experts to work out all the bugs and caveats in List::Util::reduce() you can see that it's not just me that has the problems.

      Thanks to everyone who gave this serious consideration and posted. I now know what I've got to do, I just need to work out whether I am up to the challenge.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

        You overestimate my global awareness, but if a subclass, either by you or the author is possible, that sounds like a good way. I had a remotely similar situation with Schedule::Cron::Nofork, where I replaced some functionality with mine, but I think I didn't ever contact the author about changing Schedule::Cron. Eventually, S:C acquired the functionality itself and I should retire my module some day.

Re: How to complain about changes to a module? (And what good would it do?)
by jettero (Monsignor) on Aug 28, 2008 at 12:05 UTC

    What I usually do with modules I'm afraid will change over time and ruin my projects without notice: Copy them into my project tree and rename them accordingly. Then I can also patch in features I need and forget about it. Of course, I won't get any future updates, but that's what I wanted anyway, isn't it?

    -Paul

Re: How to complain about changes to a module? (And what good would it do?)
by derby (Abbot) on Aug 28, 2008 at 13:52 UTC

    If direct communication with the maintainer is providing no relief then I would do exactly what others have suggested (private copy) for the short term *but* I would also use the semi-official channels of rt.cpan.org, cpanratings.perl.org, and www.annocpan.org to document the problems. Personally, I've gone the rt.cpan.org route in the past ... it can get ugly but if it gets too ugly, you can always fork (ala Class::DBI and DBIx::Class).

    -derby
Re: How to complain about changes to a module? (And what good would it do?)
by scorpio17 (Canon) on Aug 28, 2008 at 14:14 UTC
    I vote for "fork the module" - give it a very similar name, so anyone searching for it on CPAN will see both. Make sure that the synopsis explains the differences, so users can make an informed choice. Then, may the best module win! If one is actually broken it will slowly fade away into obscurity, since no one will use it.
Re: How to complain about changes to a module? (And what good would it do?)
by FunkyMonk (Chancellor) on Aug 28, 2008 at 15:50 UTC
    What about other users of the package? How do they feel about the changes that have been made? Is there a mailing list, or an active CPAN forum for the package? Blogs? Even the CPAN ratings can be used to exress your concerns.

    Surely if the changes are as poor as you say, somebody somewhere will be talking about them. If they're not, then perhaps the changes aren't as severe as you thought.

Re: How to complain about changes to a module? (And what good would it do?)
by JavaFan (Canon) on Aug 28, 2008 at 13:29 UTC
    It may be obvious, but the easiest thing to do is to just use the version of the module you were happy with. There's never a requirement to use the latest version.
      Makes sense to me to use the latest version. The stuff should work. If not, call it something else. A module's api is important.

      You know.. sometimes the old modules are discontinued too. cpan itself suggests to get rid of old stuff. So, if I have Pudding v 0.1, and I'm up to Pudding v4.0, maybe I can remove some of the old 20 pudding distros or so previously released fromthe archive. That seems like the progressive thing to do. I think the poster makes a ton of sense - a version bump up should NOT break stuff- appear like a decay.. etc.

      As an author, this stuff can be hard to detect- what of what I am doing is really an improvement to other coders- what's making it worse. With module releases it can be hard to track because we don't by default have download counts etc.

      I think the best policy is to give feedback! If it's not working.. come over to perlmonks, and get a group of people to maintain a decent distro of something that's useful.

      I think sh1++y maintenance is grounds for a rewrite.

      Isn't that the whole point of gnu? Get an old version, and re-release it? Rename it, recognize the original authors, give credit, and you take over. You're not saying it's yours- you're just adding something that the previous author did not or will not add. In this case, it could be that they're breaking the thing's soul.

      Shouldn't come to that, though. Ideally you can offer a helping hand and or suggestions.

Re: How to complain about changes to a module? (And what good would it do?)
by talexb (Canon) on Aug 28, 2008 at 18:10 UTC
      What can be done about it?

    Politically - that's a tough call. Reason with the new maintainer? Bug the people who proposed or seconded the new maintainer?

    Technically - as has been suggested, start your own branch from a known good version.

      To whom does one complain?

    No one - Open Source is both blessed and cursed with Technical Anarchy. People are free to take the ball and run with it, based on their opinions and technical ability.

    The best revenge is to fork the offending modules and champion their use. Natural selection will determine how successful each outcome is.

      And would it do any good?

    Sure - complaining is always better than saying nothing. But it's what happens after the complaining that's probably more important.

      What other options are open to curtail or rollback such changes.

    Like I said, there's a sense of anarchy when it comes to this area of software development. If the new maintainer's a lunatic, from your point of view, the answer is simple - fork the good code and move on from there.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Re: How to complain about changes to a module? (And what good would it do?)
by tilly (Archbishop) on Aug 28, 2008 at 23:16 UTC
    Another option is to complain to the old maintainer. The new maintainer may be more likely to listen to the old maintainer than a random user.

    Also if the changes are egregious, then discussing specifics in public, ideally on a module-specific mailing list, but you could do ithere or on use.perl.org, may make more people aware of the issues around this new maintainer. That may help convince someone else to undertake the fork of the module that you don't want to handle, and it may make others aware that this isn't a good person to hand over modules to.

    Of course that option comes with the significant cost that you'll be reasonably likely to create some bad blood. I've always had the attitude that I'm willing to risk create bad blood if I think the cause is important enough. (That said I set the bar fairly high, and work to avoid accidentally creating bad blood.) However lots of people disagree with me on that.

Re: How to complain about changes to a module? (And what good would it do?)
by leocharre (Priest) on Aug 28, 2008 at 16:06 UTC

    I have some stuff on cpan. Sometimes I get random hackers contact me about details, implementation, requests for documentation and features, etc.

    That said, whenever I get any suggestions, crits.. I scramble to make the changes or allow the possibility of a change. My turnaround is between a day, and two weeks if it's something particularly tedious.

    Maybe I'm just still a noob and my modules are weird and not too many people use them. Maybe more accomplished authors are more jaded or have less time in their hands.

    I for one would like to hear more of what should be different or what's messed up. Maybe other authors would like that as well.

Re: How to complain about changes to a module? (And what good would it do?)
by hsmyers (Canon) on Aug 28, 2008 at 16:13 UTC

    As others have said, fork the module at a point free of the problems you mention. Then closely examine the current version for anything you can high grade(mining expression for take the good stuff). If you find something worth while, incorporate it into the fork. Document everything and then place in back on CPAN. Given the number of seemingly cloned offerings, I would guess this has happened before.

    As a fairly weak plan B, contact the original author and see what remedy might follow if any.

    --hsm

    "Never try to teach a pig to sing...it wastes your time and it annoys the pig."
Re: How to complain about changes to a module? (And what good would it do?)
by Anonymous Monk on Aug 29, 2008 at 06:28 UTC
    Do a fork, for example CGI.pm version 2.61 is last version you like, so you fork and rename to CGI261.pm
Re: How to complain about changes to a module? (And what good would it do?)
by Anonymous Monk on Aug 28, 2008 at 13:26 UTC
    Answer to question #2: complain to perlmonks for getting some warm and fuzzy feeling of righteousness, and of course for a bit of xp whoring.

      If you’re talking about the OP, nothing could be further from the truth regarding XP, I doubt he has any idea within several thousand how many XP he has, and when you’re that far ahead of everyone else it XP becomes meaningless anyway.

      Anonymous Monk if you are going to continually make disparaging remarks like that at least have the balls to put your moniker on it.

        Another Anonymous Monk here. The question was To whom does one complain? Complaining to perlmonks and earning some XP sounds like a great suggestion. Gavin reads between the lines too much :)
        Another anonymous monk here. I also doubt that the OP engages in gathering XP, however during the last several years I couldn't help noticing that indeed there was rarely a day without the respected OP writing a post, most often a redundant one than not. There is nothing bad in using the site as a social club I guess, but it's no surprise that someone new could easily take that for XP whoring.

      I'm not surprised that you chose to be anonymous when you take cheap shots like this. Jealousy is so unbecoming.

        I personally believe that (anonymous!) xp whoring allegations are becoming PM's own form of Godwin's law...

        --
        If you can't understand the incipit, then please check the IPB Campaign.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (4)
As of 2020-01-20 13:59 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?