Improvements on CPAN are always welcome. You just have to remember its basic principle: make life easy for authors. In other words, the barrier to entry should be as low as it can be.

So the basis of CPAN, the mirrored repository of plain tarballs, IMHO needs to stay the same. Some authors don't like RT, or web forums and don't even use source control. That's fine. Their contributions are no less important than those of "good citizens".

That said, there is certainly room for improvement, and in fact in the last few years, a lot of work has been done _above_ the current CPAN: RT, CPAN Forum (is it missing features?), Anno CPAN,, CPAN Testers, CPANTS... and recently alias's Top 100(s), amongst others.

Now it's true that all those sites do not have a common look and feel, but it looks like people are taking notice and doing something about it.

What's missing there from your list are mostly GitHub specific features, but nothing prevents you, or any other CPAN author, to use it. It looks like they do actually, as a search on Perl shows 1592 repositories. And if you don't like GitHub (I don't), you can use an other repository (launchpad seems nice enough).

What I want to say here, is that instead of planning of completely redoing the CPAN, maybe working incrementally on what you don't like (improve CPAN Forums maybe?) might be a more practical solution. You won't be alone in doing this.

Are you talking about upgrading CPAN or search.cpan.org? They aren't the same thing.

CPAN is the network of mirrored sites that contain distribution files, indices and so on. search.cpan.org is just one particular portal CPAN and the ecosystem of websites that people have built for bugs, forums, annotations, test reports, etc.

So what part of the ecosystem do you think needs fixing?

Of things you mentioned:

* Module activity levels - like on GitHub
* Author activity levels - like on GitHub
[download]

Do you mean repository commit activity or release activity?

If the former, some META.yml files in distributions are now listing repositories (these show up on search.cpan.org if they exist). Of course, some of those URLs are to actual repositories and others are to repository "dashboards". If you can figure out the difference, go for it.

If the latter, there are already several "recent upload" feeds. Just start tracking one and create a site to report aggregate details.

* The ability to "follow" modules - so you will know when they are upd
+ated.
[download]

Same answer as I just gave -- except now create the user registration and tracking preferences to go with it.

* Discussion forums that: 
  o Are faster
  o More modern
  o Include the features that thousands of other forums should Just Ha
+ve.
[download]

Do you realize that the forum software that drives http://cpanforum.com is the CPAN::Forum module on CPAN? There's even a page of notes for developers including the subversion repository. So if you think it needs features/fixes, I'm sure Gabor is open to discussing your patches.

* Source control - either via SVN, Darcs, Git or what-have-you.
[download]

This will never work, since CPAN has thousands of authors who may prefer different source code systems. And why should the Perl community rebuild what already exists on googlecode, sourceforge, github, etc.? That's not a good use of anyone's time.

* Forking/Branching/Merging - like on GitHub. Abandoned modules should
+ not be allowed to languish forever. This process could replace the c
+urrent "Take over a distribution" workflow in PAUSE.
[download]

You're mixing several issues here. Fork/branch/merge is about evolution of a code tree. "Take over a distribution" workflow is about ownership -- more specifically, permission over changes to the index for a particular namespace. Nothing stops you from uploading your own Foo::Bar module if one already exists, but it won't be indexed for CPAN/CPANPLUS clients unless you have permissions for that namespace.

A new site or a github-like "fork" button isn't going to change the permissions process. A willing author can give permissions in under a minute on PAUSE. And there is a process -- manual and subject to administrator oversight -- to do the same in the case where an original author can't be contacted. And I don't think we should ever take human judgment out of the loop in the latter case.

So, ultimately, if you think "CPAN" can be upgraded, then start writing code -- no one is stopping you.

After using GitHub, Google Code and other online coding collaboration tools, CPAN (once a shining jewel in my view) is starting to feel a bit 1990's-ish.

CPAN is also not a community effort. It was created by a few who 'just fucking did it'. IMO, CPAN was great, still is great, and will be great in the future. It's simplicity and unpretentiousness are the keys to its success. That allows the many mirrors to exists - the simplicity means virtually no (CPAN-specific) maintenance.

Ladies and Gentlemen, we can rebuild it. We have the technology. We have the capability to build something better than the current search.cpan.org

If you want something better than CPAN, start building. Words are cheap. In the open source world, you're judged by your actions, not your speeches.

CPAN is not an online coding collaboration tool. CPAN was, and will always be, a distributed distribution mechanism. Nothing more, nothing less.

I wouldn't say "always" there. Or at least "always" + "only" - I might have misunderstood the new whizbang features in Perl6's modules but this part right here:

The syntax of a versioned module or class declaration has multiple parts in which the non-identifier parts are specified in adverbial pair notation without intervening spaces. Internally these are stored in a canonical string form which you should ignore. You may write the various parts in any order, except that the bare identifer must come first. The required parts for library insertion are the short name of the class/module, its version number, and a URI identifying the author (or authorizing authority, so we call it "auth" to be intentionally ambiguous).
For example:

    class Dog:ver<1.2.1>:auth<cpan:JRANDOM>;
    class Dog:ver<1.2.1>:auth<http://www.some.com/~jrandom>;
    class Dog:ver<1.2.1>:auth<mailto:jrandom@some.com>;
[download]

Since these are somewhat unweildy to look at, we allow a shorthand in which a bare subscripty adverb interprets its elements according to their form:

    class Dog:<1.2.1 cpan:JRANDOM>
[download]

So instead of just

use DBI;
[download]

I could have

use DBI:ver<4.2>:auth<http://www.devstack.com.com/cpan/DBI>;
[download]

and get a completely different set of code than the "canonical" version (who knows how we decide on that).

Just Perl6's package loader tells me that something significant is about to happen to CPAN - and someone (I'll do it if I can get the time to) will need to accommodate the new features Perl6 will provide. I figure we could extend those features to Perl5 by adding coderefs to @INC. Something like:

