# What is a fork, and what is a pull request?

- Link: https://opensourcecad.nl/en/what-is-a-fork-and-what-is-a-pull-request/
- Published: 2026-10-22T21:41:34+02:00
- Author: Marijn van den Heuvel \+ AI

_This is the English reading version of the Dutch news item [Wat is een fork, en wat is een pull request?](https://opensourcecad.nl/vibecoded-apps/wat-is-een-fork-en-wat-is-een-pull-request/)._

Two words keep coming back in reports about open-source CAD: fork and pull request.
This is what they mean.

## A fork

The code of an open-source CAD program sits in a repository, with its whole history
attached. A fork is your own copy of that code, and it stays linked to the original
repository. You may change anything in it without the original noticing, and you
need nobody’s permission to do so.

Because that link stays in place, you can go two ways: improvements made in the 
original you can pull into your copy, and your changes you can send back. That pulling
only happens when you ask for it, and only when there are no conflicts with the 
source code. If there are, you have to resolve them yourself first. In open source,
forking is the normal way of working: whoever wants to change something and does
not want to wait starts a copy.

## A pull request

A pull request, PR for short, is a proposal to change a project’s source code. You
explain what you changed, the maintainers look at it, and only when someone approves
it does your change get merged in. That merging is called a merge.

It is a request, not an order. That is in the name: you are asking the owner to 
take your work in. Nothing may happen with it either, and that happens often.

## Pros and cons of a fork

 * You can start straight away, without asking permission and without standing in
   a queue.
 * You have complete freedom over what you change.
 * But you keep a second copy of the code with it, which you have to maintain yourself.
 * If the two drift too far apart, merging later stops working.

## Pros and cons of a pull request

 * Your work ends up in the real program, where everyone uses it.
 * Others review it along the way, and that improves the quality.
 * You do not have to maintain a second version of the code.
 * But your proposal has to be kept up to date against the changes in the code. 
   If it falls too far behind, your change stops working.
 * And it can take a long time or never happen at all, because it depends on someone
   else.

## Why you notice it

Two CAD programs that look alike often share the same origin. And it explains why
a program sometimes feels the same for years: an improvement is not a switch you
flip, but a proposal that has to be reviewed and approved. If it is at the back 
of the queue, it takes time.

The explanation of forking is in [GitHub’s documentation](https://docs.github.com/en/pull-requests/how-tos/work-with-forks/fork-a-repo),
as is the one on [pull requests](https://docs.github.com/en/pull-requests/reference/pull-requests).