http://qs1969.pair.com?node_id=57623


in reply to What to do when a module is no longer being maintained

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.

  • Comment on Re: What to do when a module is no longer being maintained

Replies are listed 'Best First'.
Re: Re: What to do when a module is no longer being maintained
by ichimunki (Priest) on Feb 10, 2001 at 18:30 UTC
    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.
[reply]
      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.

[reply]
        I think that ichimunki nailed it. A good introduction to customs when deciding to maintain an open source project may be found here. The case of Red Hat versus Mandrake is very different since they are competing businesses. Normally there is quite a bit of value in not trying to get into squabbles about who is supposed to be maintaining what.
[reply]
Re: Re: What to do when a module is no longer being maintained
by knight (Friar) on Feb 11, 2001 at 00:34 UTC
    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 IPchains.pm 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 IPChains.pm 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.
[reply]
      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.

[reply]

In Section Seekers of Perl Wisdom