The last release of the module was less than a year ago, which is not a great deal of time in the great scheme of things - I have modules which have been four years between releases for instance. That there doesn't appear to be much activity around the module might simply be an indication that it is relatively bug-free and people aren't having many problems using it. In the first instance I would suggest that you drop the author an e-mail reporting your problem (and if you have a patch that fixes your problem even better) and take it from there.

/J\

As far as I know, the author is not actively developing Spreadsheet::ParseExcel (he had stopped everything a while back to write a book on the DBI).

I think that it would be a good idea for someone to take over maintenance of the module. Not least of all to apply some patches for greater Unicode support under Perl 5.8.

--
John.

And relying heavily on an unmaintained module seems rather scary.

modules that are constantly changing are more scary

Not that I don't agree, but let's not generalize. Some modules constantly change and that might be a good thing :-)

what if an interface changes

You can always write a wrapper.

or a bug is introduced

That's what tests are for. If the author doesn't use them, you can write them yourself (and even if the author refuses to include them, you can run them yourself just to make sure everything's OK). And you can also stay a couple of versions behind at all times.

At least with static code, you know exactly what you've got

Presumably... :-)

My point with "constantly changing" modules is that some authors are like kids with ADD...there really isn't a rhyme or a reason to what they're doing at any given time. So, you get v0.02 of a module, find that it does the job "well enough", only to find that when v0.03 comes around, the whole architecture has changed. If the interface is consistent and the behavior is somewhat consistent (modulo new features or bug fixes), then okay. Having to write a wrapper is, in my opinion, a signal that either you got the module at a time when the module was marked alpha, or the maintainer is one of those maintainers who just changes the interface on a whim. The latter are the ones that I take issue with.

thor

Feel the white light, the light within
Be your own disciple, fan the sparks of will
For all of us waiting, your kingdom will come

Is emailing the author, and offering to take over maintenance an option for you? Based also on the perl license, there's nothing stopping you from taking the code, forking it to a new project, and maintaining that (IANAL). Or even, if you don't want to go that far, to fork off an internal-only version that you don't distribute, but I highly discourage that as much as you can ;-)

Emailing the author is usually the way to go, especially when there's no section BUGS or BUG-REPORTING in the docs.

But for general discussion regarding CPAN modules you can also resort to the module-author mailing list.