Shingo Kawamura

Posted on Oct 1

CPAN Rescue: Growing Maintainers, Not Collecting Modules

#opensource #perl #softwareengineering #community

CPAN has been around for more than 30 years.

That means something interesting has started to happen.

Some modules are still useful.

Some are still deeply embedded in production systems.

Some sit underneath dozens, hundreds, or thousands of other distributions.

But the people who originally maintained them may have moved on.

The code remains.

The dependency remains.

The maintenance responsibility does not automatically move with it.

That is the problem I started CPAN Rescue to explore.

https://github.com/kawamurashingo/cpan-rescue

At first, the idea was simple:

Find useful CPAN distributions that are abandoned or under-maintained, help repair them, and adopt them when appropriate.

After doing the work, I realized that rescuing modules is not the real problem.

The harder problem is this:

How do we create the next generation of open-source maintainers?

Software can outlive its maintainers

A library does not need frequent releases to be valuable.

Sometimes the opposite is true.

A module may be ten or fifteen years old because its API is stable and it simply works.

That does not mean nobody depends on it.

A quiet dependency can still sit underneath:

production applications,
developer tools,
build systems,
database clients,
command-line utilities,
or hundreds of other packages.

But maintainers are human.

People change jobs.

They become busy.

Their interests change.

They burn out.

They move to another ecosystem.

Eventually, a project can reach a strange state:

Code: still useful
Users: still present
Dependencies: still present
Maintainer: unavailable

At that point, the problem is not merely "old code."

It is a stewardship problem.

My first instinct was: just maintain more modules

That seems like the obvious solution.

If a useful CPAN distribution needs help, someone can adopt it.

So I started doing exactly that.

CPAN Rescue has already reached a few concrete outcomes:

distributions have been adopted,
an upstream pull request has been merged,
a post-adoption CPAN release has been published,
and maintenance work has included regression testing, artifact validation, and downstream compatibility checks.

One example is Devel::CallChecker.

It is a low-level compatibility module used around Perl call-checking APIs, including XS code.

This is not the kind of module where I wanted to say:

"Its own test suite passes, so let's ship it."

For infrastructure code, that is not enough.

The work involved reconstructing the current baseline, understanding existing behavior, checking metadata and release artifacts, and testing downstream distributions so that existing failures could be distinguished from regressions introduced by a new release.

That experience reinforced something important:

Maintenance is a skill of judgment, not just a skill of coding.

But it also exposed a flaw in the original idea.

If I adopt 10 modules, I become responsible for 10 modules.

If I adopt 100 modules, I become responsible for 100 modules.

That does not solve the bus-factor problem.

It just moves the bus factor to me.

So CPAN Rescue changed direction

The project is still about maintaining real CPAN software.

But adoption is no longer the primary goal.

The goal is now:

Use real maintenance work to grow maintainers.

I want someone to be able to enter the project without already knowing how CPAN maintenance works.

They should not need a PAUSE account.

They should not need release experience.

They should not need to promise to maintain a distribution forever.

Instead, responsibility can grow gradually.

The path currently looks like this:

Explorer
   ↓
Contributor
   ↓
Release Contributor
   ↓
Co-maintainer
   ↓
Maintainer / Steward

This is a path, not a ranking.

Nobody is required to reach the final stage.

What does a first maintenance task look like?

The first task should be small.

For example:

verify the current CPAN release,
identify the canonical source repository,
reproduce a reported problem,
run the existing tests on a modern Perl,
add regression coverage,
repair CI,
inspect generated metadata,
test a release tarball in a clean environment,
or classify downstream test failures.

These are real maintenance tasks.

They are not exercises invented for training.

That matters.

A toy project can teach syntax.

It cannot easily teach questions like:

Is this failure caused by our patch or was it already present?
Is the repository actually the source of the CPAN release?
Does this behavioral change violate an old compatibility promise?
Should this module be revived at all?
How much downstream testing is appropriate?
Should we adopt it, co-maintain it, fund it, or migrate users away from it?

Those are maintainer questions.

And the only good way I know to learn them is by maintaining real software.

Release engineering is part of maintainership

Writing the patch is often the easy part.

For important infrastructure, a maintainer also needs to understand:

source
  ↓
build
  ↓
release artifact
  ↓
distribution metadata
  ↓
upload
  ↓
indexing
  ↓
CPAN Testers
  ↓
downstream behavior

A release can be technically valid while still being unsafe for the ecosystem.

That is especially true for low-level modules with many reverse dependencies.

So CPAN Rescue tries to make release validation part of the learning process.

A contributor may help:

build and inspect a release artifact,
test representative downstream distributions,
compare candidate behavior with the previous release,
review CPAN Testers results,
or investigate regressions after release.

You should not need release credentials just to learn release engineering.

That boundary is important.

Maintainers also need to know how to leave

There is another side of open-source maintenance that we do not talk about enough.

We often explain how to become a maintainer.

We rarely explain how to stop being one.

That creates an unhealthy implication:

Once you accept responsibility, you own it forever.

