The library you depend on was archived

The workflow

1. TriggerGitHubArchived repositories and the public repos that depend on them
2. Evidence
   OSV.devUnpatched vulnerabilities in the package
3. Artifact
   What you hand overA pull request on their public repo that swaps the dependency for a maintained one, with tests passing.
4. Contact
   GliderFinds the engineering lead, with a verified work email and a phone
5. Message
   Send itFrom your own mailboxes, evidence attached

The play in six steps

1. 01

   Find who depends on an archived library

   GitHub

   What you pull

   Repositories marked archived, and the public repos that list them as a dependency: owner, project and how recently it was updated.

   Why it matters

   An archived library will not get fixes. An active project depending on it has a problem it may not have noticed.

   Example

   HTTP library archived Aug 2026 · your public SDK depends on it · SDK updated last week

2. 02

   Check for open vulnerabilities

   OSV.dev

   What you pull

   Known vulnerabilities for the package and version they use, with severity and whether a fix exists.

   Why it matters

   A vulnerability with no fix coming makes the swap urgent rather than nice to have.

   Example

   1 high-severity issue · no patched version · archived, so none expected

3. 03

   Open the pull request

   Your artifact

   What you build

   A branch that swaps the dependency for a maintained alternative, updates the calls, and runs their test suite.

   Why it works

   The engineer reviews and merges. You did the part nobody had time for.

   Example

   12 files changed · tests pass · no API change for SDK users

4. 04

   Check before you send

   Run their full test suite and read their contribution guide before opening the PR. Do not disclose vulnerability details publicly beyond what is already published.

5. 05

   Find the engineering lead in Glider

   Glider

   Search for

   Engineering leadMaintainerCTOHead of platform

   Why them

   The maintainer merges. The engineering lead decides whether to hire help with the next one.

   What you get

   A work email and a direct phone, with the email verified before it goes into a sequence.

6. 06

   Send the evidence, then run the first test

   Your public SDK depends on an HTTP library that was archived in August.¹ It has a high-severity vulnerability with no fix coming.² I opened a pull request that swaps it for a maintained alternative. Tests pass and the SDK's API doesn't change.³ Here it is if you want it.

   • Facts from the data (the number is the step)
   • What you built for them
   • One small ask

   Why it works

   It is the fix itself, not an offer to fix. An engineer can judge it in five minutes.

   First test

   Ten public repos from companies with funding, each PR reviewed by hand.

   Success looks like

   Three merged pull requests and one consulting call out of ten.

The sample message is hypothetical and its numbers are illustrative. Verify every claim, date and rule before sending.

Sources used

The two sources this play names. Each links to the other plays that use it.

GitHubRepositories, dependencies and archived projects2 playsOSV.devOpen-source vulnerabilities by package1 play

Related plays

Play 09Software, web and AIForSEO and web agenciesToThe marketing leadYour redesign threw away introductions people are still making3 sources · 7 stepsPlay 10Software, web and AIForNiche software companiesToThe person who askedYour competitor keeps telling these buyers they can't help3 sources · 7 stepsPlay 52Software, web and AIForGEO agenciesToThe head of marketingAI search mentions your competitors and not you4 sources · 8 steps