DEV Community: Shingo Kawamura

CPAN Rescue: Growing Maintainers, Not Collecting Modules

Shingo Kawamura — Thu, 01 Oct 2026 10:27:03 +0000

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://cpan-rescue.com

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:

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

If you maintain CPAN distributions, depend on older Perl infrastructure, or are interested in open-source sustainability and maintainer succession, I would be very interested in your feedback.

I built a transport-independent foundation for JSON API clients in Perl

Shingo Kawamura — Sat, 19 Sep 2026 23:37:59 +0000

Writing a simple API client is easy.

my $response = $http->get($url);

Then the client starts being used in production.

Suddenly, it needs to handle:

query parameters
JSON encoding and decoding
structured errors
retries and Retry-After
rate limits
pagination
authentication
request IDs
logging and metrics
idempotency

At that point, what started as a small API wrapper often becomes a collection of infrastructure code.

I found myself looking at this problem and asking:

How much of this is actually specific to the API being wrapped?

Not very much.

That led me to build HTTP::API::Core, a small, dependency-light foundation for building JSON HTTP API clients in Perl.

The key idea is simple: keep HTTP transport separate from API-client policy.

Use HTTP::Tiny, LWP, Mojo::UserAgent, Furl, or your preferred transport for HTTP. Let HTTP::API::Core handle the repetitive policy around it.

The project is available on GitHub.

It is deliberately not another HTTP client

One of the main design decisions was not to replace the existing HTTP ecosystem.

Perl already has good HTTP implementations:

HTTP::Tiny
LWP
Mojo::UserAgent
Furl

HTTP::API::Core sits above the transport layer.

The HTTP implementation is responsible for making the request.

HTTP::API::Core is responsible for the application-level policies surrounding that request.

Conceptually:

Your API client
      |
HTTP::API::Core
      |
HTTP::Tiny / LWP / Mojo / Furl / custom transport
      |
     HTTP

This separation means an API wrapper does not have to couple its retry, pagination, error handling, or authentication logic to a particular HTTP library.

A small example

A client can start with:

use HTTP::API::Core;

my $api = HTTP::API::Core->new(
    base_url => 'https://api.example.com',
    headers  => {
        Authorization => "Bearer $ENV{API_TOKEN}",
    },
    timeout => 10,
    retry => {
        attempts   => 3,
        base_delay => 0.25,
        max_delay  => 5,
        jitter     => 1,
    },
);

my $response = $api->get('/users');
my $data = $response->json;

A service-specific client can then remain small:

sub get_user {
    my ($self, $id) = @_;

    return $self->{api}
        ->get("/users/$id")
        ->json;
}

The resource method describes the API.

The core handles the repetitive infrastructure around it.

Retries are more complicated than they look

Retries were one of the areas where I wanted conservative defaults.

HTTP::API::Core retries safe/idempotent methods by default:

GET
HEAD
PUT
DELETE
OPTIONS

It does not automatically retry POST or PATCH.

Retryable failures include transport failures and HTTP responses such as:

It also understands Retry-After and rate-limit reset metadata.

Delays use exponential backoff with optional jitter.

If an API explicitly supports idempotent POST requests, that behavior can be enabled rather than silently assumed.

For example:

$api->post('/jobs',
    json => { task => 'sync' },
    retry => {
        attempts => 2,
        methods  => ['POST'],
    },
);

The goal is to make the safe behavior the boring default.

Rate limits should be data, not special cases

Different APIs expose rate limits differently.

Instead of making application code repeatedly inspect raw headers, responses expose normalized rate-limit information:

my $rate = $response->rate_limit;

say $rate->limit
    if defined $rate->limit;

say $rate->remaining
    if defined $rate->remaining;

say $rate->wait_seconds
    if $rate->exhausted;

HTTP::API::Core understands the commonly used X-RateLimit-* family as well as standard-style rate-limit fields and Retry-After.

The retry system can use the same normalized information.

This is one of the ideas behind the project: parse infrastructure information once and expose it consistently.

One pagination interface, different API styles

Pagination is another thing that looks trivial until you support several APIs.

Some APIs return a next URL.

Others use page numbers.

Others use opaque cursors.

HTTP::API::Core provides one iterator interface for these styles.

For cursor pagination:

my $pager = $api->paginate(
    '/users',
    mode  => 'cursor',
    items => 'data.users',
    next  => 'meta.next_cursor',
    query => { limit => 100 },
);

while (my $user = $pager->next) {
    ...
}

For page-number pagination:

my $pager = $api->paginate(
    '/users',
    mode      => 'page',
    items     => 'users',
    page_size => 100,
);

my @users = $pager->all;

Repeated cursors or next URLs are detected so a broken API response does not accidentally create an infinite pagination loop.

Authentication is implemented through hooks

I did not want authentication to become a growing collection of special cases inside the HTTP client.

Instead, HTTP::API::Core provides lifecycle hooks.

For example:

my $api = HTTP::API::Core->new(
    base_url => 'https://api.example.com',

    hooks => {
        before_request => sub {
            my ($ctx) = @_;

            $ctx->{headers}{Authorization}
                = "Bearer $token";
        },

        after_response => sub {
            my ($response, $ctx) = @_;

            log_status($response->status);
        },

        on_error => sub {
            my ($error, $ctx) = @_;

            record_failure($error->category);
        },
    },
);

The same mechanism can be used for:

authentication
logging
metrics
tracing
request customization

Small helpers for Bearer, Basic, and API-key authentication are included.

OAuth token acquisition and refresh deliberately remain outside the core.

Observability without choosing an observability framework

The library records useful request metadata without requiring a specific logging or tracing stack.

For example:

say $response->elapsed;

say $response->request_id
    if defined $response->request_id;

