CPAN PAUSE Accounts for Organisations

kcott has asked for the wisdom of the Perl Monks concerning the following question:

The company I work for is considering putting some of its non-commercially-sensitive Perl modules on CPAN for general use. I have been asked to investigate this.

I already know about PAUSE and how to "Request PAUSE account" (I have such an account myself). The wisdom I'm seeking in this instance regards accounts for (commercial) organisations and whether there are any special considerations.

It looks like the process should be straightforward; but, of course, looks can be deceptive. If anyone has done this previously and encountered any stumbling blocks, gotchas, or such-like, a description of your experiences and how they were overcome (or, indeed, how to avoid them in the first place) would be much appreciated.

Thanks in advance.

— Ken

Comment on CPAN PAUSE Accounts for Organisations

Replies are listed 'Best First'.
Re: CPAN PAUSE Accounts for Organisations by Corion (Patriarch) on Jun 18, 2018 at 08:20 UTC
There is no infrastructure on CPAN to really model an organisation. What you can do is either do as MQSeries did and create the "MQ Engineering Group" account, and hope that the administrator of that account does not leave the company without handing over the credentials. The alternative would be to have contributors sign up on CPAN individually and hand them co-maintainership. The "group account" approach has the advantage of keeping the administration of the account simple, but creates a bottleneck for releases etc. where those credentials are needed. The "comaintainer approach" has the advantage of allowing all comaintainers to release versions of the modules even across organisations, at the cost of needing more maintenance to add or remove comaintainership status. Personally, I only have experience with the comaintainership approach in private settings and so far it has worked well enough.	[reply]
Re^2: CPAN PAUSE Accounts for Organisations by kcott (Archbishop) on Jun 19, 2018 at 04:50 UTC
G'day Corion, ++ Thanks for your response and advice. Although I didn't have any formal plan for this, what I originally had in mind was closest to the group approach you outline; however, the comaintainer approach does have advantages. Accordingly, I'm considering a model (which uses a bit of both) along these lines: A company account, as per group approach, controlled by the IT Manager (probably with credentials held by an additional person, e.g. SysAdmin Manager). IT Manager to grant and revoke comaintainer privileges to developers as necessary. [For anyone interested, "The PAUSE Operating Model" has details about comaintainers, privileges, and so on.] — Ken	[reply]