A common rule of thumb is to depend in the direction of stability. What actually makes one dependency target more stable than another, and how much of that stability is a property of your ecosystem's packaging rather than of the code you depend on?

## What stability means here Stability in this sense has nothing to do with correctness or uptime. A unit is stable when it is **hard to change**, and it is hard to change when many things depend on it and it depends on little. The usual formalisation counts edges: with `Ca` incoming dependents and `Ce` outgoing dependencies, instability `I = Ce / (Ca + Ce)` runs from 0 (maximally stable: everyone depends on it, it depends on nobody) to 1 (maximally unstable: depends on everything, nobody depends on it). The guidance follows immediately: point your edges towards lower `I`, and because a stable unit cannot easily change, it should be **abstract** - extendable without modification. A stable concrete unit is the worst quadrant, and a volatile abstract one is pointless. That gives you a good first pass. It also hides the more interesting half of the question. ## Volatility is rate of change times blast radius The metric measures your own graph. What it cannot see is what happens when the target *does* change: how far the change is allowed to travel is decided by your packaging system, and ecosystems answer that very differently for the *same* dependency graph. Consider one shape: your app depends on library A which needs parser 2.x, and on library B which needs parser 1.x. - **npm/Node** resolves by nesting. A gets `parser@2` under its own `node_modules`, the top level keeps `parser@1`, and both load. Nobody is forced to upgrade, so an incompatible release of a transitive dependency is a local event. The cost is the duplicate-instance class of bug: two copies means two module-level caches, two singletons, two sets of constructors, so an identity check on an object made by one copy against the other fails - the familiar "two copies of the framework" symptom. - **Maven/Gradle on the JVM** cannot do this: one fully-qualified class name resolves to one class on the classpath, and the resolver mediates to a single version (nearest-wins in Maven, highest by default in Gradle). So B ends up running against a parser it was never compiled against, and you find out at runtime with a `NoSuchMethodError`. Every transitive library is therefore a *global* commitment shared by the whole graph, which makes the identical dependency edge substantially more volatile than it is under npm. Shading - relocating a library's packages into your own namespace - is the workaround, and it exists precisely because the platform cannot hold two versions. - **Go modules** made this a language-level decision: from v2 onward the major version is part of the import path (`example.com/parser/v2`). Two majors are literally different packages and coexist without ceremony, and the Go 1 compatibility promise makes the standard library about as stable a target as exists. The cost is visible churn in import paths at every major bump. - **Cargo** permits multiple semver-incompatible versions of a crate in one binary, but types from different versions are distinct types. The result is the confusing error where a trait apparently does not match itself, because two versions of the same crate are in the graph - a diagnosis problem rather than a runtime failure. - **.NET** loads one assembly per identity per load context, historically with binding redirects and now with `AssemblyLoadContext` for genuine isolation, which is how plugin hosts run components with conflicting dependencies in one process. So "how volatile is this dependency" is not answerable from the library alone. The same package, with the same release cadence, is a much heavier commitment on a flat classpath than in a nesting resolver. ## Making a target stable on purpose Beyond picking well, you can *manufacture* stability at the edge you own. - **Depend on the narrowest shape.** A consumer-declared interface with two methods changes far less often than a vendor's class with forty. In structurally typed languages this costs nothing; in nominal ones it costs an adapter. - **Own the adapter.** One module in your codebase touches the volatile library; everything else touches your abstraction. Now the blast radius of a breaking upgrade is one file, whatever the packaging system does. - **Prefer targets with an explicit compatibility contract.** A standard library with a written promise, or a crate with a disciplined semver policy, is stable in a way a fast-moving utility library never is regardless of edge counts. - **Watch the direction of abstraction.** Depending on a stable *concrete* type is the trap: it cannot change without breaking everyone, so it does not change, so it accretes special cases instead. That is how shared "common" or "contracts" modules become the least pleasant code in the repository. ## The judgment Count edges to find your unstable units, then ask the packaging question about each external target: if this ships a breaking change tomorrow, how many of my units must move at once? On npm or with Go's versioned import paths, often one. On a flat classpath, potentially all of them. That asymmetry, not the metric, is usually what decides whether an edge needs an adapter in front of it.