No human system should work that way.

So CPAN Rescue treats handoff as part of normal stewardship.

A healthy maintainer should be able to leave behind:

a clear canonical repository,
a reproducible release process,
the current release state,
known regressions,
important downstream risks,
CI and release requirements,
open work,
and a clear transfer of repository and PAUSE permissions where appropriate.

If nobody is available to take over, that fact should be visible.

Stepping back should not be considered failure.

A project that cannot survive the departure of one person was never sustainable in the first place.

Not every old module needs to be rescued

This is another lesson I learned quickly.

An old release date is not evidence of abandonment.

Some modules are simply finished.

Others may have an active maintainer who does not release often.

And sometimes the correct answer is not maintenance at all.

For a given distribution, the ecosystem may be better served by:

preserving it,
finding a co-maintainer,
funding the existing maintainer,
improving CI,
documenting a migration path,
replacing it with a maintained alternative,
or deliberately doing nothing.

That means "number of adopted modules" is a terrible success metric.

If adoption itself becomes the goal, the project starts optimizing for ownership instead of ecosystem health.

I do not want CPAN Rescue to become a collection of modules.

What should success look like?

Technical outcomes still matter.

I want to track things like:

bugs fixed,
regressions prevented,
releases published,
upstream patches merged,
reverse dependencies protected,
and abandoned distributions returned to a maintainable state.

But those are not the metrics I care about most.

The more important questions are:

How many people completed a real maintenance task?
How many participated in release validation?
How many became co-maintainers?
How many eventually made an independent release?
How many maintainers were able to hand responsibility to someone else safely?

The project becomes truly interesting when this happens:

CPAN Rescue
    ↓
new contributor
    ↓
release contributor
    ↓
co-maintainer
    ↓
maintainer
    ↓
teaches another contributor

At that point, maintenance capacity is reproducing itself.

That is much more valuable than one person maintaining a large number of modules.

Why CPAN?

CPAN is a particularly interesting place to test this idea.

It is old enough to contain multiple generations of software.

It contains modules that are:

new,
stable,
forgotten,
deeply depended upon,
historically important,
actively maintained,
or quietly embedded in systems nobody wants to rewrite.

This makes it a useful laboratory for a problem that every mature package ecosystem eventually faces.

The details differ, but the underlying questions are familiar across ecosystems:

CPAN        → Perl
PyPI        → Python
RubyGems    → Ruby
npm         → JavaScript
crates.io   → Rust

Who maintains infrastructure after the original author leaves?

How do new people acquire enough context to take responsibility safely?

How do we reduce bus factor without creating another overloaded maintainer?

How do we preserve institutional knowledge that currently exists only inside someone's head?

How should maintenance be funded without letting sponsors buy technical control?

These are not Perl-specific questions.

CPAN is simply where I am starting.

AI may make this problem more important, not less

AI is making code generation cheaper.

It can already help with:

reading unfamiliar code,
generating tests,
updating CI,
investigating APIs,
writing documentation,
and proposing patches.

That is useful.

But maintenance contains another category of work:

Should this change be released?

Is this API behavior actually a bug?

Is maintaining this package better than migrating users away?

How much downstream evidence is enough?

Who should receive release authority?

When should compatibility win over cleanup?

Those are stewardship decisions.

If producing code becomes dramatically easier, the bottleneck may increasingly move from:

"Who can write this?"

to:

"Who understands the consequences well enough to take responsibility for it?"

That makes maintainer education more important, not less.

Sustainability also means funding

There is another direction I want CPAN Rescue to explore.

Some infrastructure is important enough that volunteer maintenance alone may not be a sustainable answer.

In those cases, the right intervention may involve:

grants,
recurring sponsorship,
compatibility infrastructure,
paid maintenance capacity,
secondary reviewers,
or fiscal hosting.

But funding introduces its own governance problem.

A sponsor should be able to support maintenance without purchasing technical authority over a shared project.

So one of the questions I am beginning to explore is:

Can we fund maintenance capacity while keeping technical governance maintainer-led?

Again, I do not know the answer yet.

That is part of the experiment.

The real hypothesis

CPAN Rescue is still young.

I do not want to present it as a solved model.

The central idea is still a hypothesis:

Can real maintenance work be turned into a practical path for growing the next generation of open-source maintainers?

If the answer is yes, the important output will not be the number of modules rescued.

It will be the people who become capable of maintaining software responsibly.

And the best possible outcome would be slightly paradoxical:

CPAN Rescue should eventually work without me.

If the project depends permanently on its founder, then it has reproduced exactly the problem it is trying to solve.

What I want to leave behind

The name "CPAN Rescue" makes it sound like the goal is to save old Perl modules.

That is part of the work.

But it is not what I ultimately want to preserve.

I want to help build a culture where software can be:

understood,
maintained,
released,
reviewed,
handed over,
and eventually entrusted to someone new.

Not forever by one maintainer.

But across generations of maintainers.

If we can demonstrate that model in CPAN, perhaps some of the lessons will be useful elsewhere too.

The project is here: