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


This is going to be long, so i apologize in advance for anyone who's bored by this. If you just want the question, skip to the end.


I work at a company that does 80% of it's coding in perl. I feel blessed because i know a lot of people who would kill for a programming job not involving VB or java. So the point of this is the fact that we're encouraged to do everything in perl if it's feasable. We are also encouraged to use CPAN whenever possible, since time is money, and with the way the economy is right now, no startup can afford to pay people to reinvent the wheel. My copmany makes transparent / explicit proxying software. The technology is super cool. When we do transparent proxying , we usually use a layer 4 switch to route all traffic destined to port 80 to our proxy, which handles everything from there. Our proxy usually listens on a different port than 80 though, so somehow the traffic must be forwared from one port to another. Originally (before I got there), this was done with squid. But squid is slow and big and ugly. So i proposed the use of ipchains instead (all of our machines run linux). I set up a proof of concept box to show that ipchains could handle 10x more connections than squid while using 1/10th of the system resources that squid would have. This is a good thing. Then it fell upon me to automate this process. Originally i wrote a module to grab configuration info from a config file, and construct the appropriate command line stuff for ipchains. Most importantly, I had this rule:
/sbin/ipchains -A input -s -d 80:80 -p6 -j REDIREC +T 3000
which redirects all traffic destined to port 80 to port 3000 instead. This made transparent proxying work. Unfortunately , the code to do this was pretty dirty. I searched CPAN and found, which gave OO methods to accomplish the same thing, and used SWIG to directly make the C calls, rather than running a shell. This was definitely cooler, so I started rewriting my module to use this interface instead.


Then i found a problem. The module didn't allow you to specify a port to redirect to if 'REDIRECT' was your action. This made redirection pointless, and prevented me from accomplishing what the above ipchains command did. So (like any good hacker), I went through the code, wrote an option in for what I wanted, and made it work (which could have never happened if i didn't have access to source code). Which brings me to my question.


I generated a patch for the module, and sent it off to the author. It's been a week, and I haven't heard anything back. The last time this code was updated was September 1999, which makes me think the author has no intentions of releasing a new version anytime soon. The code is GPL'd, so I could just release my own version with the patch, but somehow I feel like i'm going behind the author's back by doing so. So I guess what I'm asking is what do you do when you have bug fixes for code that's not being maintained anymore?


Disclaimer: This post may contain inaccurate information, be habit forming, cause atomic warfare between peaceful countries, speed up male pattern baldness, interfere with your cable reception, exile you from certain third world countries, ruin your marriage, and generally spoil your day. No batteries included, no strings attached, your mileage may vary.

Replies are listed 'Best First'.
Re: What to do when a module is no longer being maintained
by knight (Friar) on Feb 10, 2001 at 05:31 UTC
    Don't give up just yet trying to contact the author. Ping the author again via email. Search other modules the author wrote to see if there's a more current email address. Try a web search for the author as well. Give yourself maybe another week after your best efforts at tracking down him/her.

    If you still haven't heard anything by then, send mail to, or post to comp.lang.perl.modules, asking whether anyone is still claiming to maintain the module in question. If no one in those forums can vouch for someone currently owning and maintaining the module (after another reasonable wait, another week or two), then you can probably feel free to take over and upload a new version to CPAN yourself.

    If you do, don't take this ownership lightly. If you're really going to take over, be prepared to field questions, fix bugs, etc., in the future. If you're not interested in doing that, but really just want to make your one fix available, then at least document the fact that the ownership is up for grabs, so the next person in your situation isn't left wondering like you are now...

    (Eric Raymond covered this property/ownership aspect of open source software in his Homesteading the Noosphere, essay, which will be part of his eventual The Cathedral and the Bazaar book.)
Re: What to do when a module is no longer being maintained
by runrig (Abbot) on Feb 10, 2001 at 05:07 UTC
    I wouldn't assume anything after a week. Maybe she's on vacation, maybe the email got lost, maybe ... ?? I'd only take over a module if the author asked me to, and I wanted to (or after waiting a while longer). IMHO, send another email, and wait a little longer.

    You can also try sending email to, it may or may not go to a different place than her listed address. She has a website ( which appears to recently maintained, but not of much help right now.

Re: What to do when a module is no longer being maintained
by IndyZ (Friar) on Feb 10, 2001 at 05:32 UTC
    If the module does turn out to be dead, you might want to consider taking it over. Does anybody know how CPAN would first establish that a module is unmaintained, then turn it over to a new maintainer?


      The only thing stopping you from uploading a patched version of a module (last time I checked) is courtesy. That is, if you tried to upload a patched version of a module that is normally maintained by someone else, I don't think any automated system would prevent or even detect it. You'd have to get a PAUSE ID first, of course.

              - tye (but CPAN calls me "TYEMQ")
Re: What to do when a module is no longer being maintained
by extremely (Priest) on Feb 10, 2001 at 10:55 UTC
    Isn't IPChains being knocked back by Linux 2.4 and IPTables? Maybe you can just make an IPTables module and have it import what you don't want to rewrite from IPChains... (Oops, almost off topic... um um 'use strict' yeah... =)

    $you = new YOU;
    honk() if $you->love(perl)

      Um, yeah. But that's not the point. No one i know is moving to the 2.4 series for production use yet, and Netfilter supports ipchains rulesets as well (just like ipchains supported ipfwadm commands and rulesets).


      Disclaimer: This post may contain inaccurate information, be habit forming, cause atomic warfare between peaceful countries, speed up male pattern baldness, interfere with your cable reception, exile you from certain third world countries, ruin your marriage, and generally spoil your day. No batteries included, no strings attached, your mileage may vary.
Re: What to do when a module is no longer being maintained
by sierrathedog04 (Hermit) on Feb 10, 2001 at 17:42 UTC
    By attempting to contact the author you have already extended the courtesy that you are supposed to extend. Do you think that Mandrake asks for Red Hat's permission before extending the Red Hat Linux distribution's source code?

    Indeed, people are always coming out with unusual Linuxes for PDAs, computers without hard disks, etc. The developers don't ask for Linus's permission, nor should they. That's why it is called open source. Open means anyone can use it. Use includes distribution. You especially don't need permission if permission is not available.

    I would upload the new module to CPAN and stop looking for the original author. However, I would make certain that my new module profusely credited the original author.

    Even if you post an updated module and then don't maintain it, users are no worse off than they are with the current module, which is also not maintained.

      Hoping not to start a semantic debate, but the phrase "open source" does not mean anything other than "viewable source code" when taken at face value.

      When dealing with Free software, it is good to remember that the freedom to fork or replace something doesn't always make it a good idea to do so.

      In this case, the author may not wish to maintain the original module, or he/she may simply need some time to digest the patch, recover from illness, etc. Unless the code is from Damian Conway, most module authors are not paid to be full time Perl gurus and get to things when they can.

      In the meantime, BlueLines has a working patch that adds his feature. Which proves that Free software is working. And obviously if his/her company is going to distribute a package of software they will use this if they cannot get an improved 'official' patch in time.

      I would hope for the sake of users everywhere and the Free software community as a whole that Mandrake and Red Hat communicate as often as possible about changes and extensions. Technically they are not in the business of selling software widgets, so it seems wasteful to reproduce the same extensions at both companies. However, if they check with one another, and Red Hat says they don't plan to do XYZ, then of course Mandrake will go ahead and do XYZ, and hopefully someone at Red Hat will pay a marginal amount of attention to the progress of XYZ.

      In the case of things like Linux kernels, obviously Linus or Alan Cox are not going to spend their time moving the kernel to some new platform, but groups working on extensions routinely submit patches back to the maintainers as often as possible.

      While most Free software is the brainchild of one developer or a small group of developers, each project usually has a large team of peripherally interested parties as well. Doing things like communicating, having patience, asking permission are all parts of good teamwork.
        At least initially there was no cooperation between Red Hat and MandrakeSoft at all. A founder of MandrakeSoft says in an Inside Magazine article that:
        "It was 1998, and KDE had just come out. He Gael Duval wanted to take Red Hat the Linux distribution, remove the crappy interface, install KDE in its place and make the user links a bit easier."
        Red Hat for its part appears not to object after the fact to what Mandrake has done. Indeed, they should not object. I started using Mandrake 7.2 because it was the only Linux that would recognize my video card. I got so hooked on Linux/Perl that I installed Red Hat 5.1 on a second, smaller laptop that did not have enough memory for Mandrake 7.2.

        So now —thanks to Mandrake having copied Red Hat— I am using Red Hat more than I would have otherwise. If BlueLines goes ahead and releases an upgrade to the original Perl module he upgraded then his release will stimulate interest in the original module. Maybe it will even motivate the original developer to start working on it again.

        There is no need to delay releasing the upgrade for months while engaging in a search for the original author.

      Even if you post an updated module and then don't maintain it, users are no worse off...

      The courtesy you're extending in doing a thorough check is not only to the original author, but to the user community in not creating multiple, potentially conflicting versions of the source code base unnecessarily. If BlueLines put out a new version of and the original author followed a week later with another that contains a different fix or API change, the well-intentioned fixed version has caused confusion in the user community.

      This is different from your example of multiple Linux distributions, which are (mostly) different groupings and packagings of established code bases. One of the reasons Linux is successful is because there aren't multiple forks of the kernel source code. And those that variants do exist (for example, Alan Cox' networking code) are clearly labeled, and aren't versioned as another release of Linus' kernel.

      So if it's important to make a change available quickly, and you want to push the analogy with Linux distributions, it would be safer if BlueLines put out a distinct "BlueLines" distribution of in the interim. That would keep the distinction clear (in the same way that Red Hat is Red Hat and Mandrake is Mandrake) while verifying that the original author has, in fact, abandoned it the module. And the variant can be abandoned whenever it's folded into the "official" version of the module, either because BlueLines takes over or because the original author pops up and picks up the fix.

      The underlying point remains, though: lack of a reply from the original author a week after sending a message to a possibly out-of-date email address is hardly thorough enough to determine that it's really unmaintained.
        We agree more than we disagree. Yes, the new module must be clearly labeled with a name such as BLIPC ("BlueLine's IP Chain") or something like that. Just as we have separate namespaces in XML and Perl, we need them in module names as well.

        Moreover, BLIPC should clearly state what version of the original IP Chain it forked off of. But if BlueLine does the above then I really don't know what he is waiting for. Maybe there is a user today who needs his modified module, and next week will be too late.