All insights
EngineeringMaintenance5 min read
The pinned version that became a vendor
Some dependencies stop being dependencies — they become permanent forks, hand-patched, with the maintainer no longer involved. That's a vendor, even if you don't call it one.
There's a moment in many codebases where a dependency stops being one. The team pins to a specific old version, applies a few patches, and never updates. The library's maintainer doesn't matter anymore — your team is the maintainer now, whether you signed up for it or not.
Signs you've crossed the line
- You have local patches that would conflict with upstream changes.
- Your version is pinned to a release the maintainer has stopped supporting.
- Updating means a multi-week project the team keeps deferring.
- Nobody on the team has read the upstream changelog in over a year.
What to do about it
Either fork explicitly — name the fact that you own this code now, document your patches, set a maintenance owner. Or get back to upstream and rejoin the release train. The worst outcome is the current one: implicit ownership with no plan.
A pinned version is a dependency. A patched pinned version is your code. Treat it that way.