Free tool · Open source
How fast does a fork fall behind? — free fork cost estimator for GitHub projects
Pick a project. See its real release and commit pace, dated, and what a fork has to take in every quarter.
Your browser asks GitHub directly; nothing you type is sent to us. A read costs about 7 of the 60 free requests GitHub gives you an hour.
Sample reading · recorded 14 Oct 2026
frappe/erpnext
Recorded from GitHub's public data, so nothing was requested from your browser. Press Read the upstream to read it live, or type or pick another project.
Release line
Branch version-16. Latest release v16.50.0, 8 days ago. One every 4 days, middle value of 52 weeks.
Frappe's support page lists v16 as planned to end at the end of 2029 (read 14 Oct 2026).
Stable releases with a major.minor.patch tag. Commits are what git would bring in on a merge, merges and bots included.
Show
| When | Dates | Releases | Commits |
|---|---|---|---|
| Last 13 weeks15 Jul – 14 Oct | 15 Jul – 14 Oct | 17 | 1,111 |
| 13–26 weeks ago15 Apr – 15 Jul | 15 Apr – 15 Jul | 24 | 1,057 |
| 26–39 weeks ago14 Jan – 15 Apr | 14 Jan – 15 Apr | 27 | 1,419 |
| 39–52 weeks ago15 Oct 2025 – 14 Jan 2026 | 15 Oct 2025 – 14 Jan 2026 | 2 | 1,230 |
A quarter here is 91 days, counted back from 14 Oct 2026. A line's branch can hold commits from before its first stable release, so the oldest quarter of a young line can show many commits and few releases.
Opening the link reads GitHub again, so it spends the free requests of whoever opens it.
Your fork: what a merge brings in
Every step is optional and uses the release line you picked above. The hours are only ever yours.
You set the pace and the hours a merge takes you.
Optional. The hours are only ever yours.
Your merge planOptional
h
Your figure, for a merge of this size. We don't suggest one: it depends on your changes.
4 merges a year. Each brings in about 18 releases and 1,204 commits.
Add your hours for one merge to see the year.
Averages over the last 52 weeks. Merging less often means bigger merges; enter the hours for a merge of that size.
GitHub compares the last releases of the line you picked.
Optional. Uses a few of your free GitHub requests.
What each release changesOptional
Reads the last 6 releases of v16 from GitHub's comparison pages. Costs 6 of your free requests and can download several megabytes.
You paste the files your fork changes; the page says which of them upstream changed too.
Optional. It stays in this tab and is not stored.
Files your fork changesOptional
Paste the output of git diff --name-only <upstream tag>. One path per line, up to 2,000. It stays in this tab and is not stored.
Three ways to need a fork less
Try these first. Each keeps your change out of the project's own files, so upstream releases land without your help.
| Compared on | PickedPut your changes in your own app | Use the hooks the project gives you | Send the change upstream |
|---|---|---|---|
| Frappe and ERPNext | A custom app on the same site. Upstream upgrades leave it alone. | doc_events react to a record. extend_doctype_class adds methods from v16. override_doctype_class swaps a whole class; two apps that override one class can clash. | Frappe Framework takes pull requests only from vouched people; ERPNext's guide has no such note. Outside pull requests on stable branches are closed; fixes go to hotfix branches. |
| Medusa | Your own modules, workflows and API routes. Plugins from v2.3.0 to reuse them. | Workflow hooks, module links, and extra data on core routes. | Maintainers put their own organisation's pull requests first. Outside ones are triaged on no fixed schedule. Ask before a large one. |
| Falls short when | What you need to change has no place to plug in. | No hook reaches the behaviour you want. | It is not accepted, or not soon. Carry a small patch until it lands. |
| Read more |
Picked
Put your changes in your own app
Your code sits beside the project, in its own repository.
- Frappe and ERPNext
- A custom app on the same site. Upstream upgrades leave it alone.
- Medusa
- Your own modules, workflows and API routes. Plugins from v2.3.0 to reuse them.
- Falls short when
- What you need to change has no place to plug in.
- Read more
Use the hooks the project gives you
The project names the places you may change.
- Frappe and ERPNext
- doc_events react to a record. extend_doctype_class adds methods from v16. override_doctype_class swaps a whole class; two apps that override one class can clash.
- Medusa
- Workflow hooks, module links, and extra data on core routes.
- Falls short when
- No hook reaches the behaviour you want.
- Read more
Send the change upstream
Once it is merged, it leaves your list.
- Frappe and ERPNext
- Frappe Framework takes pull requests only from vouched people; ERPNext's guide has no such note. Outside pull requests on stable branches are closed; fixes go to hotfix branches.
- Medusa
- Maintainers put their own organisation's pull requests first. Outside ones are triaged on no fixed schedule. Ask before a large one.
- Falls short when
- It is not accepted, or not soon. Carry a small patch until it lands.
Others who keep forks say the same: the Linux kernel's guide calls out-of-tree code a "false economy"; the BBC on the upkeep of its dash.js fork; rOpenSci on changing fewer files. A different project each time; the point is the same. Read 14 Oct 2026.
What this estimator answers
What keeping a fork of an open-source project would ask of your team each quarter.
Most of the time the answer is not to fork: build what you need as an app on top, and keep taking the project's releases. The page shows the ways to do that next to the numbers.
What it rests on
- GitHub's releases and commitsRead in your browser, with the dates of the window.
- The quarterly loadWorked out from that record and shown with the sum.
A fork is sometimes right. These numbers can't say when.
Five things the numbers cannot tell you, and the three times a fork is still the right call.
- Your hoursThey depend on your changes and your team, so you enter them.
- Which merges conflictThe file list in Look closer is a start; the conflicts show only when you merge.
- A break git does not flagOnly your tests can catch a change that merges cleanly and still breaks.
- Your data and serversDatabase patches and new runtime versions that come with a release. ERPNext v15 vs v16
- The next quarterThe pace above is the past 52 weeks, not a forecast.
A fork is still right when
- Upstream has stopped, or changed its licence or direction. Check the project's health
- You need behaviour no hook reaches, and upstream will not take it.
- You must stay on a version upstream has ended, and you will write its fixes.
Who made this
We implement ERPNext and Medusa for clients and write custom apps and extensions for them. We earn from that work, so we have a reason to prefer it to a fork. Every number here is GitHub's, and the requests are listed under the result. How we stay independent of Frappe
When the answer is a project
When the answer is build on top rather than fork, these are the next steps.
Talk it through before you fork
Bring the project and the change you need; we say how we would build it.
Frappe custom app development
What you need as an app on top, so upgrades keep working.
Our open-source work
What we have sent upstream instead of forking.
Questions people ask
The one most people ask is answered first. Type to find the rest.
Should I fork an open-source project?
Only if no extension point, hook or upstream change can give you what you need. A fork turns every upstream release into your work. Try a custom app, the project's own hooks, or a pull request first; the three cards above say where each falls short. Check the project's health too: if upstream has gone quiet, a fork may be the only road.
Before you fork
There is no single answer. Merging less often means fewer, larger merges and longer without upstream's fixes; merging every release means constant small ones. A 2017 paper on technical lag treats being behind as a price to weigh, not a fault in itself. Pick a pace above and see what each merge brings in.
The one your fork is based on. Frappe and ERPNext keep more than one version shipping at once, each with its own branch and releases. The page opens the newest line with four or more releases in 52 weeks, and you can switch. A line with no release in 13 weeks is marked idle; Frappe's support page says which lines have ended.
Yes. ERPNext runs on the Frappe Framework and pins a range of it in its pyproject.toml file: version-16 asks for Frappe 16.x, and version-15 for 15.x. The lower limit is raised from time to time. A fork of ERPNext is also a bet on a Frappe version, so read both projects and add the numbers.
A count can't say which files collide. A list can: the page checks it against the files upstream changed in the last six releases and names the matches. GitHub shows at most 300 files per comparison, so a big release can hide some, and then the overlap is a minimum. Your list stays in this tab.
The numbers
GitHub's REST API, read from your browser on the date shown. Releases are the project's stable GitHub Releases with a major.minor.patch tag. Commits are counted on the release line's branch in four 91-day windows, merges and bots included, so they measure what git would bring in, not work done. Every request is listed under the result.
Because we would have to invent one. The hours for a merge depend on what you changed, how big the gap is and how well your tests catch breaks. Enter your own hours for one merge and the page multiplies them by a count it read from GitHub. Leave it blank and you still see what each merge has to take in.
One survey does. Linux Foundation Research's 2025 ROI survey, published in February 2026, asked 238 respondents how many hours one private fork takes per release cycle. The report puts the average at 60, but answers ran from under 5 hours to over 160 and 22% did not know. It does not say how long a cycle is, so we use no default.
No. Your browser asks GitHub's public API for the releases and commits, and the page does the sums. The repository name, your hours and any file list stay in this tab and are not stored. We record that a read ran and which kind of result it was, never the repository or what you pasted. GitHub sees your internet address, as on any visit.