# The Hard-Fork Outcome Read: Displace, Split the Market, or Fizzle

*Score any hard fork 30 to 365 days old on six public-evidence dimensions and call Displace, Split, or Fizzle with a confidence level and a dated re-check.*

- Canonical URL: https://www.refolk.ai/guides/hard-fork-outcome-read
- Pillar: Market and talent intelligence
- Format: Framework
- Published: 2026-10-20
- Last reviewed: 2026-10-20
- Reading time: 22 min
- Keywords: will the open source fork succeed, how to evaluate a hard fork after a license change, fork vs upstream adoption comparison, measure fork momentum maintainers and contributors, open source relicensing impact on market share

## Key takeaways

- Backer breadth decides a fork more reliably than founder defection: Freenginx got the developer credited with about 99% of current development and stayed small, while Valkey, backed by roughly 50 contributing companies at one year, took the distros and clouds.
- When Redis relicensed, every external company contributor with more than five commits stopped committing to Redis within six months, so the upstream's employer diversity collapses rather than thinning gradually.
- Packaging is the strongest Displace signal, but it often reflects upstream license incompatibility: Fedora, which does not allow SSPL, approved replacing Redis with Valkey roughly 70 days after the fork.
- Relicensing back has come late and has not reversed a fork: Elastic added AGPL about 40 months after the OpenSearch fork and Redis about 13 months after Valkey, and Valkey still averaged 80 PRs a month against Redis's 42 that year.
- In Refolk's index there is about 1 US profile listing Valkey for every 800 listing Redis, so talent footprint lags code and packaging by a wide margin and should be read as a lagging cross-check, not a leading signal.
- The single Percona survey of 151 respondents supports anything from 7% to about 76% Valkey adoption depending on framing, so only the 'currently using' row belongs in a fork read.

This is a scoring model for making an early call on a hard fork. When a license change or a governance fight splits a project your market depends on, it tells you whether the fork will displace the upstream, split the market, or fizzle. It is written for strategy teams, talent-intelligence analysts, and operators who owe leadership a verdict on a fork between 30 and 365 days old. You get six public-evidence dimensions, a 0 to 2 score for each, verdict rules calibrated against documented forks that went both ways, and a format for a dated re-check.

A **hard fork** is a copy of a project's code that carries on under separate maintainers, a separate name, and separate governance, with no plan to merge back. The **upstream** is the original project it was copied from.

## What does a Displace, Split, or Fizzle verdict mean?

The verdict states where the market will get the software in a year's time. With Displace, the fork becomes the default in distributions and managed services. With Split, both lines keep real backing and real users. With Fizzle, the fork keeps going but stays small. Each verdict changes what leadership should do: migrate, support both, or ignore.

