Passing maintenance or deprecating projects?

I think this problem is accruing in all languages. CPAN is just the oldest repository and Perl doesn't have a standard library so you have to deal with it for things that IMHO you really shouldnt (like JSON and CSV... sigh... but i digress)
Some random thoughts:

• if youre an author and the thing your library talks to goes away or becomes completely broken (like a webservice going out of business or ditching its v1 api that your library used) - then you should delete it entirely from CPAN and mark it as dead in github. Delete it from github if you like, although i think its kinder to leave it up with a notice of why its been marked as dead
• Repos like CPAN are sort of a dumping ground. CPAN doesnt have any release signing at all, nor do any of the tools check CRC's on tarballs. So its basically inferrior to most warez sites that at lease publish the SHA signatures of the rar files. Even torrents check the file integrity.This is a known problem thats not entirely specific to Perl's CPAN. Node's NPM has had some real problems.
• From the above problem, google has announced its "Assured Open Source Software" initiative.
• I do think its utter and complete clowntown to just cpanm stuff from cpan and run it in prod.You're literally just running some random persons code in your production environment without vetting it at all.
• Whilst its attractive and popular to perlbrew then cpanm to avoid using "system perl" - your distribution's perl packages and perl libraries are signed and checked when installed. The package maintainers are also actively managing CVE's so you don't have to. Do you know what CVE's are open against your perlbrew'd perl version in your prod?
• I would like to see CPAN itself become more opinionated and proactive in managing the software it holds. What that would look like is interesting to discuss. Obviously signing releases and checking SHA's would be a good start. But i think that we can the system itself could set a higher bar for inclusion of software (checking all tests work before indexing for example) and it could start to hide old releases from search.

This is an interesting problem and not just in software, we're talking about the sustainability of things that require people to continue to commit time and energy over a long term (possibly a long tail - the distribution of attention required follows a very familiar curve..). My thoughts:

• It's entirely a people problem.
• It's related to succession planning / handover.
• There are organisations that operate a business based on it (eg: corgibytes.com/)
• There are individuals who want to maintain things, and have made a career out of this, on their own terms (eg: words.filippo.io/full-time-maintai...) - aside: I'd love to be one of them!
• Open source projects that become useful would do well to have published succession planning in place - this alone would greatly increase confidence in depending on them.
• Succession planning does not have to wait for the originator / current maintainers to decide, contributors can provide this input while a project is still active, since they will have the ongoing interests, a silly example from the LKML concerning Linus from 2018 (it's long!): lists.linuxfoundation.org/pipermai...
• Assuming we already have a dependency on a project that starts to rot, then it's a risk management problem, with the usual risk treatments (these from ISO27001):
  • Accept it - do nothing and accept the risk of something eventually going bad (CVE anyone?)
  • Avoid it - migrate to a fresher equivalent if one exists, leave the rotting corpse behind.
  • Mitigate it - commit time and energy to maintain the project in lieu of it's originators, this could be simply a fork and take it all on approach, or it could be paying others to look after it (see above!), or forming an organisation with other dependees and sharing the costs.
  • The choice depends on the uniqueness of the project, your level of dependency, and your long term strategies. The choice is not set in stone either, for example: an organisation can opt to maintain a dependency while they engineer their way out of it.

Rant over - can you tell I used to do this regularly in the old day job?

Fork n republish is the way my friend

I definitely feel like this question doesn't get discussed enough in the dev community (for example, see this "unmaintained" search in GitHub).

We're trying to address this from two sides at Tidelift:

1) Pay maintainers (we call them "lifters") to keep packages up to date (and perform certain basic duties, like enable 2FA or address CVEs)
2) Offering companies a tool that lets them set standards on OSS dependencies. e.g. if you add a dependency to your Gemfile.lock or pom.xml, we'll tell you if it violates one of your own rules, like "this project hasn't been active for X days" or "this project has a conflicting license" or "this project has CVEs that haven't been addressed".

Speaking of package deprecation, I wrote up a summary of how it works across ecosystems a while back: dev.to/tidelift/the-current-state-...