Adopting Modules

[jk2addict]

I've decided to adopt a couple of modules from Simon Cozens; specifically Apache::AxKit::Language::XSP::ObjectTaglib and AxKit::XSP::Minisession. I've got a PAUSE id and as far as I know all necessary upload permissions have been changed, but I've never done anything with it. I also own and have been through Writing Perl Modules for Cpan a few times in the past.

What I'm looking for is advice, guidance and any other info on what the commen/excepted/expected practices are for when taking over someone elses module. I would think at the very least I should update it and push up a new version with my contact information in place. Obviously credit needs to be maintained with respect to the original author. What should be changed? What should be left alone?

I'm just trying to avoid incoming flames due to mistakes made in ignorance and not in malice. :-)

Updated: For example, I'd like to get rid of this stuff but I don't want to step on previous toes. Hell, for that matter, I'd like to completely convert it all to ExtUtils::ModuleMaker, it's directory structure, and write some tests. I guess my real question is where do I need to make sure to list the previous author? I'd assume the POD and the Makefile.PL.

Maybe I'm thinking too literally. Afterall, the previous versions will still be available in his author directory.

Update 2: Why in the heck did I put this in meditation?

[stvn]

Maybe I'm thinking too literally. Afterall, the previous versions will still be available in his author directory.

Exactly! That is the beauty of CPAN and even more so of back-PAN. This stuff never goes away. It is your module now, if Simon still wanted to control it's destiny, he would not have given it up :)

AxKit::XSP::Minisession is over 2 years old, as is Apache::AxKit::Language::XSP::ObjectTaglib (which only seems to have been uploaded once). Surely they could use some really basic updating to start with. For instance converting the test.pl file in Apache::AxKit::Language::XSP::ObjectTaglib to be a proper t/ file which uses Test::More. AxKit::XSP::Minisession does not even have tests, so adding even just a smoke test to check the module compiles would be a step in the right direction. And of course this is also an opportune time to add your contact info and small paragraph stating that you are now maintaining this module. You can even put a TO DO list or FUTURE PLANS section to let possible users of the module know what you are thinking.

Personally, I see no problem with "the release early and release often" approach when using CPAN.

As for the stepping on toes thing, don't worry about it. Anyone who flames you for adopting, maintaining and updating a CPAN module is clearly an a**hole and should be ignored as such.

[jZed]

If a complete overhaul of the module will take a while, you should probably release a new version with your contact info now even if you have only minor changes to make to the module. You'll also want to make sure that the rt.cpan.org rights to the module get transferred to you so that you can examine existing bug reports and begin to recieve new ones.

[jk2addict]

Hmmm. I would think they have already, but I guess I'll find out. I'm not sure what magic modules@ has performed thus far. What's the best way to check that?

[TStanley]

I would include a small section in the pod and in the readme stating that the original code was the idea of the previous maintainer, but that you are the new maintainer, and that any questions/bug fixes should be directed to you.
And I do agree with your notion of giving it an overhaul and putting it out with your contact info.

[dragonchild]

I'd take a look at XML::Parser and how it does the documentation. It's gone through at least three authors, if not more.

When I took over PDF::Template, the changeset was nearly 99.9% of the code and the author didn't have time. Now, once you've taken over maintainership, you're the boss. Sure, you definitely have to look at backwards compatibility, but that's true if you originally wrote it or not.

Writing more tests, adding new build methods, reorganizing the directory ... as long as you're not ripping out stuff just because it ain't yours, I'd say go for it! If you're not sure, ask your users.

Oh, yeah - make sure you have a mailing list and that you invite anyone and everyone you can think of to be on it. And, make sure that mailing list is prominently listed in the POD. Mailing lists are an absolute MUST when you've got something opensource. GoogleGroups, Yahoo!Groups ... both are excellent free mailing lists. (Perl6 and Parrot both use GoogleGroups, if that tells you anything.)

[rrwo]

I would think at the very least I should update it and push up a new version with my contact information in place. Obviously credit needs to be maintained with respect to the original author. What should be changed? What should be left alone?

I recently took over Log::Dispatch::Win32EventLog. I added my name and contact info on the top of the AUTHORS list, but also updated the installation style to work with Module::Build, included a META.yml etc.

Of course, I took it over to fix some warnings related to newer versions of Perl and update the test suite. (Which led to finding more subtle bugs....)

I did update the documentation with some things that I thought needed explicit mention, and rather shamelessly added reference to another module I wrote with overlapping functionality to the SEE ALSO section.

What I meant to do but have just realized that I did not do, was to put a link to rt.cpan.org for reporting bugs, rather than to have people send E-mail to me. That's the best way since there's a list of outstanding bug reports and feature requests.

I did not remove references to the other authors, since they put a bit of work into the original. Nor did I update the wording on the license.