So You’re Thinking About Forking | Medplum

Forking can look like the fastest path to control, but it often becomes a long‑term maintenance tax. Here’s a pragmatic checklist to decide—and alternatives that usually win.

TL;DR Forking feels like freedom; more often it is technical debt in disguise. Before you spin up a divergent codebase, walk through the checklist below and consider proven collaboration patterns that deliver 90 % of the control with 10 % of the cost.

The Temptation to Fork ​

Every open‑source maintainer eventually receives the same message: “We love your project, but we need feature X immediately—so we’re considering a fork.” The allure is clear:

Yet the freedom is rarely free.

What a Fork Really Means ​

Hidden Cost Why It Hurts Over Time
Merge fatigue Every upstream security patch, performance fix, or new feature now requires repeated cherry‑picks and conflict resolution.
Security surface Divergent codepaths double the CVE tracking burden and slow incident response.
Community isolation Third‑party plugins, docs, and Stack Overflow answers increasingly apply to the mainline, not your fork.
Talent attraction Engineers prefer contributing to widely‑used projects; recruiting for a niche fork is tougher.

At Medplum, we have seen partners launch forks with convinced leadership support—only to merge back within months after realising the hidden cost curve.

When a Fork Is Justified ​

There are legitimate scenarios:

  1. Project abandonment No active maintainers, unmerged PRs, stale security issues.
  2. License retreat Upstream changes from permissive to restrictive terms.
  3. Irreconcilable governance clash The core team rejects a domain‑specific regulatory requirement that your business legally must meet.

If none of the above apply, pause before you type git clone.

Alternatives That Usually Win ​

Contribute Upstream ​

Large features land faster than you think when paired with a well‑structured proposal, passing tests, and open communication. For context, Medplum has merged >1 000 community PRs, including entire modules such as the upcoming Kafka subscription channel.

Maintain a Thin Extension Layer ​

Build your business logic in a backend‑for‑frontend (BFF) or dedicated microservice, leaving the core FHIR server untouched. You keep velocity while upstream remains a drop‑in upgrade.

Sponsor Roadmap Work ​

If a feature is strategic but non‑differentiating—think sharding, compliance, or new spec versions—directly funding upstream development is often faster and cheaper than hiring a fork team.

Case Study: Four Years of Medplum Evolution ​

A downstream fork would have needed to replicate every one of these changes—or risk falling behind on performance and compliance.

A 30‑Minute Fork Decision Checklist ​

  1. List blockers Write down the features or constraints driving the fork discussion.
  2. Search the tracker Is someone already working on your need? Comment and collaborate.
  3. Draft a proposal PR Even a work‑in‑progress branch sparks upstream feedback.
  4. Estimate ownership cost How many engineer‑months per year will merges, CI, and CVE triage consume? Multiply by three.
  5. Schedule an architecture chat Most maintainers (Medplum included) are happy to roadmap with partners—often unlocking an upstream path.

Conclusion & Next Steps ​

Forking should be the exception, not the default. The open‑source ecosystem thrives when contributors pull in the same direction, sharing maintenance and innovation. Before you commit to life on a fork:

Our door is always open. If you’re weighing a fork—or just need architectural advice—reach out in the Medplum Slack, book office hours, or send us a pull request.

Move fast—but merge faster.