Fork

A fork is a copy of a repository, with the full history. GitHub's fork button is one click. A fork is a new repository with its own URL, its own issues, its own stars, and its own user base — starting from zero.

Adoption and forking are different paths. Adoption preserves the original URL: the new maintainer gets commit access to the existing project, the existing user base sees the same README, the same docs, the same issues. The handoff is graceful. A fork starts the new maintainer from scratch: zero stars, zero visibility, the same code but a new URL that no one knows about.

The right path is adoption first, fork as fallback. If the original maintainer is reachable and willing to hand over, the URL stays alive. If they're not, or if there's a licensing conflict, a fork is the right answer. The 2014 io.js fork of Node.js is the canonical example: the maintainers of Node.js were unresponsive, the community forked, io.js thrived for 18 months, and the Node.js Foundation merged the fork back into the official project. The fork was the right move; the merge was the resolution.

A fork on its own is just a copy. A fork that gets adopted, maintained, and built into something new is a second chance.