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.