Unthought.

Keeping software current

Few enough third-party components that keeping them current stays possible three years after launch.

Every package added to a project is an obligation somebody will have to honor, and usually not the person who added it. The install takes a second; the commitment runs for the life of the system. That asymmetry is why the number of them is treated as a decision rather than allowed to accumulate.

Adding a third-party component is argued in writing: what it does, what it would take to do without it, how actively it is maintained, and what it drags in behind it. Most candidates do not survive the fourth question.

The count is kept small enough that upgrading remains a task, not a project. A system resting on a handful of them can still be rebuilt three years later; one resting on several hundred has had its maintenance cost decided by whoever assembled it, and the bill arrives when a security advisory forces an upgrade that cascades.

Upgrades happen on a cadence instead of in response to alarm. Small and frequent moves are ordinary work; a system left untouched for two years faces a set of major version jumps that have to be taken together, which is how routine maintenance becomes a project.

Advisories are watched and triaged, not applied reflexively. Whether a published vulnerability is reachable in this system's actual usage determines urgency, and treating every advisory as an emergency exhausts the attention needed for the ones that are.

Versions are pinned and recorded, so that what builds today builds identically tomorrow. An unpinned version means the build is a function of when it ran, which turns an unrelated release into a debugging session.

Framework major versions are planned for before they are forced. Support windows are published in advance, so the date is knowable, and the difference between a planned upgrade and an urgent one is entirely whether somebody looked.

Abandoned components are identified early. A package with no release in years and unanswered issues is a future rewrite with an unknown due date, and noticing while alternatives still exist is considerably cheaper than noticing when an advisory lands against it.

Tooling that ships nothing to a reader is held to a lighter standard than software that runs in front of one, deliberately. A linter that ships nothing to a user carries a fraction of the risk of a library that runs in the request path, and pretending the two deserve identical scrutiny wastes the scrutiny.

Exclusions

What this does not cover.

  • Adding a third-party component without an argument recorded for it.
  • Upgrades performed only in response to a security advisory.
  • Unpinned versions, or a build that cannot be reproduced from what is recorded.
Elsewhere in this area

Managed Services & Infrastructure