Asher Cohen
Back to posts

Open Source After Dependencies (Part IV): Package Managers, Governance, and a Realistic Migration Path

Tradeoffs are hidden in the details

After three articles, the remaining questions are no longer philosophical. They’re practical.

If this model is even partially correct, then three things need to be addressed explicitly:

  1. How does this compare to existing package managers?

  2. How do shared specs avoid becoming a new bottleneck?

  3. What does this look like when applied to a real codebase, not a greenfield thought experiment?

This article tackles those three, without pretending there’s a clean or universal answer.

1. Package Managers: What They Actually Optimized For

Package managers solved a very specific historical problem:

“How do we share code efficiently when copying is expensive?”

npm, cargo, pip, and others optimized for:

  • distribution

  • versioning

  • reuse

  • transitive composition

They were wildly successful.

But they also encoded assumptions that are now questionable:

  • reuse is always better than regeneration

  • abstraction cost is lower than understanding cost

  • popularity is a reasonable proxy for quality

LLMs invert those assumptions.

When copying becomes effectively free, the bottleneck moves from distribution to decision-making. Package managers still excel at moving bits around. They do not help you understand:

  • why this abstraction exists

  • which tradeoffs it made

  • what you inherit by using it

In that sense, intent-driven generation is not a replacement for package managers. It is a response to a different scarcity.

You can still ship binaries, frameworks, and libraries. But they stop being the default unit of reuse.

2. Shared Specs Without Centralization

A natural fear emerges here:

“If we share specs instead of code, won’t specs become the new chokepoint?”

They could—if designed like packages.

The difference is that specs are constraints, not assets.

A capability spec should contain:

  • interface definitions

  • invariants

  • test cases

  • benchmark harnesses

  • explicit non-goals

What it must not contain:

  • reference implementations

  • opinionated defaults

  • hidden performance assumptions

Governance then shifts from:

“Who controls the repo?”

to:

“Who can propose a new constraint or test?”

That’s a lower bar—and a healthier one.

Forking a spec is cheaper than forking an ecosystem, because:

  • consumers already vendor implementations

  • compatibility is enforced by tests, not social pressure

  • divergence is explicit, not accidental

Specs can fragment without breaking users. Packages cannot.

3. Governance Through Tests, Not Authority

Traditional open source governance relies on:

  • maintainers

  • commit rights

  • release gates

This model relies on:

  • shared test suites

  • benchmark comparability

  • transparent constraints

Disagreements don’t require consensus. They require measurement.

If someone believes:

“This HTTP server design is fundamentally better”

They encode that belief as:

  • a new benchmark

  • a new failure scenario

  • a new constraint

Others can adopt it—or not.

Governance becomes additive instead of adversarial.

4. A Real Codebase: Migrating Without Burning It Down

Let’s make this concrete.

Assume an existing production service:

  • Node.js

  • Express or Fastify

  • ~30 direct dependencies

  • ~300 transitive ones

  • stable, but brittle

A realistic migration does not start with:

“Let’s replace everything.”

It starts with one dependency class.

Step 1: Identify High-Churn, Low-Value Dependencies

Good candidates:

  • small utilities

  • HTTP middleware

  • serialization helpers

  • simple UI components

  • build-time tooling

Bad candidates:

  • databases

  • ORMs

  • distributed systems

The goal is to reduce cognitive load, not prove purity.

Step 2: Replace One Dependency With an Intent

Example:

capability: request-logger constraints: structured: true overhead_ms: <1 no_external_io: true

Generate, vendor, test.

Nothing else changes.

No new infrastructure. No platform commitment. Rollback is trivial.

Step 3: Compare Outcomes, Not Ideology

After a few replacements, compare:

  • dependency count

  • onboarding time

  • incident debugging

  • upgrade anxiety

  • code comprehension

If none of these improve, stop.

This model only earns its place if it reduces real pain.

What This Looks Like After 6–12 Months

If applied conservatively, a mature codebase might end up with:

  • fewer dependencies

  • more local code

  • clearer ownership boundaries

  • fewer “drive-by” upgrades

  • more explicit tradeoffs

Not revolutionary. Just calmer.

That’s important.

What This Does Not Do

It does not:

  • eliminate libraries

  • kill frameworks

  • replace ecosystems

  • solve funding

It changes the default answer to:

“Should we depend on this?”

From “probably” to “why?”

That alone is a meaningful shift.

The Uncomfortable Comparison

Package managers optimized for sharing artifacts. This model optimizes for sharing understanding.

Both are valuable. Only one scales with LLMs.

We don’t need to burn the old world down. But we do need a place for the new one to exist without pretending it fits the same rules.

Closing Thought

If open source survives the LLM era, it won’t be because we protected packages.

It will be because we protected:

  • ideas

  • constraints

  • measurements

  • the freedom to explore design spaces without permission

Everything else is implementation detail.

#opensource #llm #ai #software #engineering