This mediation was removed from part two of the BlueChild project. Part two deals primarily with ways to setup your development instance, which obviously will revolve to a large degree around CPAN. Originally meant as a discussion about how CPAN shares merit and responsibility, I decided to remove it since it felt a bit too tangential, as well as lengthened what was already a long blog posting.
I've come to strongly feel that a key difference between Perl and other languages is the depth to which you need to engage the Perl programming community in order to progress in skill and make best use of the available resources. I am not saying other languages don't also have large communities or engage in community building. However, Perl as a language seems to be to be more shaped by the community and the push and pull of ideas batted about the mailing lists and on IRC chat rooms than most other programming languages. Partially this is due to the fact Perl does not have one single company behind it with particular vested interests in promoting and shaping it. This is combined with the distributed and anarchistic nature of CPAN development to promote a culture that is extremely merit based (you get help and respect first by the nature of your contributions to the community) and yet insists on sharing responsibility for many key projects as widely as possible. This is achieved first by the ease at which it is to contribute code via shared software version control systems and by how widely co-maintenance of those modules as published to CPAN are.
On CPAN, it's normal for “handoffs” to take place over the maintenance of important modules. This distributed style encourages the development of sustainable and useful bits of code that can be glued together to form more complex systems. This is one of the key differences with Perl. Many other languages have distributed systems similar to CPAN, but they tend to be based as plugins around existing large projects. Perl tends to follow the Unix approach, where each module is intended to do one and only one thing as well as possible. Although this requires more upfront effort on the part of developers to learn the tools, it results in greater flexibility.
Since you have a big investment in so many of these shared resources, it encourages people to reach out to the primary authors of important projects. You might have a bug report, and hopefully a test and maybe offer a patch to fix the issue. I see a lot of this type of shared responsibility. For example, one developer might take the lead in releasing a new CPAN module during the first few releases (thus shaping the overall contours of the module) and then grant co maintenance to one or more important users of that module. Or, you might assign the job of release manager to someone you, as the lead, is trying to help mentor. In any case, this kind of responsibility sharing, via CPAN and increasingly via source code control systems such as git and github is a means by which the community shares merit and grows talent.
Being so, you really need to track what's going on in the community, and participating to the degree you are able. I recommend you do at least the following:
Following trends and updates to CPAN. I subscribe to a syndication feed and check it daily at the minimum. After a while you will get to learn which projects are being aggressively worked on. Hopefully you will see a few useful things you didn't know about. For example, I discovered Moose because it's a project with a lot of development and it kept showing up in my feed.
For the projects important to you, join the mailing lists or IRC chats where developers and user hang out. I recommend 'lurking' a bit to get to know who is who and to get a feel for the tone of the group. If you haven't been on IRC before, there's a great and easy to use Firefox extension called “Chatzilla” which although not the most feature-full IRC client, will help you get going.
For help getting to know Perl IRC channels.
There's a couple of blog aggregators you should know about:
One thing I'd like to add. CPAN get's a lot of flack at times when it's difficult to build your software due to changes somewhere in the dependency stack. This used to frustrate me as well, but now I have come to understand that with a system as large and complex as this, keeping it working is work and not always easy work. CPAN can be great when everyone takes responsibility for the bits they need. I think the biggest issue is getting out all the information and tools needed to make it much easier for people to join and and solve problems on CPAN. We need to make it easier to work with the source code (via something like git's easy cloning feature) and easy to find original authors and get co maintainance roles. We also need to do a better job of teaching people how to become CPAN authors and get contributing. I think if we can do that, CPAN will become as reliable as it is deep in features.