• Review others' work, submit patches for bugs/perldoc enhancements, etc.
• Tutor new monks in the art of proper namespace usage
• Understand the apocalypse

For example, I've always wanted to enhance some of the *::SSH::* modules out there.

Please help! I desperately need help with a test suite for Net::SSH::Perl and Net::SFTP!

Most people just solve their own problems and try to make the solution general enough to help other people too. But there's no reason that has to be the only way. Good luck!

-sam

PS: XML::Validator::Schema needs a ton of work if it's ever going to even approach spec-compliance. If you're in the mood for some extreme XML nerdiness you're more than welcome to dig in!

This is exactly what I need. Thanks everyone.
meh.

I agree. I've always had an interest in ways I could give back to the community, but it can be hard to come up with something, especially if it's just for the sake of community involvement.

I have found in the past that it's often useful to me to assemble modules out of any code that I'm working on that is sufficiently reuseable. It takes a little more work to clean them up and write helpful documentation, but after that effort, it's a great feeling to make those modules available on CPAN.

In fact, once you share some code, there are people just waiting to help and make suggestions if they find your code and use it. Knowing I've made someone's life a little easier makes coding that much more worthwhile, at least to me. --andy

For Perl 5, the Phalanx project is a great place to help.

For Perl 6, Perl 6 Stories could use helpers.

In addition to the suggestions already given you might want to consider reviewing the modules that you use on cpanratings, becoming a cpan tester and (of course) submitting and bugs you find in the modules that you use to rt.cpan.org.

These all help people find good modules and get bad modules fixed.

I suggest not looking for a problem that needs solving and then putting it on CPAN. Doing it that way will probably end up with a shoddy peice of software. Rather, you will inevitibly find at some point that no solution exists for what you're trying to solve, or you find the existing solutions are insufficient.

The most important part of Open Source development is that the author starts with an itch that needs scratching. It is shocking how many Open Source zealots miss this simple point. Looking for a problem will not produce good Open Source software. Rather, the problem must come to you and bug you enough to do something about it.

I would also say start getting active with Perl 6 as this project moves forward there is going to need to be more feedback from the people getting themselve in trouble over the journey men, gurus, wizards and demigods.

I second the rate CPAN modules.

I have been working steadily toward a distant software goal for some time now. I find having a goal focuses your attention on the smaller steps you need to take in order to get there. On the way, you WILL contribute to the community--as you see the opportunity arise.

I am a jazz musician, and I'd like a really simple, non-proprietary way for folks to share leadsheets (the chord changes for a given jazz tune; the lyrics and notes can be copyrighted, but not the chord progression).

In addition, I'd like the program to be able to autogenerate some elementary accompaniment (bass, drums, and chords) so that folks who are learning jazz can play along and 'get' the tune.

Since I'm lazy (which is a virtue for programmers, remember), I want to first look around and see what existing systems are in place to interchange music. So far, I've found MusicXML, MIDI, and ABC file format, to name a few. I also want to see what similar or related programs are out there, so I could possibly interface my project with theirs (make it so I could out documents to lilypond, for instance, or the numerous abc systems).

Additional layers of complication: I want it to be as cross platform as possible (which is why I have three systems on my computer now, WinXP, Cygwin, and dual-boot with Debian).

Right now it looks like I'm about 2-3 years away from having a good product. I've built some elementary alpha versions of the program--Perl scripts that take a chord progression and make a walking bass line, for instance. But the more I learn, the more ideas I come up with for the final project.

And no, none of this is for profit. Truth is, I love jazz, and, as they say, the best way to make a small fortune in jazz is ... start out with a large one ;-)

Once I get some good modules up and running, I'll make em available on CPAN. Until I think they're really worthwhile and innovative, though, I'm keeping em to myself. In the meantime, if I learn something, I can share it, or provide a review of modules I've really found worthwhile (there's already a MIDI to MusicXML module, for instance, though I haven't had time to wrestle with it properly, yet).

I'm still not certain the final form will be in Perl, but there's no doubt--knocking out the code in Perl is about 10x more efficient time wise than doing it in Java or C. Perl gives wings to your algorithms, sometimes, by freeing you from the gravity of interface.

Computer music stuff is cool... I've had a long running idea in my mind for about 5 years now, on making "computer music that actually sounds good". The idea is that you could turn this thing on, and it would ad-lib and play forever -- in one constantly changing, never ending song. My problem is, I'm actually less musically talented from you, and I can't codify what sounds good until I hear it -- that is, generic rules such as "chord progression X to Y sounds good after a Z, but not after a W", etc. (This isn't the whole idea of course, since that implies a theoretically boring Markov-chain solution, but that's part of it)

I really don't like the CSound syntax, but it's about as powerful as any Debian package I can find for making instruments, so I may play with that... I don't know. (I'll take suggestions on any other Deb's for batch-mode non-real-time synthesis I might try).

Anyhow, I'm just rambling, but it does serve one point to the discussion... trying to 'contribute' is never fun unless you are having fun, taking on a project to do something cool without believing in it always ends in failure. Or Microsoft Windows :). Whichever.

So anyway, I'll need to get working if I want my software to be cranking out something Mountain Jam like anytime soon.

Actually, getting it to sound 'right' is 90% of the problem. Take the bass lines for instance: you can have a 100% technically correct line, but . . .

• It's hard to make a synthetic bass sound that sounds like the real thing, especially a doghouse (the big, upright bass you see a lot in jazz).
• If you are dead on the beat, you sound flat. To swing, you have to play around with the time a bit. (I can't seem to get my current model to swing.) I think it has something to do with anticipating beats 2 and 4 by a smidgeon, but probably more to do with articulation (also hard to do electronically)
• Ad libbing forever is possible--there's a book by Jerry Coker called 'Elements of the Jazz Language for the Developing Improvisor', where he analyzes thousands of jazz tunes and comes up with 14 to 20 'elements' that make up the vocabulary of jazz. BUT, you program a tune like this, you get . . . the sound of a computer pretending to play jazz. Again, rhythm, articulation, and just plain horse sense are hard to program . . . even in Perl ;-)
$jPxu=q?@jPxu?;$jPxu^=q?Whats?^q?UpDoc?;print$jPxu;

Spike.

Tests! (coverage report linked from phalanx).

Wouldn't it be nice to see test coverage on CPAN?

qq