Take Dave Cantrell's CPAN Dependency checker for a spin. Give it a couple of big packages like Plagger, Catalyst, Jifty, Mail::SpamAssassin or POE and see what it thinks of them.

Look for the usual suspects (modules that come up repeatedly with lots of failure), and that deal with problem domains you're interested in.

Check out the corresponding CPAN RT queue and see if there are two hundred new bug reports filed. There's a fair chance that the author has gone AWOL. Download the package, fix the bugs, while trying to contact the author in parallel.

After three months is up, and you've fixed all the bugs, and the author hasn't acknowledged your polite queries as to whether they still wish to maintain the module, or want a co-maint, or whatever, you should then drop a line to module-authors@perl.org detailing your attempts to fix the module and track down the author.

Depending on a number of factors, you might just wind up as the proud maintainer of any number of crucial CPAN modules. And I would buy you a beer if we ever meet up at a YAPC.

It's hard to recommend something without knowing more about your preferences

And finally: would you like to be the only maintainer of module, or would you prefer teamwork?

I'd not mentioned a specific topic because I find it hard to answer. To be honest I can be interested, or not, in all the topics you suggested.

I'm not trying to be difficult (honestly!) I just find that some things catch my imagination regardless of the broader topic that they fall under. That was why I'd been looking for a list of options (either of new ideas or unmaintained options) until I had an 'Aha!' moment.

As far as working with a team or not, I'd be happy with either, in fact as I'm looking at this as much for learning as anything else a team may be helpful, then again I am also used to learning by myself. So, yeah, either :)

I'll try to present a module I'm working on in my free time, and if you (or another monk) are interested in it, I'll set up a repository where you can get the code.

My inspiration comes from a simulation software called stella which I used in school, but which is closed source and, iirc, rather expensive.

The idea is that you can create objects and specify their relation, which means that you can either say things like "acceleration = force / mass", or things like "velocity gains/looses by "acceleration"" (which is, mathematically, a derivation).

A simple example for a falling stone might be something like this:

mass: 1 # in kg

force: -9.81 # in N

acceleration: force / mass

velocity: 
     gains by: acceleration
     initial: 2.5

height:
     gains by: velocity
     inital: 0
[download]

This will output a parabolic curve for height, and an linear for velocity. This is trivial to calculate manually as well, but if you want to add things like air resistance it's very hard to do manually.

That means that you can model physical relations (and other things, but being a physicist I tend to forget them...) with only very little physical knowledge, and without knowing it you are actually writing down a differential equation.

Solving that isn't hard (my prototype does that with Math::RungeKutta), the real work is manage the objects, ensure that values aren't calculated multiple times (to boost efficiency), and to create a usable API.

Further along the way I see a serialization format (based on yaml, json, xml or the like), plotting of the results and perhaps a GUI.

And I'm targeting the "everything is a library" approach, in Perl term "everything is a Module", so that large parts of the application (especially the modelling backend) can easily be used by other programs.

Am working on this occasionally, and plan to release the first modules to cpan as soons they have a stable API (and are not too buggy).

---

Perl 6 in German

Interesting that you say that. I'm slightly digressing here, but I was looking at a creative writing forum recently where a student said they couldn't think what or who to write about.

A fairly well-known writer (trying to be blunt and calling a spade a spade, etc) responded to this by saying 'there's not an awful lot of point wanting to be a writer if you can't think of anything to write about.' (I'm paraphrasing here, I think the sense was: ..if you haven't got anything you *want* to write about)

I suppose you don't always know till you get there, how much you'll enjoy a project. But if I have a need to work on (or interest in) something it certainly helps motivation

That really was less than £0.02 from me. Excellent meditation subject, though. ++

Ask yourself: Do you have an itch to scratch? Do you have some particular problem you need to solve?

If you don't, chances are that whatever particular cool module you start making or maintaining, you'll quickly lose all interest in it and it becomes a burden -- unless you really have that much extra time in your hands. It's symptomatic that you can't put a name on any topic that would interest you. Usually (of course not always) this means that you are raring to do something, but once you have that something to work on, it's not what you want. (Case in point: PDF::Writer.)

On the other hand, if you accept requests, I could use Perl bindings to libogg and libvorbis -- mind you, something more Perlish than converted C interface. The goal: being able to effetively manipulate audio data in Perl, the first step being able to decode audio data and then, after processing, encode it again. This is relatively simple and you would gain some XS and C experience in the meantime.

(I had some ready code for this, but my harddrive had a mechanical failure, and since then I've noticed that there's no burning need to have it after all. But it would be nice to have. If the module even supported loading data directly into piddles, the more the better!)

Don't dive off the deep end, it's easy to overestimate your time/effort/ambition ... wade in.

The best way to learn about coding, stretch your skills, and help the community is to find something that can use more tests or fixes to existing bugs -- the merit of new features may be disputed, but few people can argue with a bug fix or better test coverage.

go through the phalanx ... look for modules you use that have little problems you think you can fix easily. no matter how trivial they may be, fixing them will involve becoming more familiar with the code involved, which will give you more breadth of perl knowledge. submitting the patches will give you more exposure to the world of "open development" and pave the way for more ambitious projects.

• It was coded originally using test-driven development, so there's lots of good tests and a decent harness for adding more. If you break it, you'll know.
• It's meant to implement a published, stable spec. You won't need any creativity to find more stuff to do and you'll have a great source of test cases.
• People are begging for more features and will shower you with praise when you deliver them.
• You'll get to put some buzz-words on your resume - hot ones like XML, XML Schema, SAX, etc.

-sam

i wouldn't mind working on this myself. :-) Where do you suggest i begin?

Great! I'd start by picking a small feature from the spec that XML::Validator::Schema doesn't support - some detail in the simple type system perhaps. First write a test case that fails, then implement the code necessary to get the test passing.

-sam

Not being an author yet myself, I'm becoming enlightened on what it means to be an author and just how much of a jerk module users can be CPAN Author Struggle: Am I a jerk? (unter-jerk).

I've been using Net::SSH::Perl for a long time now, not only because it's practical for what I'm trying to do, but the idea of someone re-implementing the SSH protocol using just perl alone, was just, well...neat!

Being a heavy user, I ran into a bug that I was able to hack up a fix for (I still don't believe it's fixed, but that is another story).

Recently, I found myself needing to connect to a far end machine via SOCKS proxy, and first asked here on what to do Using SSH via SOCKS5 Proxy (Solution Posted). What I really wanted was for Net::SSH::Perl to use Net::SOCKS to get the job done, so I went ahead and modified it myself. Well, hacked it with a ball-peen hammer is probably more accurate however it did work fine. Then, before sending it I stopped to think about the stuff I learned from my unter-jerk experience, and realized that my hacks would probably not be viewed as usable by the author. After some internal debate, I sent them anyway, just in case the author didn't think they're as bad as I do.

After additional research, I found a much more elegant way in the form of the Net::SSH::W32Perl module, and so hacked that up to do the SOCKS stuff. Much better result!

Now I'm torn on what I think the right solution should be. Ideally, both the SOCKS and W32 functionality should be in the Net::SSH::Perl module, but again there are probably reasons why W32 was created. Hmmm..., I'm learning all the time.

The upshot of this long story is that if you're interested in teaming up with me (and hopefully the author) with Net::SSH::Perl, I'm game!

-Craig

A module that needs attention, as the original author might not have any interrest anymore, but the rest of the world has, might be Spreadsheet::ReadSXC, which is a XML task.