Dependency Is Not the Enemy. Having No Exit Is.

The bakery is a dependency. So is the compiler. So is the person who knows how to service the boiler. We rarely describe them that way when they work well. We describe them as conveniences, relationships, or parts of a functioning town.

Dependencies let us do things we could not do alone. They concentrate expertise, share costs, and make complicated capabilities available to ordinary people. A world in which everyone had to rebuild every tool would be poorer in almost every sense.

The useful distinction is not between dependence and independence. It is between a relationship we can reconsider and one we cannot meaningfully leave.

When a good bargain changes

A service can begin as an excellent choice and become a difficult dependency without any single dramatic event. Over time, your files accumulate there. Colleagues adopt its vocabulary. Workflows develop around its peculiarities. You stop keeping another way of doing the work.

Then a price changes, a feature disappears, or your circumstances shift. The cost of leaving is no longer the price of a competing product. It includes migration, retraining, broken links, lost context, and the risk of discovering halfway through that some essential detail cannot be moved.

This is why an attractive price is not a complete description of a dependency. The cost of entering and the cost of leaving are separate properties. A service can be inexpensive to use and very expensive to replace.

There is nothing irrational about accepting those costs. A specialised tool may be valuable enough to justify them. The problem is accepting them accidentally, while believing that the mere existence of alternatives means you can switch.

An exit has several parts

An exit starts with access to the things that matter. Can you retrieve the original files, not just screenshots or flattened reports? Do relationships, dates, annotations, and identifiers survive? Can you read the export without asking the same provider for permission?

But data is only one part. You also need a place to go and a way to continue the activity. A folder of messages may preserve a record without preserving a working communication channel. An export of a project board may retain text while losing the decisions encoded in links and history.

Finally, the exit must fit your circumstances. A theoretically possible migration that requires three uninterrupted weeks is not a useful option during a busy period. A replacement that only one person knows how to operate may exchange one kind of fragility for another.

An alternative becomes an option when you can actually use it.

The practical test is modest: move a small, representative piece of work. Include something awkward. Open the result. Try to do an ordinary task. You will learn more from this than from a feature comparison.

Friction is not always captivity

Some switching costs are inherent in learning anything worthwhile. Moving from one instrument to another takes practice. Leaving a community changes relationships. Replacing a carefully configured tool takes time even when every format is open.

It helps to distinguish this ordinary friction from avoidable captivity. A readable file format cannot remove the effort of learning a new editor. It can prevent that effort from also requiring the reconstruction of your work. Good documentation cannot eliminate every dependency on a specialist. It can keep essential knowledge from vanishing when the specialist leaves.

Look for arrangements in which your investment accumulates in something you retain: knowledge, transferable skills, ordinary files, understandable equipment, and relationships that are not mediated by one irreplaceable gatekeeper.

date: 2026-09-15
service: github
object: one private repo with LFS, issues, wiki
method: git clone --mirror + gh api for issues
result: refs and blobs restored on Forgejo; issue numbers remapped; Actions
        workflows need a runner; wiki as git repo survived; LFS needed a
        separate fetch
time: 40 minutes plus one failed LFS pointer

Keep the bridge usable

An exit plan decays. Export formats change. Recovery addresses become obsolete. The alternative tool stops being maintained. The person who understood the process moves away.

This does not mean every possible failure needs a standing duplicate system. Maintaining two complete versions of everything can consume more time than it saves. Often a periodic rehearsal is enough: export a sample, restore a copy, make a call using another channel, or ask a second person to follow the instructions.

The frequency should follow the cost of being wrong. A working archive of irreplaceable documents deserves more attention than an abandoned hobby account. The object is to preserve a credible route, not to stage a permanent evacuation.

A small dependency notebook

For a service that matters, write a few sentences under four headings: what it provides, what you would lose, where you could go, and what you have actually tested. Resist the urge to turn this into an inventory of everything you own.

The final heading is the important one. “Exports supported” is a claim about the service. “Opened last month’s export in another application; attachments present, comments missing” is knowledge about your situation.

That missing-comments detail may be acceptable. It may also reveal that the comments contain the reasoning behind the work and deserve a separate record. Either way, you can now decide deliberately.

Good dependencies are worth keeping. They save effort, deepen expertise, and connect us to other people. Keeping an exit does not express hostility toward them. It lets us continue choosing them with confidence, because staying remains a decision.