- **Displace.** Distributions and cloud managed services ship the fork where they used to ship the upstream. Valkey is the reference case. Fedora 41 and Enterprise Linux 10 replaced Redis with Valkey, Arch moved Redis out of its official repository, and AWS launched Valkey 8.0 on ElastiCache.
- **Split.** The fork has enough paid backing and neutral governance to last, but it has not taken over the default channels, and the upstream still has a funded core of its own. None of the cases I calibrate against has a published Split label. It is the verdict for durable forks that have not yet won the distribution layer.
- **Fizzle.** The fork is alive but marginal. Two scorecard entries show it: The Butthurt Fork, a public scorecard of forks, lists Redict (Drew DeVault's LGPL fork of Redis, announced 2024-03-22) as Niche, and Freenginx as Active but small.

### Why the window is 30 to 365 days

A fork younger than 30 days has almost no commit history to attribute. The earliest packaging event I can document came about 70 days in (Fedora's approval of Valkey). By about day 370, Valkey had distro switches and a managed-service GA, and Arch had moved Redis to the AUR. A read inside this window is a forecast. After it, you are writing history.

### What the read deliberately ignores

Stars. Fork coverage quotes them all the time, but none of the case evidence links star counts to the outcome. Launch-month excitement is the noise this framework is built to filter out.

## The six dimensions: what each proves and how it lies

Score each dimension 0, 1, or 2 from public evidence. Each one proves something specific about the fork's chance of survival, and each has a known way of misleading you. The rubric below gives the anchors, and the subsections explain what a score actually tells you.

| Dimension | 0 | 1 | 2 |
|---|---|---|---|
| D1 Maintainer defection | Upstream core stays | Some top committers move | External company contributors leave upstream |
| D2 Backer breadth | Elephant factor 1 | One dominant backer plus others | Elephant factor 2+, many employers |
| D3 Packaging | Nothing ships it | Proposals or one channel | Major distro ships it and/or cloud GA |
| D4 Compatibility and divergence | Incompatible or stalled | Compatible, slower cadence | Drop-in compatible, cadence at or above upstream |
| D5 Governance and trademark | Personal or single-company home | Foundation move announced | Neutral foundation holds project and name |
| D6 Upstream counter-moves | Counter-move and fork cadence fell | Counter-move, cadence holding | None, or came after fork was entrenched |

The cutoffs are my calibration from a small set of documented cases. They are not fitted statistically, and no cross-case study of fork outcomes has been published that would let anyone fit them.

### D1 Maintainer defection share

**Defection share** is the proportion of the upstream's trailing-year committers who stopped committing upstream, or moved their work to the fork, after day 0.

- **What it proves:** whether the people who know the code are still working upstream. In the four months before the Valkey fork, 24 people contributed to Redis. The following year, 9 of them (37.5%) committed nothing to Redis, 2 committed less, and 13 committed more. CHAOSS found that every external contributor from a company with more than five commits, including people from Amazon, Alibaba, Tencent, Huawei, and Ericsson, had stopped within six months.
- **How it lies:** a single person can defect. A Hacker News commenter (not a primary source) put Freenginx's founder and one colleague at "basically 99% of current development". Defection doesn't get much higher than that, and the fork still stayed small.
- **Thin evidence:** Redis is the only case where top-committer defection is documented. Compute it yourself every time.

### D2 Backer breadth, measured by elephant factor

**Elephant factor** is the CHAOSS metric for the smallest number of organizations whose people together account for half of a project's contributions. A score of 1 means one employer, or one person, carries the project.

- **What it proves:** whether the fork's survival depends on a single payroll. Valkey had over 20 contributing companies within its first few months and nearly 50 at one year. OpenTofu's backers pledged at least five years of support and nineteen full-time developers between them.
- **What happens to the upstream:** contribution drops to zero rather than halving. Once the upstream sits behind a company CLA and a restrictive license, outside employers have no reason to contribute, and its elephant factor collapses to 1.
- **How it lies:** unattributed commits look like independence. In RedMonk's year-two count, gmail addresses were the largest single group of committers on both Valkey and Redis. If those go uncleaned, the "independent" share grows and the elephant factor reads higher than it really is. Breadth also sits alongside dominance: RedMonk counted 30 Amazon contributors on Valkey. Nobody has published an elephant factor at exactly day 90 or day 365 for any fork.

### D3 Distro and managed-service packaging

- **What it proves:** that the fork has reached the channels most users actually install from. This is the strongest Displace signal available.
- **How it lies:** distro license policy works on its own schedule. Fedora does not allow SSPL, so it had to move whatever the market thought. A packaging date measures how incompatible the upstream license is as much as how good the fork is. Proposals also get counted as if they had shipped. The Fedora change was held back two weeks while compat packaging was finished.

### D4 Compatibility and divergence rate

**Divergence rate** is how quickly the fork's code moves away from the upstream, measured through PR and release cadence and through whether a compatibility shim is still possible.

- **What it proves:** compatibility makes switching cheap, and cadence shows the fork is more than a frozen copy. Valkey forked from Redis 7.2.4, Fedora 41 shipped it as valkey-compat, and Valkey averaged 80 PRs a month in 2025 against Redis's 42.
- **How it lies:** activity counts depend on what is being counted. RedMonk reports that the gap in active contributors between Valkey and Redis is usually in single digits, which is much narrower than the PR gap suggests.
- **Thin evidence:** no published measure compares divergence across forks. Treat D4 as a supporting score, not a deciding one.

### D5 Governance home and trademark position

- **What it proves:** whether employers can contribute without handing value to a competitor. Valkey sits in the Linux Foundation. OpenTofu was accepted to the CNCF Sandbox on April 23, 2025. OpenSearch got its own foundation on September 16, 2024, with SAP and Uber as premier members. On the other side, Redis Ltd. owns the Redis trademark and requires a contributor license agreement.
- **How it lies:** an announced intent to join a foundation is not the same as an accepted project. Score 1 until a foundation has actually taken the project and the name.

### D6 Upstream counter-moves

A **counter-move** is anything the upstream does to win back users or contributors. Relicensing back to an open license and rehiring key people are the two documented ones.

- **What it proves:** whether the fork's reason to exist still holds. Redis credited the November 2024 return of its original creator, antirez, when it explained the AGPL decision. Redis 8 is now tri-licensed RSALv2, SSPLv1, and AGPLv3.
- **How it lies:** a relicense reads as a win for the upstream, and the cases show it is not a reversal. This dimension is scored inverted: 2 means no counter-move has worked.

> **Rule:** Score backer breadth before defection
>
> If D2 is 0, the verdict is Fizzle, whatever D1 says. Defection without a second payroll is a one-person project, and the Freenginx case shows how that ends.

## Calibration: what separated the forks that took over

Across the documented cases, the forks that won had several paying employers and a neutral foundation before the upstream made any counter-move. The forks that faded had a famous founder or a principled license, but no breadth. Timing shows the pattern most clearly, so start with the day counts.

| Fork | Event | Days after fork |
|---|---|---|
| Valkey | Fedora FESCo approval (date inferred, verify) | ~70 |
| Valkey | ElastiCache Valkey 8.0 | ~220 to 245 |
| Valkey | Arch moves Redis to AUR | ~370 |
| Valkey | Redis adds AGPL | ~399 |
| OpenSearch | Elastic adds AGPL | ~1,230 |

The day counts are calculated from public announcement dates. For OpenSearch, the fork date is taken as April 2021. The Fedora date is inferred from the age of the article that reported it, so check it against the Fedora change page before you cite it.

#### The Valkey sequence, license change to relicense-back

1. **License change** - Redis changes its license on March 20, 2024
2. **Fork** - Valkey forks from Redis 7.2.4 and is announced 8 days later
3. **Distro switch** - Fedora approves at about day 70, Fedora 41 ships valkey-compat
4. **Managed service** - AWS launches Valkey 8.0 on ElastiCache at about day 220 to 245
5. **Counter-move** - Redis adds AGPL at about day 399, Valkey still out-ships it on PRs

*Valkey had distro packaging and a managed-service launch in place before Redis relicensed, which is why the relicense slowed the fork rather than reversing it.*

### Three patterns the cases support

1. **Backer payroll beat founder charisma.** Valkey had AWS with 30 measured contributors, plus dozens of other companies, and it moved toward Displace. Freenginx had the most active core developer and stayed small. In the Valkey case, the distros' packaging decisions came after contributors had moved and a foundation had taken the project on.
2. **Relicensing back comes late.** Elastic took about 40 months and Redis about 13. By the time each acted, the fork already had foundation governance. OpenSearch's foundation launched 18 days after Elastic's AGPL change. So the relicense removed the licensing argument but left the fork's ownership structure untouched.
3. **Momentum figures need their count type.** Valkey grew from 18 to 49 contributors in 18 months, which is a monthly-active count. A maintainer's one-year summary of "1,000 commits, 150 contributors, 5M+ Docker pulls and 13 releases" is cumulative. OpenTofu shows the same split: 71 active contributors in January 2024, then a later report of 163 companies and 791 individual contributors. Compare like with like, or the fork vs upstream adoption comparison falls apart.

### What I could not calibrate

I found no packaging dates for OpenTofu or OpenSearch, and no verified contributor figures for OpenBao, LibreOffice, MariaDB, or io.js. No one has published how fork activity changed in the two quarters after an upstream relicensed. If the fork in front of you looks like one of those cases, your confidence should be lower to match.

## Talent footprint: the lagging cross-check

Talent footprint is how many working professionals list the fork as a skill and where they work. It shows whether adoption has reached end users or is still concentrated at the backers. It lags the code and packaging evidence badly, so use it to tell Displace from Split on the demand side, never as an early signal.

In Refolk's index of professional profiles, the counts for the US are:

| Skill | US profiles | Fork-to-upstream | Top employers in 25-profile sample |
|---|---|---|---|
| Redis | 38,739 | n/a | Spread out, every employer at 1 |
| Valkey | 48 | 0.12% | AWS 3, Snap 2, Apple 2, Google 1, Oracle 1 |
| OpenTofu | 122 | Not computed | Spread out, every employer at 1 |

Terraform was not queried, so there is no OpenTofu ratio. Valkey and OpenTofu skill holders are in a ratio of roughly 1 to 2.5.

**~800 : 1 - US profiles listing Redis for every one listing Valkey, in Refolk's index**

The distros had already switched, but practitioners had not yet started listing the fork as a skill.

**7 of 25 - Sampled Valkey-skilled profiles working at AWS, Snap, Google, or Oracle**

Most of Valkey's talent footprint sits at its backers, whereas OpenTofu's most common title in Refolk's index is Senior DevOps Engineer and its employers are spread out.

How to read this alongside the six scores:

- **Skill clustered at backers, packaging at 2:** the market's supply side has switched but its demand side has not. Valkey's footprint looks like this. Keep the verdict at Displace for distribution, and tell leadership that hiring for the fork will mostly mean hiring from the backers for some time yet.
- **Skill spread across end-user roles:** adoption has reached operators. OpenTofu's footprint is spread across end-user DevOps titles, which suggests the fork has users well beyond the companies that fund it.
- **How it lies:** people update their profiles slowly, and people using the fork may still list the upstream because the commands and concepts are the same. A tiny count does not make a fork Fizzle when D2 and D3 are strong.

The same cross-check also fixes the hardest step in the procedure, which is attributing commits. A gmail address on a commit tells you nothing about who pays for the work. [Refolk](/) links a GitHub committer to a named person and current employer across GitHub, LinkedIn, and the open web, so the unattributed pile shrinks and the elephant factor stops getting a boost from anonymous commits.

I ran this search: `Engineers at AWS, Google, Oracle or Ericsson who commit to the Valkey repository on GitHub` - [see the full result list](https://www.refolk.ai/s/fc0mnydcm7).

*Returns named engineers with their Valkey commit activity and current employer, so you can test commit attribution against people rather than email domains.*

## The procedure: scoring a fork step by step

Eight steps take you from a fork announcement to a scored verdict. The first four produce the people numbers, the next three log the market and governance facts, and the last one turns everything into a call. The time estimates are my own working figures. Employer attribution is where most of the error enters.

#### Hard-fork outcome read

1. **Fix the window** - Set day 0 as the fork announcement and write down the windows, for example days 0 to 90 and days 0 to 365. About 1 hour.
2. **Pull commit history for both repos** - Pull the trailing year of upstream commits before the fork and all fork commits since, into one deduplicated author table. About half a day.
3. **Attribute employers** - Use SortingHat or a manual review, decide how gmail and noreply addresses are handled, and report the unattributed share. 1 to 3 days.
4. **Compute defection share and elephant factor** - Compute both for fork and upstream, each written with its window and count type. About 2 hours.
5. **Log packaging events** - Record distro proposals separately from shipped releases, plus managed-service GA dates, each with days since fork. About half a day.
6. **Track divergence and governance** - Note compat packaging, PR and release cadence on both sides, the foundation, the trademark owner, and any CLA. About half a day.
7. **Watch for upstream counter-moves** - Date any relicensing back or rehiring of key people, and schedule a two-quarter comparison of fork activity. Ongoing.
8. **Score, give a verdict, and set a re-check date** - Score D1 to D6, apply the verdict rules, state confidence and its reason, and name a dated trigger. About 1 hour.

### Notes on the hard steps

- **Attribution follows the CHAOSS method:** build a list of people associated with each organization, collect data from wherever contributions happen, identify each contributor's affiliation, and match contributions to organizations. Decide in advance how you will handle multiple email addresses, affiliation changes over time, and contractors versus employees. CHAOSS itself says affiliation data is almost never accurate enough to use without some manual cleanup. No error rate has been published.
- **Order is disputed.** Refolk's Employer-Concentration Read puts affiliation cleanup before any computation. The CHAOSS practitioner guide starts from trend charts, and it lists elephant factor first among the organizational metrics, ahead of diversity and influence. I clean first, because a trend chart built from dirty affiliations gives you the wrong shape.
- **Packaging needs the shipped release.** For each distro, record the release in which the fork actually ships, not the date of the change proposal.

## Turning six scores into a verdict, confidence, and re-check date

Apply the rules in order. A zero on backer breadth means Fizzle. Displace needs top scores on breadth, packaging, and governance. Everything else is Split. Then state a confidence level and a dated re-check, because a fork between 30 and 365 days old is still moving.

#### Defection against backer breadth

Horizontal axis runs from Elephant factor 1, one backer to Many paying employers. Vertical axis runs from Upstream core stays to Upstream committers defect.

| Quadrant | What it means |
| --- | --- |
| Founder fork | Freenginx pattern; lean Fizzle unless new employers appear by the re-check |
| Displace candidate | Valkey pattern; confirm with packaging and governance scores |
| Protest fork | Lean Fizzle; re-check only if a distro or cloud picks it up |
| Sponsored parallel line | Lean Split; packaging and governance decide whether it climbs |

*Defection only matters when several employers are paying for the fork's commits; on its own it describes a founder, not a market shift.*

### Verdict rules

1. **Fizzle** if D2 is 0. Also Fizzle if D2 is 1 and both D3 and D5 are 0, because one dominant backer with no channel and no neutral home has nothing holding it in place.
2. **Displace** if D2, D3, and D5 are all 2, and D6 is at least 1.
3. **Split** for everything else. In practice this means a fork with real breadth and governance that has not yet taken the default channels, or an upstream counter-move that has slowed the fork without stopping it.

D1 and D4 shift the verdict within its band rather than defining it. A Split with D1 at 2 and D4 at 2 is heading toward Displace. A Split with both at 0 is heading toward Fizzle.

### Confidence

- **High:** unattributed commits below your working threshold, every count labeled with its type, and at least one shipped distro release or managed-service GA on record.
- **Medium:** attribution is clean but the packaging evidence is still at the proposal stage, or the fork is younger than the first packaging decision (about 70 days in the earliest documented case).
- **Low:** heavy unattributed share, mixed count types, or a case pattern with no calibration behind it, such as a fork whose upstream has just relicensed and has no two-quarter comparison yet.

### Re-check trigger

Tie the re-check to an event with a date, not to a calendar interval. Good triggers are the next distro release where a switch would ship, an announced managed-service GA, a foundation acceptance decision, the day 90 or day 365 mark, and the end of the second quarter after any upstream relicense.

**Hard-fork outcome memo**

```
Fork:                      Upstream:
Day 0 (announcement):      Read date / days since fork:
Windows: days 0 to 90, days 0 to 365
Unattributed commit share (fork / upstream): __% / __%

D1 Defection: __ of __ trailing-year upstream committers stopped or moved [window]   Score: _
D2 Backer breadth: fork elephant factor __ / upstream __ [window, commits]           Score: _
D3 Packaging: shipped distro releases (release, day) / cloud GA (service, day)      Score: _
D4 Compatibility and divergence: compat package Y/N; PRs/month fork __ vs upstream __ Score: _
D5 Governance: fork home __; trademark owner __; upstream CLA Y/N                    Score: _
D6 Counter-moves: relicense (date) / rehires (who, date); fork cadence after         Score: _

Talent cross-check: fork-skill profiles __ vs upstream __; share at backers in sample __

Verdict: Displace / Split / Fizzle
Confidence: High / Medium / Low, because __
Re-check on: (date), when (event)
What would change the verdict: __
```

*One per fork. Keep the window and count type beside every number, and replace each blank before it goes to leadership.*

## How the read goes wrong

Most bad calls on a fork come from about seven errors, and nearly all of them make the fork look stronger than it is. Run each check below before the memo goes out. This section matters more than the rubric, because a wrong score that looks precise is worse than no score.

1. **Unattributed commits.** Gmail and noreply addresses swell the "independent" share and push the elephant factor up. *Check:* report the percentage of commits left unattributed. Above about 15%, which is my working threshold and not a published standard, do a manual cleanup pass before you score D2.
2. **Mixing contributor counts.** Putting a monthly-active figure (49) next to a cumulative one (150) makes momentum look three times larger than it is. *Check:* write the count type next to every number in the memo.
3. **Defection by one key person.** Freenginx got the most active core developer and stayed small. A fork led by one person can show very high defection and still have an elephant factor of 1. *Check:* never score D1 without D2 next to it.
4. **Survey framing.** The same survey supports anything from 7% to 76%, and its sponsor contributes to the fork. *Check:* use only the "currently using" row and name who paid for the survey.
5. **Proposals counted as shipping.** A distro change proposal has not shipped anything. The Fedora proposal was held back two weeks waiting for compat packaging. *Check:* count the release that ships.
6. **Relicense read as a win for the upstream.** AGPL removes the licensing argument, but the fork's foundation ownership is still there. *Check:* compare fork PR and release counts across the two quarters after the relicense before you move D6.
7. **Stars as momentum.** Stars get cited constantly, but none of the evidence links them to the outcome. *Check:* leave them out of the score entirely.

### The survey trap, in one table

Here is how the single fork-specific adoption survey (Percona, 151 respondents) gets reported:

| Framing | Value |
|---|---|
| Currently using Valkey | 7% |
| Valkey share among users of an alternative | 23.49% |
| Considering or testing Valkey | ~60% |
| Testing, considering, or adopted, among those considering migration | 75.71% |

The same survey reported 67% currently using Redis. Later articles repeat a figure of 83% that I could not trace to any source, so leave it out. Self-reported download totals have the same problem from the other direction: they come from the project, and no published registry series tracks fork and upstream downloads side by side.

> **Watch out:** A relicense is not a reversal
>
> When the upstream relicenses back, the headlines say the fork's reason is gone. In both documented cases, the fork kept its foundation and its pace. Change D6 only after two quarters of fork activity data, never on the announcement.

> A fork is decided by who pays for the commits, not by who wrote the most of them.

## Keeping the read current

A verdict on a fork younger than a year has a short shelf life. Re-score on each trigger event, and log what changed and why, so leadership can see the call firming up instead of a fresh opinion every quarter.

### What to re-pull at each trigger

- **D2 first.** Re-run attribution on the new window. If a second or third employer has appeared in the fork's commits, a Fizzle lean can move to Split.
- **Packaging.** Check whether each proposal you logged turned into a shipped release, and record the day count.
- **Counter-moves.** If the upstream has relicensed or rehired someone, start the two-quarter comparison clock on that date.
- **Talent cross-check.** Re-run the skill counts and the employer sample. A spread away from the backers toward end-user titles is the demand-side sign that a Split is heading toward Displace. To find the people behind a packaging decision, Refolk will answer a plain-English request such as distribution package maintainers for Valkey at Fedora, AlmaLinux, Debian or Arch.

#### Before the memo goes to leadership

- [ ] Day 0 and every measurement window are written at the top of the memo.
- [ ] The unattributed commit share is reported for both fork and upstream.
- [ ] Every contributor number carries its count type, monthly active or cumulative.
- [ ] D2 was scored before D1, and the Fizzle rule was applied if D2 is 0.
- [ ] Every packaging event is a shipped release or a GA date, with days since fork.
- [ ] The trademark owner and any CLA are recorded for both projects.
- [ ] Any upstream relicense has a scheduled two-quarter comparison, and D6 was not moved on the announcement.
- [ ] Survey figures, if any, use only the currently-using row and name the sponsor.
- [ ] No star counts appear in the scoring.
- [ ] The confidence level states its reason, and the re-check names a date and an event.

When the fork passes day 365, close the read. Record the final verdict, the scores at each re-check, and the event that settled it. That record is the calibration data this field is missing, and it will make your next fork read more accurate than this one.

## Frequently asked questions

### How early can you tell whether an open source fork will succeed?

You can make a low-confidence call from commit attribution inside the first 90 days, but the strongest Displace evidence arrives later. In the Valkey case, Fedora's approval came about 70 days after the fork and the AWS managed-service launch about 220 to 245 days after. Treat any read made before a distro or managed-service decision as provisional, and set the re-check date on the next of those events rather than on a calendar interval.

### Does an upstream relicensing back to open source kill the fork?

Not in the documented cases. Elastic added AGPL about 40 months after the OpenSearch fork, and OpenSearch moved into its own foundation 18 days later. Redis added AGPL about 13 months after Valkey forked, and Valkey still averaged 80 PRs a month against Redis's 42 that year. A relicense removes the licensing argument but not the fork's foundation ownership. Compare fork PR and release counts over the two quarters that follow before you change a verdict.

### What is elephant factor and why does it matter for a fork?

Elephant factor is the smallest number of organizations whose people together account for half of a project's contributions. It matters because forks survive on payroll. A fork with an elephant factor of 1 depends on one company or one person, which is the Freenginx pattern. After a relicense under a company CLA, the upstream's own elephant factor tends to collapse to 1, as Redis's did when every external company contributor with more than five commits stopped.

### Are GitHub stars or download counts good evidence of fork momentum?

No. Stars are quoted constantly in fork coverage, but none of the case evidence ties star counts to whether a fork displaced, split, or faded. Download figures are usually the project's own self-reported totals, and no published registry series tracks fork and upstream downloads side by side. Use commit attribution, packaging events, and governance facts instead, and treat stars and downloads as context only.

### If the upstream's lead maintainer moves to the fork, is that enough to call it?

No. Freenginx got the developer that one commenter credited, together with a colleague, with about 99% of current development, and the fork stayed active but small. High defection with an elephant factor of 1 means a single person carries the project. Always score backer breadth alongside defection. A fork needs several employers paying for commits before defection turns into displacement.

### How should I use adoption surveys in a fork vs upstream comparison?

Use only the 'currently using' figure and record who paid for the survey. The one survey that separates Valkey from Redis had 151 respondents and supports figures from 7% to about 76% depending on the framing, and its sponsor, Percona, contributes to Valkey. The 7% currently using Valkey against 67% using Redis is the only row that measures adoption. The other framings measure intent.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/hard-fork-outcome-read*