use NiftyPerl6PackageNames;
use DBI:ver<4.2>:auth<http://www.devstack.com.com/cpan/DBI>;
[download]

..............................

CPAN is also not a community effort.

If you say so...

It was created by a few who 'just fucking did it'. IMO, CPAN was great, still is great, and will be great in the future.

I have a strong feeling that a single, comprehensive archive of instantly-installable, free and open-source code will not only belong to Perl much longer. Other platforms could really benefit from something similar, and before long I'm sure CPAN will be viewed as a "predecessor to XYZ" (where XYZ is the Great New Thing for something else, like Ruby, .Net or Python).

I also believe that if (for example) someone like Microsoft were to create a "CPAN" for .Net, it would have all the features I've mentioned above, and more. Ultimately it would make our beloved CPAN look like a toy from the 1990's.

It's simplicity and unpretentiousness are the keys to its success. That allows the many mirrors to exists - the simplicity means virtually no (CPAN-specific) maintenance.

Uh-huh. Simplicity is good. So is a lack of pretense.

You and I and every programmer in the world knows that the first time you write a system, you know you could always do it better the second time around. The thing is that every system becomes a prototype for its replacement. Even Perl5 will one day succumb to Perl6. It is inevitable.

Along similar lines, the CPAN and all of its satellites will one day either become or become eclipsed by another CPAN-esque service that is simply Way Better.

Saying that what we have is Good Enough, or slinging the good old "Well then crank some code out, dude" just won't cut it. I have a few modules on CPAN and am always adding more. I do crank out code when I can, and when I see a need that's not yet fulfilled - like this one.

Creating Yet Another CPAN Alternative is, while within my realm of skill, not what I would aim for. Instead, I would like to open the discussion for what the Perl community and user base will need for the next 20 years with Perl6.

If that discussion has already taken place, I will probably it 2 minutes after typing this response - and read it. And perhaps see why I'm barking up the wrong tree. Or maybe I'll post a link to that discussion within this thread.

Wish me luck ;)

You know what pissed me off about cpan.. Is when the lil portraits of the author's popped up :-)

I used to think the place looked so damn pro without any sillyness.. until.. that one thing came along..

I had fantasies of starting a campaign to get authors to associate blank squares for the pics .. hahaha...

Well.. at least I now know what Mark Stosberg looks like.

If you're collecting features you'd want, could you add alternate (disjunctive) module dependencies, where a module can depend on different combinations of other modules (and module versions)? The current dependency system is a bit restrictive, apt and other package managers have had disjunctions for ages. Also, maybe there could be recommended and suggested dependencies, not just required ones.

could you add alternate (disjunctive) module dependencies, where a module can depend on different combinations of other modules (and module versions)?

This is Perl. Of course we can :P

Actually I'm sure that it's possible simply by extending the grammar or perhaps even with something like this:

use any(qw( ModuleA ModuleB ModuleC ));
[download]

No, I mean dependencies the CPAN installer handles, so that when a module is installed it installs all the dependencies as well. (There are two varieties of these: dependencies that are only needed for building and that need to be permanently installed, but that is irrelevant now.)

The difficult part with these is that you don't want to make everyone update their CPAN package, so the only way this could go is that the info file of new modules can contain both the old style dependencies (which is just a plain conjunction of versioned modules) and new style ones. However, as ExtUtils::MakeMaker generates the info file from Makefile.PL, it could also write a sensible default for the old style if you give a dependency expression that has disjunctions in it.

ltjake is working on this. Might do you well to check it out.