Common request ID headers are normalized, including:

X-Request-Id
Request-Id
X-Correlation-Id

Hooks can then send this information wherever an application wants.

The library provides the data without deciding how the application should observe it.

Structured errors

Another design goal was to avoid application code parsing human-readable error strings.

Errors have machine-readable categories such as:

encode
decode
transport
http
hook

Application code can inspect fields including:

$error->category;
$error->status;
$error->retryable;
$error->request_id;

HTTP errors retain their response information, so callers can still inspect headers, text, JSON, or rate-limit state.

Transport independence

The transport boundary is intentionally small.

A transport receives:

($method, $url, \%options)

and returns a response-like hash containing at least:

status => 200

That means the same API client policy can sit on top of different HTTP implementations.

It also makes testing API-specific code possible without requiring real network requests.

Testing against real API conventions

The repository includes example clients demonstrating different API styles:

GitHub — page-number pagination and rate-limit metadata
Slack — cursor pagination
Cloudflare — page-number pagination using response metadata

These are not intended to replace their official SDKs.

They are examples showing that the abstraction can map onto APIs with significantly different conventions.

What I intentionally left out

A reusable core can easily become a framework that tries to solve everything.

I am trying to avoid that.

HTTP::API::Core intentionally does not handle:

service-specific SDK behavior
complete OAuth flows
OpenAPI generation
GraphQL-specific behavior
WebSockets
HTTP server functionality
async runtime concerns

The project is intended to remain small, predictable, dependency-light, and transport-independent.

The broader idea

Although this implementation is for Perl, the architectural question is language-independent.

Where should the boundary be between:

the HTTP transport,
reusable API-client policy, and
service-specific domain methods?

Putting everything into the HTTP layer makes the transport too opinionated.

Putting everything into every service SDK means repeatedly implementing retries, pagination, errors, authentication, and rate-limit handling.

HTTP::API::Core is my attempt to put that boundary in the middle.

Try it

HTTP::API::Core is available on GitHub:

👉 github.com/kawamurashingo/HTTP-API-Core

I'd be especially interested in feedback from people who maintain API clients or SDKs:

What functionality do you consider generic API-client infrastructure, and what would you deliberately keep out of a core like this?

Why I Built a jq-Compatible Tool in Pure Perl (and Why It Still Matters)

Shingo Kawamura — Fri, 02 Jan 2026 13:06:54 +0000

Modern tooling often assumes a perfect world:
latest Linux, internet access, package managers, and rebuildable binaries.

Reality is different.

In many production environments — especially enterprise, legacy, or air-gapped systems —
those assumptions break down.

That gap is why I built jq-lite.

The Problem: jq Is Great — Until You Can’t Use It

jq is an excellent JSON processor.
But in real operations, I kept hitting walls:

Legacy UNIX systems with outdated glibc

Air-gapped environments with no package repositories

Minimal containers without build tools

Environments where “just install jq” was not an option

In those cases, JSON processing didn’t disappear —
the need became more critical.

Shell scripts still had to be reliable.
Automation still had to work.

The Idea: A jq-Compatible Tool That Never Breaks Scripts

I didn’t want another JSON tool.

I wanted a tool that could be:

Dropped into restricted systems

Trusted in shell scripts

Stable across years, not releases

So I built jq-lite with three strict rules:

Design Rule #1: Pure Perl, No Dependencies

jq-lite is written in pure Perl.

No native extensions

No external libraries

No compilation step

If Perl exists, jq-lite runs.

That means it works on:

legacy Linux / UNIX

minimal containers

offline environments

systems where only base OS tools are allowed

Perl is still one of the most widely deployed runtimes in the world —
especially in places modern tooling forgot.

Design Rule #2: jq Compatibility Where It Matters

jq-lite aims to be jq-compatible in daily CLI usage:

echo '{}' | jq-lite --arg greeting hello '.hello = $greeting'

Output:

{
"hello": "hello"
}

The goal isn’t to clone every feature,
but to support the jq patterns people actually use in automation.

Design Rule #3: A Stable CLI Contract (This Is the Important Part)

Here’s the part that made jq-lite different.

jq-lite defines a documented CLI contract:

exit codes

error categories

stderr prefixes

stdout behavior on failure

And that contract is tested.

Exit Code Meaning

0 Success
1 -e used and result was false / null / empty
2 Compile error
3 Runtime error
4 Input error
5 Usage error

This means shell scripts can safely rely on jq-lite:

if jq-lite -e '.enabled' config.json; then
deploy
fi

No surprises.
No silent behavior changes.

In operations, this matters more than features.

Why Not Rewrite It in Rust or Go?

I get this question a lot.

Because the problem wasn’t performance or language fashion.

The problem was deployability and longevity.

Perl already exists on:

old servers

enterprise systems

restricted environments

Adding jq-lite doesn’t require changing the environment —
just using what’s already there.

Who Is jq-lite For?

jq-lite is not for everyone.

It is for people who:

maintain legacy systems

write shell scripts that must survive years

operate in restricted or offline environments

care about CLI behavior as a contract, not a suggestion

If you’ve ever thought
“this script must not break in five years”
— jq-lite is for you.

Where to Find It

GitHub: https://github.com/kawamurashingo/JQ-Lite

CLI Contract: https://github.com/kawamurashingo/JQ-Lite/blob/main/docs/cli-contract.md

CPAN: https://metacpan.org/release/JQ-Lite

Alpine Linux package available

Final Thought

Modern tools optimize for speed of change.

jq-lite optimizes for stability over time.

Sometimes, that’s the more important optimization.

Author
川村慎吾（Shingo Kawamura）
SRE / Infrastructure Engineer
CPAN author of jq-lite