← All terms

define fork --plain-english

Illustration for "Fork" from the Non-Technical Technical Dictionary

Fork

TLDR:Take someone's open-source project, the code anyone can read and use, and make your own full copy to do whatever you want with, independent of the original.

Take someone's open-source project, the code anyone can read and use, and make your own full copy to do whatever you want with, independent of the original. That copy, and the act of making it, is a fork.

A fork is a complete, independent copy of a project that you own and can change freely, without asking the original owner's permission (the open-source license already grants it). The name is the image: the road splits, the original keeps going one way, your version heads another. From the fork on, they're two separate projects that happen to share a past.

It helps to hold it next to a branch, because they sound similar and aren't. A branch is a temporary side copy within one project, meant to come back home, you branch off, build, then merge back into the main version. A fork is a more permanent split into a separate project, often by a different person entirely, usually with no plan to merge back. Branch: a detour that returns. Fork: a new road that leaves.

People fork for a few honest reasons. Sometimes you want to build on someone's work and take it your own direction, your own features, your own priorities. Sometimes a project gets abandoned and the community forks it to keep it alive. And sometimes people disagree so sharply about where a project should go that it splits in two, both versions continuing under different names. A surprising number of tools you use are forks of something older.

There's also the everyday GitHub meaning, which is gentler. To contribute to someone else's open-source project, the normal move is: fork it (make your own copy), change what you want in your copy, then send the original owner a pull request, "here's an improvement, want to merge it back?" Here the fork isn't a permanent breakup, it's just your personal workspace so you can propose a change without ever touching their live version. Same word, friendlier intent.

Why this matters even if you'll never fork anything yourself: it's a quiet superpower of open source. Nothing good is ever truly stuck. If a tool you depend on gets abandoned, mismanaged, or taken in a direction you hate, the code is right there to be forked and carried on (within the license terms). That escape hatch, "we can always fork it," is a big part of why building on open source feels safe.

A fork is your own full copy of a project, taken in your own direction. A branch comes home. A fork leaves to become its own thing. It's the open-source escape hatch: nothing good ever has to die.