buildontopnotover.org  /  worth building  /  open source

Build on top,
not over.

Contribute upstream before you fork. Extend before you replace.

deposition  work that adds a layer truncation  work that removes one

Stratum I  ·  surface

Everything you type today lands on something.

There is no empty ground in software. The editor you opened, the parser it leans on, the compression format underneath that, the sort that somebody got right in 1962: you are standing on a column of other people's decisions that runs deeper than anyone has ever read.

The only real question is what you do when you reach a layer that does not fit. You can add to it, or you can cut through it. Those look similar on the day. They are not remotely the same thing five years out.

Stratum II  ·  deposition

Adding is slow because it has to survive contact with strangers.

An upstream patch is an argument you have to win in public. Someone who has held the thing for eight years asks why. You defend the interface, you learn about the four users you did not know existed, you write the test for the case you would have shipped broken. It takes three weeks instead of an afternoon.

That friction is not overhead. That friction is the product. What you get at the end is not just your feature. It is your feature with the maintainer's knowledge compiled into it, carried forward by people who are not you, in a release you do not have to cut.

The measure of a contribution is not what it does on merge day. It is whether it is still working after you have stopped paying attention to it.

Stratum III  ·  truncation

The fork feels like speed. It is a bill on a delay.

On the day, a fork is the fastest thing in the world. No review, no negotiation, no waiting on someone in a timezone you keep forgetting. The change lands in an hour and it does exactly what you meant.

What you actually bought is every future fix, forever. Upstream keeps moving: their security patch, their protocol update, their performance work, all landing in a shape that no longer matches yours. Each one now arrives as a merge conflict addressed to you personally. The gap widens on its own, without anybody deciding to widen it, and one morning it is wide enough that catching up is a bigger job than the fork ever was.

Meanwhile the reason you forked, that one real problem, is still unsolved for everyone else who will hit it. They will each fork too. The commons gets a little thinner, quietly, and nobody sends an invoice for it.

A fork does not remove the maintenance. It moves it onto you and hides it in a place where nobody is counting.

Stratum IV  ·  procedure

Work the ladder down. Stop at the first rung that holds.

Nobody is arguing that forks are never right. The argument is that most forks happen at step one, when the answer was sitting at step two, and the only thing missing was the patience to check.

  1. 01 Read it properly. The behaviour you want is often already there, behind a flag, a hook, or a paragraph of documentation nobody scrolled to.
  2. 02 Ask in the open. An issue costs you ten minutes and frequently returns a maintainer explaining why your approach breaks in a case you had not imagined. That answer is worth more than the patch.
  3. 03 Extend from outside. A plugin, an adapter, a wrapper, a subclass. If the project gives you a seam, use the seam. It is a promise about compatibility that a fork cannot make.
  4. 04 Send the patch upstream. Small, tested, documented, one idea at a time. Written so that someone who has never met you can say yes without a meeting.
  5. 05 Carry a local patch, in the open. If upstream is slow, run your change as a visible diff on top, not a private rewrite underneath. Keep the pull request open. Rebase it. Stay a version of the same thing.
  6. 06 Fork, and say why. Sometimes the direction genuinely diverges, or the project is abandoned, or governance failed. Then fork honestly: publish the reason, credit the lineage, and take on the maintenance out loud.
Stratum V  ·  bedrock

Deep layers are the ones nobody is thanked for.

The further down the column you go, the more load a layer carries and the fewer people can name it. Whole industries rest on libraries maintained by one person in the evenings, and the first sign of trouble is usually that something stopped, not that anyone asked.

Building on top is how you pay into that, whether or not you meant to. Every upstream patch is a small transfer of effort from the people who benefit to the layer that holds them up. Every avoidable fork is the same transfer running the other way.

This is not generosity and it does not need to be. It is the only arrangement where the ground under your own work keeps getting stronger while you are busy doing something else.

Adding takes longer and compounds.
Cutting is quicker and erodes.
Almost every day, that is the whole decision.

A claim held in the open, kept here while it earns a fuller form.