Why I contribute upstream instead of maintaining forks

When a library doesn't do what I need, the fork is tempting: I control it, I can change anything today, no review, no waiting. I've done it. It felt powerful for about two months, and then it started rotting.

The fork's hidden invoice

Every fork is a private copy of a moving target. Upstream fixes security issues; my fork doesn't get them automatically. Upstream improves the API; my fork diverges. The moment I need an upstream improvement, I'm doing a painful merge — of code I half-remember, in a project that's no longer theirs and was never really mine.

The upstream alternative

Slower and smarter: open an issue describing the gap, submit the patch, wait for review. Sometimes the answer is no — and then I've learned whether I truly need the fork. But when the patch merges, the maintenance belongs to the project, the improvement ships to every user, and my name sits in the changelog forever.

My decision rule

• change useful to others → upstream, always try first
• change niche or contrarian to the project's direction → local patch, clearly marked, with an issue explaining it upstream anyway
• fork → last resort, with a written exit plan, because forks are how you adopt someone else's maintenance burden in disguise

Upstream contribution is slower today and free tomorrow. The fork is the opposite.