A private CPAN does not preclude you from using a source control systems for deployment. Nor does it preclude you from using a more general packaging system (like RPMs) to distribute your code. These are complimentary technologies that fit around a private CPAN.

In my experience, the purpose of a private CPAN is to enable organizations to leverage the CPAN tool chain for managing the dependencies between their own modules and their third-party libraries (i.e. the public CPAN).

I'm not suggesting that everyone *should* use a private CPAN, especially if they are already comfortable with their dependency management infrastructure. However, there are a significant number of organizations that don't manage their Perl module dependencies well. Often times, this leads to application failures, unnecessary development costs, and general chaos.

Private CPANs have started to emerge as one possible solution for managing Perl module dependencies. But the current tools for creating, maintaining, and using a private CPANs are very fragmented. Moreover, the patterns for using those tools are not well established. My goal is to assimilate the existing tools and knowledge (and perhaps some new tools and knowledge) into a coherent product.

So this thread certainly isn't relevant for everyone. But if your production system has ever crashed because the team down the hall decided to upgrade their app to the latest Catalyst, or if you have to debug in production because you can't reproduce the exact same system somewhere else, or if you've ever had to force-install a module with failed tests, then I want to hear from you.