For most of open source history, forking was considered a failure mode. "Don't fork" was accepted wisdom: it splits communities, duplicates effort, and creates maintenance burden. Forking was something you did when communication with upstream had completely collapsed, and even then reluctantly. Linus Torvalds famously called forks "a tragedy" in multiple interviews.
That consensus has fractured. Between 2023 and 2024, the Linux Foundation alone incubated three high-profile "reactive" forks: OpenTofu (forked from Terraform in September 2023), Valkey (forked from Redis in March 2024), and OpenSearch, which had already been donated to the foundation in September 2024 after a longer history of standalone operation. Each fork emerged in response to a license change by the upstream vendor. Each now has substantial commercial backing and a growing independent contributor base.
At the same time, enterprises have quietly been running internal forks of critical dependencies for decades. Google's internal forks of countless open source projects are a well-documented engineering reality. Facebook's Phabricator fork outlived Phacility itself. Financial institutions run internal forks of OpenJDK with backported security fixes. The practice is normal. The doctrine around it is finally catching up.
The Three Forks You Might Need
Enterprise forking falls into three patterns that require very different playbooks.
A soft fork is an internal mirror with minor patches. You clone upstream, apply your own patches, build your own artifacts, and periodically rebase onto new upstream releases. This is what most regulated enterprises do with their JVM: they run their own OpenJDK build with extra security patches and compliance flags. The maintenance burden is real but bounded.
A hard fork is a public, independent continuation of a project. OpenTofu, Valkey, and OpenSearch are hard forks. They have their own governance, their own release cadence, their own CVE numbering in some cases, and an explicit intent to diverge over time. Hard forks require sustained investment and are almost always backed by multiple organizations.
A rescue fork is taken over an abandoned or sabotaged project. When event-stream was compromised in November 2018, the npm community effectively rescue-forked by pointing users at alternatives and removing the compromised versions. When colors.js was sabotaged in January 2022, downstream projects scrambled to pin to clean versions or replace the dependency. Rescue forks are reactive and usually small-scope.
The decision to fork, and what kind of fork to pursue, should be made deliberately. The worst outcome is an accidental fork: a team that intended a temporary patch finds themselves five years later maintaining a de facto hard fork without ever having made the organizational commitment.
The Trigger Conditions
Three categories of events have historically triggered enterprise forks.
License change. HashiCorp's August 2023 move from MPL 2.0 to BSL 1.1 triggered OpenTofu. Redis Ltd.'s March 2024 move from BSD to dual SSPL/RSAL triggered Valkey. Elastic's January 2021 move from Apache 2.0 to SSPL/ELv2 triggered OpenSearch (via AWS, with Linux Foundation stewardship coming later). In each case, the fork was launched within weeks of the license change because enterprises needed a license-stable alternative.
Governance collapse. When a project's governance fails, either because a sole maintainer goes dark, because a hostile actor is granted rights, or because corporate sponsor decisions override community consensus, forking can be a legitimate response. The 2020 ReactiveX.NET controversy, where governance disputes led to a fork, is an example. Node.js itself emerged from the io.js fork in 2014, motivated by governance concerns with the Joyent-era io.js predecessor (and the forks ultimately merged back with a reformed governance model).
Stalled maintenance. Projects that simply stop receiving updates, especially security updates, can justify a rescue or continuation fork. The Log4j 1.x community fork efforts, while never achieving broad uptake, emerged from this motivation. OpenSSL 3.0's API shifts led some downstream users to fork older branches to maintain compatibility.
The Mechanics of a Hard Fork
OpenTofu's launch playbook has become something of a reference pattern. Within weeks of HashiCorp's August 2023 announcement, a coalition of Harness, Spacelift, env0, Gruntwork, and others published a manifesto. Within a month they had organized under the Linux Foundation and secured an initial maintainer pool. By September 20, 2023 the project was officially announced. The 1.6.0 release shipped in January 2024.
The essential components were: multiple corporate backers (no single vendor can credibly sustain a fork), a neutral foundation home (Linux Foundation, Apache, or CNCF all work), a rename to avoid trademark conflicts, a governance document before the first release, and a public divergence strategy that explained how OpenTofu would differ from Terraform over time.
Valkey's March 2024 launch followed essentially the same pattern, with AWS, Google Cloud, Oracle, Ericsson, and Snap providing initial backing, Linux Foundation stewardship, a rebrand, and a clear statement of intent. By the end of 2024, Valkey had made its first divergent release with features upstream Redis did not have.
The Mechanics of a Soft Fork
Internal forks are less dramatic but more common. The discipline required is different. You need a clear upstream tracking strategy (which branch do you track, and when do you rebase?), a patch-management workflow (how do you apply your internal patches to each new upstream release?), a CVE-backporting process (when upstream issues a fix, how do you apply it to your fork?), and an exit strategy (at what point do you either upstream your patches or abandon the fork?).
Financial services firms have been running soft forks of OpenJDK (through vendors like Azul, BellSoft, or their own build pipelines) for over a decade. The practice is sometimes called "distro-forking," and the tooling ecosystem, including tools like rpm-ostree, Copr, and Yocto layers, supports it well.
For SBOM and compliance purposes, soft forks need careful metadata. A PURL that says "log4j 2.17.0" is ambiguous if you have actually shipped "log4j 2.17.0 plus three internal patches." Tooling needs to understand "my internal fork" as a distinct identity.
The Durability Question
Forks fail more often than they succeed. The io.js fork of Node.js succeeded only because the communities merged back with reformed governance. The LibreOffice fork of OpenOffice succeeded, but only after Oracle donated OpenOffice to Apache, where it languished. MariaDB's fork of MySQL has lasted, but its commercial trajectory has diverged substantially from its original vision.
Durability requires three things: a sustained multi-vendor backing (to avoid single-sponsor capture risk on the fork itself), a clear statement of why the fork exists that survives the moment of its creation, and an ability to attract contributors who were not part of the original drama. Forks that remain purely reactive rarely last. Forks that develop their own identity and roadmap usually do.
How Safeguard Helps
Safeguard treats forks as first-class citizens in dependency tracking, so your internal soft forks and hard-fork migrations (Terraform to OpenTofu, Redis to Valkey, Elasticsearch to OpenSearch) are represented accurately in SBOMs and risk reports rather than collapsed into ambiguous upstream identifiers. Our policy engine lets you require specific fork lineages for regulated workloads, block unsanctioned internal forks, and track divergence from upstream CVE coverage. When a security fix lands in upstream that has not yet been backported to your fork, Safeguard surfaces the gap before it becomes an audit finding. That turns forking from an improvisation into a governed engineering practice.