CPAN is already a mess. What we have now is 10 bugs not fixed and not reported because 10 people know darn well that the 80% of the time the only way to get a bug fixed is to take on the role of "stalker" in hopes of getting the lovely prize of "now you get to be the one that people are supposed to stalk", 4 different versions of each module with slightly different names and significantly different implementations and feature sets, none of which are getting improvements applied particularly well (most of the time) and none of which is the clear best choice just in terms of features. Short spurts of one person having the time to work on a module and then their life taking a turn and the module sitting untouched for years until somebody is actually perverse enough to jump through the hoop of "play stalker to the last person who touched it" for 6 months in order to be allowed to contribute to it (meanwhile, the module has been "forked" 3 times by people just starting over with a slightly different name).

Freedom and encouraging collaboration is scary until you do it. I'm a bit shocked that so many in the Perl community haven't overcome that fear. So CPAN will continue with its mini-empire building while a bunch of us put our modules on github and encourage collaboration and make it free for people to do the work of getting a module into shape for a new release and then releasing it. Eventually, freedom and collaboration will produce such better results that most of the CPAN mini-empires will just look sad.

There is no point in trying to explain this to the powers that run CPAN. They will just take it as a personal attack anyway. Instead, just act like the internet and "route around roadblocks" ("censorship" in the original quote).

Those who are invested in the closed-ownership and "we must have roadblocks to prevent chaos" will be scared and predict failure and may even be so close-minded as to feel threatened. Meanwhile, open collaboration will increase the pace of innovation such that it will stumble here and there but in the end will produce much better results.

I want to have the modules that I created and put onto CPAN in a "anybody can contribute" mode, but CPAN won't even allow me to do that. They don't support such "anarchy". Because we know that the concept of wikis were a passing fad that was simply doomed to a chaotic failure.

So don't waste your time trying to explain the better way. Just do it the better way and those who can deal will see the better way and use it. Those who fear contributions from others will cling to keeping their "ownership" (until they inevitably lose interest and their contribution withers and fades from memory).

Most open-source projects spend much of their lifespan being driven by a single developer. How well an open source project can support an orderly transition to the next community of contributors is a major factor in how long the project remains viable and useful. Allowing more Perl modules to much more seamlessly accept new contributors and transition to new owners will allow such modules to become mature (something that the vast majority of even useful modules on CPAN can't achieve). It will be a great benefit to Perl developers.

The policies of the CPAN services mean that CPAN is a huge collection of mostly just individual contributions where collaboration is the exception. We can do so, so much better. And we will!

You can assign as many co-maintainers as you like on pause. If you want it open, simply state that and then add people as they mail you. I really don't see what's so hard about that. In fact, it seems like about 12 lines of WWW::Mechanize code and you'd have an auto perminator on your web page. Then you could go to Hawaii permanently, end of story.

I rather with cfaber would have done that. He seems to have lost the permissions to the two yokels who have it now... and they won't respond.

If it were me, I would totally just assign co-maintainership, particularly if I didn't have time to work on it. And cfaber would have done so too.

-Paul

You can assign as many admins as you like on pause

So I've heard it claimed. When I and another pointed out that the interface doesn't actually appear to support this, silence was the only response. (Re^6: Losing faith in CPAN - unresponsive module authors (ownership--))

I really don't see what's so hard about that

You presume I am even that active on CPAN. For most modules, that assumption is broken. I want to set up my modules so that others can contribute to them even after I get hit by a bus or become a Quarker, even for modules that nobody has yet expressed an interest in contributing to. And I want people to be able to contribute without there having to first be one person who has the unnatural motivation to play "stalker" for 6 months and then beg admins to deign to allow contribution. It would be even cooler if others could do the same. I really don't see what is so hard to understand about that.

- tye        

I don't think there is so much fear around as you think.

I want to have the modules that I created and put onto CPAN in a "anybody can contribute" mode, but CPAN won't even allow me to do that.

This is confused. CPAN is the Comprehensive Perl Archive Network and is well named (Ha, how I hope I am not walking into another backronym. ). If you have the right, you can develop a codebase where, how, and with whom you like, then you can release it on CPAN.

Licenses, established practice, and courtesy are arguments against summarily grabbing some author's code off of CPAN, reworking it, and putting it back on CPAN under the same name. It is not surprising that the CPAN admins are slow to declare code abandoned and then seize it.

Be well,
rir

It is not surprising that the CPAN admins are slow to declare code abandoned and then seize it.

It is not surprising that many choose not to contribute once they realize that contributing requires that "admins (slowly) declare code abandoned and then seize it". You nicely summarize the problem. Thank you.

This is confused. [....] If you have the right, you can develop a codebase where, how, and with whom you like, then you can release it on CPAN.

That seems to me to completely miss the point. Creation as the act of a single person is so very common. Maintenance is where collaboration is most useful. The ability to collaborate before submitting to the rules of the CPAN services is certainly not the problem, for multiple reasons. The need to thwart the roadblocks of CPAN services just to be able to collaborate should be seen as a problem, but, yes, we shall work around that problem.

- tye