Example 3: The Forked Repository

Advanced40-60 minutesCross-platformDiscordSteam Workshop

The fork is the drama-war equivalent of seizing a fortified position. On Steam Workshop and on GitHub, a fork copies the enemy's entire work into your own hands, removes it from their control, and hands your community a place to continue the product without them. It is one of the oldest weapons in the modding arsenal, and one of the least understood. The Yamak Institute tracks fork campaigns as a distinct category of engagement, and its records show a stark asymmetry: the fork has won campaigns outright in 61% of the cases where it was launched against an unprepared maintainer, and it has destroyed its own author in 34% of cases overall. Example DW-0510, known as The Forked Repository, is the cohort's canonical study of both outcomes, because it produced both of them in the same war.

The engagement concerned a popular quality-of-life framework for Unturned servers, maintained by a single developer identified in the files as "the Warden." The Warden had become known for slow releases, private feature lists, and a Discord where criticism was removed within minutes. A coalition of server owners and contributors had spent months requesting a changelog, a public issue tracker, and a roadmap. The Warden's response was a statement that no changelog would be published because the project's direction was "an internal matter." The coalition then made its calculations in the temple, and its calculations produced a fork.

The fork is the drama war's most complete seizure, and it is the only weapon that can win without firing a shot against its target. It does not argue with the enemy, does not raid the enemy, and does not smear the enemy. It moves the ground: it copies the product, offers the maintenance the enemy refused, and lets the community decide where the work continues. The Forked Repository is the cohort's demonstration that the fork's power is not in the copy but in the maintenance, and that the fork that offers only a copy is a fork that has seized nothing.

Prerequisites

The doctrine of On Terrain, because the fork is the seizure and holding of position
The calculations of Laying Plans, because the coalition's fork was decided in the temple before it was published
The art of The Art of the Counter, because the counter-fork is the doctrine's rarest and most failed formation
The economics of The Economics of the Drama War, because the fork wins by outspending the original in maintenance
Experience, direct or observed, with at least one mod project that was forked, or one community that chose between a project and its fork

The article is a worked case study, and its full weight is carried by the preceding doctrine. The fork is the seizure the terrain chapter prepares for, the stratagem the laying-plans method calculates, and the counter the counter chapter answers. A reader who has studied the four works above will recognize the coalition's fork as the terrain doctrine executed against the Warden's abandoned position, and the counter-fork as the counter chapter's most failed formation. A reader who has not will still follow the fork's shape, but the references will land without their full charge.

What You Will Learn

Why the fork is the seizure of position rather than the settlement of an argument
How the fork breaks the junction between the maintainer and the users
The maintenance differential and why the fork must outpace the original every day
Why the revenge fork is always legible and always fails
Why the counter-fork concedes the position and never succeeds
The five-stage protocol for running a fork campaign, or retiring into one
The answers to the objections sceptical maintainers and contributors raise against the doctrine
The reference apparatus: the cohort studies, the fork-readiness audit, and the fork campaign checklist
How the fork changes register across mod teams, plugin authors, factions, and community projects
The principle chain that connects the maintenance to the absorption, and where the chain breaks cheapest

The Fork as the Seizure of the Enemy's Position

The Art of War teaches that the rule is, not to besiege walled cities if it can possibly be avoided. The coalition understood this instinctively. A siege of the Warden's position would have meant months of arguing in his Discord, under his moderation, on his terms. The fork avoided the siege entirely. The coalition published a complete copy of the framework, an open issue tracker, a public roadmap, and a maintainer group of five named contributors. It then announced the fork in every community server except the Warden's own.

The rule is, not to besiege walled cities if it can possibly be avoided.
Sun Tzu, The Art of War, ch. 3

The seizure was complete before the Warden learned of it. His community woke up to find that the product he controlled had, overnight, gained a public twin that was faster, transparent, and owned by people who answered questions. The Warden's Discord did not empty in a day; it emptied in three. The fork had not beaten him in an argument. It had moved the ground out from under the argument. As the doctrine puts it, to attack the enemy where he is unprepared, appear where you are not expected.

Attack him where he is unprepared, appear where you are not expected.
Sun Tzu, The Art of War, ch. 1

The fork is the doctrine's chapter on attack by stratagem applied to the modding surface, and the comparison with the siege it avoids is the doctrine's clearest statement of the fork's economy:

The siege	The fork
Argues in the enemy's channel, under his moderation	Builds the alternative road next to it
Requires the enemy's engagement	Requires nothing from the enemy
Spends the community's attention on the dispute	Spends the community's attention on the product
Ends when the enemy concedes	Ends when the community moves
The enemy controls the ground	The forker controls the ground

The table is the doctrine's arithmetic in two columns. The siege's victory depends on the enemy; the fork's victory depends on the community. The siege fights on the enemy's ground; the fork builds on its own. The doctrine's counsel is the table's whole lesson: the fork is the stratagem that makes the siege unnecessary, and the siege is the formation the doctrine refuses whenever the fork is available.

Documented example

Example DW-0137, "The Workshop Mirror." A vehicle pack author refused to fix a save-breaking bug, telling users to "wait for the next major." A user forked the pack to Steam Workshop, applied the one-line fix, and published it under the title "Vehicle Pack, Maintained." Within a week the mirror had more subscribers than the original. The original author's response, a statement accusing the mirror of theft, was met with a single reply that has become famous in the cohort: "It is your own code, still attributed, with the bug fixed. The only thing taken was the waiting." The mirror author never claimed ownership; that was the point. He claimed maintenance, which was the position the original author had abandoned.

The junction of forces is the key insight of the fork doctrine. Sun Tzu teaches that the wise leader prevents the enemy's forces from uniting. The Warden's position depended on one junction: the users and the maintainer meeting inside his Discord. The fork broke that junction. The users no longer needed to pass through the Warden's channel to get updates, fixes, or answers. The Art of War names this specifically: when you surround an army, leave an outlet free, and the fork is the outlet.

When you surround an army, leave an outlet free.
Sun Tzu, The Art of War, ch. 7

The Fork Avoids the Siege

The coalition's instinct was the doctrine's first principle applied to the modding surface. A siege of the Warden's position would have meant fighting inside his Discord, where he held the moderation power and the framing advantage. The coalition would have been arguing on his ground, under his rules, against his timeline. The fork avoided the siege entirely by not attacking the position at all. It built the alternative position next to it, and the alternative position made the siege unnecessary. The doctrine's rule is not to besiege what can be avoided, and the fork is the drama war's purest avoidance.

The avoidance is also the fork's elegance: it wins without forcing the enemy to lose in public. The Warden was not defeated by an argument, a raid, or a smear; he was outlasted by a better road. A community that watches a fork win does not see a humiliation; it sees a choice made. The doctrine's counsel to the forker is that the fork's victory should look like a decision, not a conquest, because the decision is what recruits the community and the conquest is what recruits the enemy's sympathy.

The Seizure of the Ground

The fork seizes ground, and the ground is the position the original maintainer occupied. Before the fork, the Warden held the only road to the framework: updates, fixes, answers, and the roadmap all ran through him. The fork opened a second road, and the second road was faster. The community did not need to be persuaded to prefer the fork; the community preferred the road that worked, and the fork was the road that worked. The doctrine's chapter on terrain teaches that the position is the ground, and the fork's seizure was complete the moment the second road was open.

The seizure is also the explanation for the fork's speed. The Warden's Discord emptied in three days not because the community was persuaded but because the community moved. The moving was the seizure, and the moving was decided by the maintenance, not by the argument. The fork that seizes ground seizes it by being the better position, and the better position is the position where the work is done. The doctrine's counsel to the forker is that the ground is held by the work, and the work is the only thing that holds it.

The Junction Broken

The junction of forces is the doctrine's term for the meeting point on which a position depends, and the Warden's position depended on one: the users and the maintainer meeting inside his Discord. The junction was the source of the Warden's power and the source of his control. The fork broke the junction by giving the users a second place to meet, and the second place did not require the Warden's permission. The users who wanted updates, fixes, or answers could now get them without passing through the Warden's channel, and the passing-through had been the Warden's authority.

The broken junction is also the fork's most durable effect. A community that has moved to the fork does not move back, because moving back would mean re-entering the junction that the fork broke. The doctrine's counsel to the forker is that the junction is broken once and permanently: the users are given every reason never to return, and the returning is the only thing that could restore the enemy's position. The fork that breaks the junction holds the ground as long as the maintenance holds the users.

Documented example

Example DW-0104, "The Junction Held." A framework author, seeing a rival preparing a fork, opened his issue tracker, published a changelog, and named a public roadmap within a week of the community's requests. The rival's fork launched to find the position already held: the tracker answered, the changelog shipped, and the roadmap was public. The fork's differential never fell below parity, the community never moved, and the rival abandoned the fork within a month. The cohort codes the case as the fork prevented, and its lesson is the doctrine's prevention in action: the junction is held by the work the community can see, and the visible work is the fork's first and largest obstacle. The Warden's project was forked because the junction had been abandoned for months; the Junction Cohort records that the junction held is the fork never launched.

The Outlet That the Doctrine Requires

The doctrine's counsel on the surrounded army is to leave an outlet free, and the fork is the outlet. The Warden's community was not trapped in a siege with no way out; it was given an exit that did not look like surrender. The fork offered the users a way to leave the Warden's project without betraying it, because the fork was the same product, credited, maintained. The users who left did not leave the framework; they left the maintainer, and the leaving was the outlet the doctrine requires.

The outlet is also the fork's ethical ground. The doctrine's refusal to besiege is a refusal to trap, and the fork's outlet is the refusal made concrete: the community is never asked to choose between the project and its future, because the fork keeps the project and replaces the future. The Warden's counter-fork, launched six weeks later, offered no outlet, because it was the same product with the same maintainer. The difference between the fork that won and the counter-fork that failed is the difference between the outlet and the trap, and the doctrine records the difference in the fork's own outcome.

The Shape of the Fork

The fork's mechanics are a flow, and the flow is the doctrine's warning in diagram form:

The shape shows the fork's only two outcomes. The branch that matters is the differential: the fork that answers fast seizes the position, and the fork that does not is a second original, equally ignored. The doctrine's counsel to the forker is to read the diagram before the launch: the fork's success is decided in its first thirty days, by the response time, and nothing else the fork does can repair a differential the tempo never held.

The Fork That Won

The coalition's fork won because it was launched at full operational tempo and never slowed. The Art of War says rapidity is the essence of war, and the fork's first month set a cohort record for issue-response time: every single issue filed on the fork received a reply within forty-eight hours, most within six. The maintainers shipped three updates in the first two weeks, one of which closed the most-requested feature. The fork did not need to attack the Warden. It only needed to be what the Warden was not.

Rapidity is the essence of war:
Sun Tzu, The Art of War, ch. 11

Did you know?

The Yamak Institute's fork doctrine includes the "maintenance differential." It is the ratio between the fork's issue-response time and the original's, measured over the fork's first thirty days. Forks with a maintenance differential below 0.5 (responding at least twice as fast as the original) retain their community after ninety days in 88% of cases. Forks with a differential above 1.0, meaning the fork is slower than the original it replaced, fail in 92% of cases. The fork does not win by existing. It wins by being faster than what it replaced, every day, until the community forgets there was a difference.

The Warden made three counter-moves, and the cohort records all three as textbook errors. He published a statement calling the fork a "sabotage operation." He banned the fork's maintainers from his Discord. He threatened to revoke the framework's license for the fork's users. The license threat was the final error. The framework was licensed under a permissive open-source license, the fork was fully within its terms, and the community saw the threat as what it was: a ruler trying to punish the army for using a better road. The threat converted the last undecided server owners, who had been waiting to see which side the law favored. The law favored the fork.

This is called, using the conquered foe to augment one's own strength.
Sun Tzu, The Art of War, ch. 2

The Maintenance Differential

The fork's victory was a matter of arithmetic, and the Institute's arithmetic is the maintenance differential. The fork answered every issue within forty-eight hours, most within six; the Warden's project had been answering issues in weeks, if at all. The differential was below 0.5 in the fork's first month, and the cohort's record is the differential's record: a fork responding twice as fast as the original retains its community after ninety days in 88% of cases. The fork did not win by its arguments, its name, or its announcement. It won by the number, and the number was the response time.

The differential is the fork doctrine's core because it names the mechanism of the seizure. The community does not choose a fork because of a manifesto; it chooses a fork because the fork answers. The answer is the maintenance, and the maintenance is the position. The Warden's project had abandoned the position by slow releases and private feature lists, and the fork's first month was the reoccupation of the position the Warden had left. The doctrine's counsel to the forker is to measure the differential from the first day and to keep the measure below 0.5 until the community forgets there was a difference.

The Tempo That Never Slowed

The fork's rapidity was not a first-week burst; it was a standing condition. The maintainers shipped three updates in the first two weeks, and they shipped more in the weeks after. The fork's cadence was the enemy's cadence inverted: where the Warden's project had been slow, the fork was fast, and where the Warden's project had been private, the fork was public. The tempo was the seizure's second mechanism, because a fast project recruits the community that a slow project has been losing. The doctrine's chapter on energy teaches that the striking energy is the weight of the movement, and the fork's weight was its unbroken tempo.

The tempo that never slowed is also the fork's defense against the counter. A fast project is hard to attack, because every attack arrives to find the project already ahead. The Warden's statement calling the fork a sabotage operation was published against a fork that had already answered the community's issues and shipped its first update; the statement arrived to find the position already moved. The doctrine's counsel is that the fork's tempo is its armor, and the fork that slows is the fork that opens the armor.

Documented example

Example DW-0235, "The Fork That Did Not Outrun." A map project was forked by a group that copied the assets, published an announcement, and then responded to no issues for its first three weeks. The original author, by contrast, had been slow but was not silent. The community that had moved to the fork's announcement moved back to the original within a month, because the original answered and the fork did not. The fork's differential was above 1.0 from the start, and the Maintenance Differential Cohort records the outcome without surprise: a fork slower than the original fails in 92% of cases. The doctrine's counsel is that the announcement is not the fork; the response time is the fork, and a fork that cannot answer is a second original, equally ignored.

The Three Counter-Moves

The Warden's three counter-moves are the cohort's canonical catalog of how not to respond to a fork. The first, the statement calling the fork sabotage, was an attack on the community's choice rather than on the fork's quality, and the community read it as the maintainer's complaint about the road. The second, the ban on the fork's maintainers, was the enforcement of a jurisdiction the maintainers had already left, and the ban was the Warden punishing his former members for their new home. The third, the license threat, was the legal overreach, and it was the counter-move that did the most damage to its own author.

The three counter-moves share a single error: each one treated the fork as an enemy to be attacked rather than a position to be matched. The Warden could have answered the fork with the changelog, the tracker, and the roadmap the community had requested for months; instead he answered with accusations, bans, and threats. The doctrine's counsel to the besieged maintainer is that the fork is not attacked; it is out-maintented, and the only answer to a better road is a better road. The Warden's counter-moves were the road's owner shooting at the travelers, and the travelers chose the other road.

The Maintenance War

The fork's campaign is a maintenance war, and the maintenance war is the engagement the counter-moves should have fought. The war's field is the response time, the changelog, and the cadence; its weapons are the issue log and the update; and its victory condition is the differential. The Warden had every weapon the war required - the code, the knowledge, the community's history - and he refused to fire any of them, because the maintenance war requires the very openness he had refused for months. The coalition fired the maintenance weapons and won; the Warden fired the accusations and lost. The doctrine's counsel is that the fork is fought on the maintenance field or not at all, and the party that refuses the field has lost the war before the first update ships.

The maintenance war also names the fork's deepest cost to the original. The Warden's project did not lose to an argument; it lost to a cadence it could have matched. The community did not choose the fork's politics; it chose the fork's response time. The doctrine's counsel to the besieged maintainer is the war's whole lesson: the only answer to a better road is a better road, and the better road is built with the changelog, the tracker, and the schedule that the fork made public. The maintainer who matches the cadence holds the junction; the maintainer who attacks the road loses the travelers.

Documented example

Example DW-0580, "The Maintainer Who Matched." A plugin author watched a rival's fork ship three updates in its first two weeks. Instead of attacking the fork, the author published a changelog, opened a tracker, and matched the fork's cadence update for update. The fork's differential, which had been strong, collapsed to near parity, and the community, which had moved, found two roads of equal speed. The original author's history, reputation, and name were the tiebreaker, and the community moved back. The cohort codes the case as the counter that works: not the counter-fork, not the accusation, but the maintenance matched. The doctrine's counsel is that the fork is beaten on the maintenance field, and the maintenance field is the only field the fork cannot survive losing.

The License Threat as the Final Error

The license threat deserves its own reading, because it was the counter-move that converted the fork's victory into the fork's empire. The framework was licensed under a permissive open-source license, and the fork was fully within its terms. The threat to revoke the license was not merely wrong; it was visible as wrong to the entire community, because the license was public and the fork's compliance was checkable. The community watched a maintainer threaten a legal action that the law did not support, and the watching converted the last undecided server owners, who had been waiting to see which side the law favored. The law favored the fork.

The threat's cost was the Warden's remaining credibility. A maintainer who threatens a legal action that the community can verify as baseless has taught the community that his claims cannot be trusted, and the teaching extends to every claim he makes after. The doctrine's chapter on deception warns that the commander who practices dissimulation will succeed only while the dissimulation is not exposed, and the license threat was exposed within the day. The doctrine's counsel to the besieged maintainer is the inverse of the Warden's move: never threaten a legal action you cannot win, because the empty threat is the accusation the community will hold against you.

The Fork That Ruined Its Author

The same engagement produced the cohort's clearest example of the fork that ruins its author, because a second fork appeared in week three, launched not by the coalition but by a disaffected ex-contributor who had been removed from the Warden's team months earlier. This second fork was launched as an act of revenge. It was published with a changelog that listed the Warden's private conversations, a title that mocked the Warden by name, and a readme that existed almost entirely to insult him.

The revenge fork is a fork that seizes nothing. It carries no maintenance advantage, because its author cares more about the enemy than the product. It fails the first test of the seizure of position: it does not occupy the enemy's ground, it merely defaces it. The cohort records that revenge forks fail in every single documented case, not because their code is worse, but because their intent is legible. The community that supports a fork is choosing maintenance, and a fork whose readme is an attack has announced that it is choosing war.

In war, practice dissimulation, and you will succeed.
Sun Tzu, The Art of War, ch. 7

Documented example

Example DW-0670, "The Parting Shot." A mod author removed a contributor and, within an hour, the contributor published a fork titled "The Original Author's Secret History." The fork contained the removed contributor's version of events and no updates at all. It was shared once, laughed at, and abandoned. The removed contributor gained nothing. The coalition case teaches the inverse: the winning fork was published under a neutral title, credited the original author in its readme, and let the maintenance do the talking. Revenge is readable, and the readable motive is the unreadable strategy.

The revenge fork also failed strategically for a second reason. It split the coalition's own audience. The community that had rallied behind the maintenance fork now had to explain that the revenge fork was not theirs. The Warden, in his final statement, pointed at the revenge fork as proof that "the entire campaign was personal." He was wrong about the coalition, but the revenge fork gave him the only legitimate sentence he had left. The Art of War warns against joining forces you cannot control. The coalition's error was not the fork. It was failing to keep its own flank from firing into the enemy's hands.

On open ground, do not try to block the enemy's way.
Sun Tzu, The Art of War, ch. 11

The Fork That Seizes Nothing

The revenge fork is the fork's failure mode, and its failure is structural. A fork seizes ground by occupying the enemy's position with maintenance; the revenge fork occupies nothing, because its author's attention is on the enemy, not on the product. The changelog that lists private conversations is not maintenance; the readme that insults the Warden is not a feature list. The revenge fork's author publishes once, waits for the reaction, and then has nothing to do, because the project is not the point. The cohort records the outcome without exception: revenge forks fail in every documented case.

The structural failure is also the revenge fork's legibility. The community reads a fork's readme before it reads its code, and the readme that attacks the enemy announces the fork's motive. The community that supports a fork is choosing maintenance, and a fork that announces it is choosing war has told the community not to choose it. The doctrine's counsel to the wronged contributor is the counsel the revenge fork refuses: if the fork's readme cannot be read without the enemy's name in it, the fork is not a fork; it is a statement wearing a repository's clothes, and the statement belongs on the statement's surface, not on the product's.

The Legible Motive

The doctrine's term for the revenge fork's failure is the legible motive. The winning fork's motive - maintenance - is invisible, because it looks like ordinary competence. The revenge fork's motive - revenge - is visible, because it is written into the readme, the title, and the changelog. The community reads the motive in the first minute, and the reading is the fork's death. The cohort's lesson is the inverse: the winning fork publishes under a neutral title, credits the original author, and lets the maintenance do the talking, because the maintenance is a motive the community can support without endorsing a war.

The legible motive is also the fork's only ethical requirement. The fork that claims maintenance must be able to prove the claim, and the proof is the issue log and the changelog. The revenge fork that claims maintenance must prove the claim too, and the claim is proven false by the readme's first paragraph. The doctrine's counsel to the forker is that the motive is legible in the product, and the product is the only thing the community reads as the fork's true intent.

The Flank That Fired Into the Enemy's Hands

The revenge fork's second failure was the split it drove through the coalition's own audience. The community that had rallied behind the maintenance fork now had to explain that the revenge fork was not theirs, and the explanation was a day of the community's attention spent on the enemy's behalf. The Warden, in his final statement, pointed at the revenge fork as proof that the campaign was personal, and the pointing gave him the only legitimate sentence he had left. The revenge fork had handed the enemy the evidence the enemy's position needed, and the evidence was the coalition's own flank.

The doctrine's warning is against joining forces you cannot control, and the warning applies to the coalition's own flank as much as to an external ally. The coalition could not control the ex-contributor's fork, and the uncontrolled fork fired into the enemy's hands. The doctrine's counsel to the forker is to keep the fork's flank clean: the fork is published by a named group, under a neutral title, with a public history, and any fork that the group cannot control is disowned in advance. The coalition's error was not the fork; it was the failure to keep its own flank from firing, and the flank's fire was the enemy's only legitimate ammunition.

The Final Statement and the Legitimate Sentence

The Warden's final statement was the enemy's closing argument, and it was built entirely from the revenge fork. "The entire campaign was personal," the Warden wrote, and the sentence was legitimate only because the revenge fork had made it look true. The coalition's maintenance fork had been personal nowhere; the revenge fork was personal everywhere, and the enemy pointed at the one that looked like the other. The doctrine records the episode as the enemy's use of the uncontrolled flank: the Warden did not need to prove the coalition was personal; he needed only to show the community the fork that was.

The lesson for the forker is that the coalition's control of its own narrative is a control of its own flank. The maintenance fork's neutrality was the coalition's defense, and the defense held until the revenge fork arrived. The doctrine's counsel is that the fork campaign must be able to disown its flank in a sentence, and the sentence must be public and early: "We do not speak for the other fork, and it does not speak for us." The coalition published the sentence late, after the enemy had already used the flank, and the late sentence was the lesson the campaign paid for.

Documented example

Example DW-0815, "The Disowned Flank." A mod team's fork of a rival's framework was joined, in its second week, by an unofficial fork that copied the team's code and added a section of insults aimed at the rival. The team published its disavowal the same day: "The other fork is not ours. It is not endorsed, not maintained by us, and not representative of this project." The rival's attempt to point at the unofficial fork as proof of the campaign's hostility met the disavowal already in place, and the attempt collapsed within a week. The cohort codes the case as the flank controlled: the disavowal, published early and public, closed the enemy's only legitimate ammunition before it could be fired. The coalition's mistake was not the revenge fork's existence; it was the lateness of the disowning, and the lateness was the lesson the mod team published on time.

The Counter-fork

The engagement closes with the doctrine's rarest formation: the counter-fork. The Warden, six weeks into the collapse, published his own fork of the coalition's fork. It was legal, it was technically competent, and it was completely ignored. The counter-fork failed because it had no base. Its maintainer had spent six weeks burning bridges with every community that mattered, and a fork cannot be built by a maintainer who has no one left to maintain for.

Critical warning

Do not respond to a fork with a counter-fork. The counter-fork announces that the fork has won the position. If the original position were worth defending, you would defend it; launching a fork of the fork concedes that your own repository is no longer the seat of power. The Yamak cohort records zero successful counter-forks in 1,800 engagements. The only correct response to a superior fork is either to merge with it, improving your own position by joining the enemy's, or to retire the position and build something the fork cannot copy. Never fork the fork.

The Warden's counter-fork was his last act. His project, the fork, and the revenge fork all survive today, but only the coalition's fork has a community. The maintenance fork absorbed the Warden's user base, absorbed his issue tracker's backlog, and eventually absorbed his best contributors, who had been waiting for a reason to leave. The Art of War calls this using the conquered foe to augment one's own strength, and it is the difference between winning a war and inheriting an empire.

Documented example

Example DW-0921, "The Retired Maintainer." A plugin author who had been forked by a faster rival did the one thing the cohort records as a success: he announced the fork himself. His statement read, in full, "The fork is faster, better documented, and I am joining it. Go use it." The community's response was a standing ovation. The author kept his reputation, kept his name on the project, and lost nothing but the burden of maintenance. The doctrine is explicit: when the junction cannot be held, and the ground cannot be regained, the winning move is to change sides in public. The conquered foe augments the conqueror, but the conqueror who joins voluntarily is no longer the conquered foe.

The Counter-fork as the Concession

The counter-fork's failure was announced by its existence. The doctrine's critical warning is exact: the counter-fork announces that the fork has won the position, because the original maintainer, launching a fork of the fork, has conceded that his own repository is no longer the seat of power. The concession was the Warden's entire statement. He had spent six weeks calling the fork sabotage; the counter-fork was the same claim in code, and the code said what the statement could not: the fork was the road, and the Warden was now a traveler on it, forking the road to try to own it again.

The concession also explains the counter-fork's audience problem. The community that had moved to the coalition's fork was not going to move again, because the moving was the point and the moving had already happened. The counter-fork offered the same product with the same maintainer who had burned the bridges, and the bridges were the only reason anyone would choose a fork. The doctrine's counsel to the besieged maintainer is to read the counter-fork's failure before launching it: the counter-fork asks the community to return to the maintainer who drove them out, and the asking is the concession.

The Zero Record

The cohort's record on the counter-fork is the doctrine's most absolute: zero successful counter-forks in 1,800 engagements. The record is the empirical form of the warning, and its absoluteness is the doctrine's point. The counter-fork fails not occasionally but categorically, because its structural position is the position of the conceded. The maintainer who launches a counter-fork has already lost the ground the fork seized, and the counter-fork cannot seize it back because the community has already chosen. The doctrine's counsel is that the counter-fork is the only response the record never rewards, and the record is the reason the warning is absolute.

The zero record also defines the counter-fork's alternatives. The maintainer who cannot win the position back has two moves, and both are recorded as successes. The merge joins the enemy's position and improves it; the retire closes the position and builds another. The Warden attempted neither, because both required the acceptance of the fork's victory, and the acceptance was the one thing his pride refused. The doctrine's counsel is that the acceptance is the winning move, and the record shows that the maintainer who accepts the fork's victory keeps more than the maintainer who fights it: the reputation, the name, and the community's goodwill.

The Merge and the Retire

The doctrine's two correct responses to the superior fork are the merge and the retire, and the distinction between them is the maintainer's situation. The merge is for the maintainer whose product is the position: he joins the fork, improves it with his expertise, and keeps his name on the work. The merge's example is the Retired Maintainer, who announced the fork himself and was rewarded with a standing ovation. The retire is for the maintainer whose name is the position: he closes the project, builds something the fork cannot copy, and returns with new ground. The two moves share the acceptance, and the acceptance is what the counter-fork refuses.

The doctrine's arithmetic on the three responses is the fork's final lesson. The counter-fork spends the maintainer's remaining credibility and wins nothing; the merge spends the pride and keeps the reputation; the retire spends the position and keeps the future. The Warden's counter-fork was the only one of the three that the cohort records as having destroyed its own author, and the destruction was not in the code but in the choice. The doctrine's counsel to the besieged maintainer is the article's whole counsel: when the junction cannot be held and the ground cannot be regained, the winning move is to change sides in public, and the maintainer who changes sides in public is no longer the conquered foe.

The Absorbed Empire

The fork's final state is the doctrine's image of the complete victory: the maintenance fork absorbed the Warden's user base, absorbed his issue tracker's backlog, and eventually absorbed his best contributors, who had been waiting for a reason to leave. The absorption was the doctrine's chapter on using the conquered foe to augment one's own strength, and it was the difference between winning a war and inheriting an empire. The coalition's fork did not merely defeat the Warden; it absorbed him, and the absorption was the seizure's completion.

The absorption is also the fork's proof that the war was over before the Warden's last act. The contributors who joined the fork had been waiting for a reason to leave the Warden's project, and the fork was the reason. The issue backlog that the fork absorbed was the backlog the Warden had refused to make public, and the fork's open tracker was the position's new home. The doctrine's counsel to the forker is that the victory is measured not in the enemy's defeat but in the community's choice, and the community's choice was made the day the fork answered its first issue. The empire was inherited the day the fork was published, and the Warden's counter-fork was the last act of a war that had already been won.

Documented example

Example DW-0723, "The Merge That Worked." A survival server's plugin suite was forked by a rival after its author refused updates for six months. The author, watching the fork ship and the server owners move, did not counter-fork. He announced the fork himself, joined its maintainer group, and contributed the three years of undocumented fixes he had never shipped. The fork became the project, the author kept his name on it, and the rival, who had launched the fork to destroy the author, watched the author become his co-maintainer. The cohort codes the case as the merge's purest form: the maintainer who joins the better road improves it, keeps the reputation, and converts the rival's weapon into his own project. The conquered foe augmented the conqueror by choosing to join, and the join was the only ending that left no one defeated.

The Fork in Different Communities

The fork doctrine is universal in its principles and particular in its surface, and the commander should know how the same seizure changes register between the communities of the Unturned world. A mod team, a server's plugin author, a faction, and a community project each face the fork on a different ground.

Community	The fork's typical ground	The position that is seized	The maintenance that holds it
A mod team	The Workshop page, the repository	The project's direction and releases	The changelog, the tracker, the cadence
A server plugin author	The server's plugin list	The fixes and features the server runs	The response to issue reports
A faction	The faction's builds and assets	The group's creative control	The releases and the credit
A community project	The shared repository	The project's leadership and roadmap	The open work and the answers

The Mod Team's Fork

The mod team's fork is the case this article documents: the framework, the vehicle pack, the asset bundle, forked when the maintainer abandons the maintenance. The team's position is the project's direction, and the fork seizes it by shipping the direction the community requested. The team's maintenance - the changelog, the tracker, the cadence - is the position, and the fork holds the position by being what the original refused to be. The doctrine's counsel to the forking team is the article's whole protocol, and the counsel to the forked team is the counter-fork's rejection.

The Server Plugin Author's Fork

The server plugin author's fork is the fork on the surface where a server's operations run. A plugin author who abandons a fix, a compatibility update, or a security patch has left the position open, and a rival's fork that ships the fix seizes the plugin's future. The server that runs the plugin does not care about the authorship dispute; it cares about the fix. The fork's maintenance differential is measured in the server's uptime, and the plugin fork that answers faster wins the server's loyalty. The doctrine's counsel to the plugin author is the same as to any maintainer: hold the maintenance, or accept the fork, because the server's choice is the fix, and the fix is the position.

The Faction's Fork

The faction's fork arrives in the RP register, and its ground is the faction's creative control. A faction whose leadership abandons its builds, its assets, or its story leaves the position open, and a breakaway group's fork - the same assets, credited, with the work continuing - seizes the ground. The faction's maintenance is the release and the credit, and the fork holds the ground by shipping what the leadership refused. The doctrine's counsel to the faction is the same as to the mod team, and the register is the only difference: the fork's neutrality is held inside the fiction, and the fiction is the surface where the seizure is judged.

The Community Project's Fork

The community project's fork is the fork on the surface where contributors decide with their time. A project whose leadership refuses a roadmap, a public tracker, or a changelog has left the position open, and a contributor's fork that opens the work seizes the contributors. The project's maintenance is the open work and the answers, and the fork holds the ground by giving the contributors the project the leadership refused to run. The doctrine's counsel to the project is the article's whole counsel, and the project that wants to avoid the fork holds the junction - the contributors and the work meeting in the open - because the junction is the only ground the fork can break.

The Yamak Institute Cohort Data

The fork doctrine rests on the Yamak Institute's cohort research into mod-project succession, collected from Steam Workshop and repository surfaces since 2019. The research codes each fork for its launch, its maintenance, its motive, and its outcome, and the coded corpus is the empirical spine of everything this article has claimed. The primary records are presented below in the register in which the Institute publishes them.

The Fork Campaign Cohort (2021)

The flagship dataset of the chapter, the Fork Campaign Cohort, codes fork engagements against their maintainers' preparation and the forks' maintenance. The cohort found the stark asymmetry this article opened with: the fork won the campaign outright in 61% of cases where it was launched against an unprepared maintainer, and it destroyed its own author in 34% of cases overall. The cohort also found the asymmetry's cause: the fork's outcome tracked the maintenance differential, not the fork's arguments, and the differential was the single most predictive variable in the fork's success. The cohort is the empirical form of the article's central claim: the fork wins by maintenance, not by existence.

The Maintenance Differential Cohort (2022)

The Maintenance Differential Cohort measured the ratio between the fork's issue-response time and the original's, over the fork's first thirty days. The cohort found that forks with a differential below 0.5 retained their community after ninety days in 88% of cases, and that forks with a differential above 1.0 - slower than the original they replaced - failed in 92% of cases. The cohort also measured the differential's slope: forks that held the differential below 0.5 for the first month kept the community even when the original improved, because the community had already forgotten the difference. The cohort is the empirical form of the fork's tempo.

The Revenge Fork Cohort (2020)

The Revenge Fork Cohort coded the forks launched as acts of revenge and recorded the outcome without exception: revenge forks failed in every documented case. The cohort also coded the failure's cause, and the cause was the legible motive: the revenge fork's readme, title, or changelog announced the motive, and the announcement converted the fork from a maintenance offer into a war declaration. The cohort is the empirical form of the doctrine's legible-motive rule: the fork whose motive is readable is the fork whose strategy is unreadable.

The Counter-fork Cohort (2023)

The Counter-fork Cohort coded the maintainer's responses to the superior fork and recorded the doctrine's most absolute statistic: zero successful counter-forks in 1,800 engagements. The cohort also coded the successful alternatives: merges and retires succeeded where counter-forks failed, and the success tracked the maintainer's public acceptance of the fork's victory. The cohort is the empirical form of the critical warning: the counter-fork concedes the position, and the concession is the only outcome the counter-fork produces.

The Absorption Cohort (2024)

The Absorption Cohort coded the fork's long-term outcome, measuring what the fork absorbed from the original in the year after the seizure. The cohort found that the maintenance fork absorbed the original's user base, its issue backlog, and its best contributors, and that the absorption was the strongest predictor of the fork's permanence. The cohort also found that the original's contributors joined the fork within months of the fork's launch, when they had a reason, and that the reason was the maintenance. The cohort is the empirical form of the article's ending: the fork that wins inherits the empire, and the inheritance is the seizure's completion.

The Junction Cohort (2022)

The Junction Cohort coded the meeting point on which mod projects depended, and the cohort's central finding is the junction's fragility. Projects that held the junction - the users and the maintainer meeting in the open, with a public tracker and a visible roadmap - were forked at a fraction of the rate of projects that held the junction behind a private channel and a closed list. The cohort also measured the junction's repair: maintainers who opened the tracker and published the changelog within a month of the community's requests retained the community in the large majority of cases, and the repair was the cheapest defense in the fork's arsenal. The cohort is the empirical form of the prevention: the junction is held by the work the community can see, and the visible work is the fork's first obstacle.

The Neutrality Cohort (2023)

The Neutrality Cohort coded the fork's readme, title, and launch announcement, and measured the fork's outcome against its neutrality. The cohort found that forks published under neutral titles, crediting the original author, were adopted at a materially higher rate than forks whose titles or readmes named the enemy, and that the neutral fork's advantage held even when the naming fork's maintenance was equal. The cohort is the empirical form of the legible-motive rule in its positive register: the fork whose motive is invisible is the fork the community can support, and the support is the fork's recruitment.

The Response-Time Staffing Cohort (2025)

The Response-Time Staffing Cohort coded the fork's first month, measuring the number of named maintainers against the fork's response time and its outcome. The cohort found that forks with a named group of three or more maintainers held the differential below 0.5 at a materially higher rate than single-author forks, and that the single-author fork's failure was usually the author's availability, not the author's skill. The cohort is the empirical form of the tempo's staffing: the fork's rapidity is a schedule, and a schedule needs more than one person to keep.

The Five-Stage Protocol for the Fork Campaign

The doctrine of this article is operational, and the Institute's field manual reduces it to a five-stage protocol that a forker executes when a project's maintenance is abandoned, and that a besieged maintainer executes in reverse. Each stage has a verification step, and the protocol is designed to be run in the order the chapter presents: the calculation first, the launch second, the tempo third, the flank fourth, and the ground last.

Stage 1: Calculate in the Temple

Before the fork is launched, calculate whether the position is worth seizing. Is the original's maintenance abandoned? Is the community present and waiting? Can the fork hold the maintenance differential below 0.5 for the first month? The verification step is the calculation test: the forker can write down the original's response time, the fork's planned response time, and the maintenance differential, and the differential is below 0.5 on paper. A forker who passes Stage 1 has a fork worth launching; a forker who fails it is about to launch a fork that the maintenance differential will kill.

Stage 2: Launch the Neutral Fork

Publish the fork under a neutral title, credited to the original author, with an open tracker and a named maintainer group. The launch is a seizure, and the seizure is complete before the original learns of it. The verification step is the neutrality test: the fork's readme, title, and changelog can be read without the enemy's name appearing in them, and the attribution to the original is present. A forker who passes Stage 2 has published a fork that the community can choose without choosing a war; a forker who fails it has published the legible motive that the revenge fork records.

Stage 3: Run the Tempo

Hold the maintenance differential below 0.5 for the first month. Every issue is answered within forty-eight hours, most within six; the updates ship on a cadence; the tracker is public. The verification step is the response-time test: at the end of the first week, the fork's average response time is at most half the original's, and the fork has shipped at least one update. A forker who passes Stage 3 has made the seizure stick; a forker who fails it has published a fork that exists but does not hold, and the differential records the failure.

Stage 4: Control the Flank

Keep the fork's flank clean. The fork is published by a named group, and any fork or statement that the group does not control is disowned in public and early. The verification step is the disavowal test: the forker can point to a public sentence naming the group's own fork and disowning any uncontrolled one. A forker who passes Stage 4 has prevented the enemy's only legitimate ammunition; a forker who fails it has let the flank fire into the enemy's hands, as the revenge fork fired into the Warden's.

Stage 5: Hold the Ground

Hold the ground by the maintenance, and let the absorption happen. The users who come stay because the fork answers; the contributors who join are the original's best, waiting for a reason to leave. The verification step is the ninety-day test: three months after the launch, the fork's community is larger than the original's, and the differential is still below 0.5. A forker who passes Stage 5 has seized the position and absorbed the empire; a forker who fails it has launched a fork that the community forgot.

The protocol is the article's operational core, and the community that works it in order has done the article's work. The community that works it in any other order - launching the fork before the calculation, publishing the readme before the neutrality - is the community the cohort records as the failed fork, and the record is the price of the order.

The Protocol in Reverse

The protocol is written for the forker, and it reads in reverse for the besieged maintainer. The maintainer who wants to prevent the fork runs the same five stages backward: hold the ground by the maintenance, control the flank by the public openness, run the tempo the fork would run, launch the neutrality the fork would launch, and calculate the cost of the abandoned junction before it is abandoned. The Reverse Protocol is the doctrine's gift to the maintainer, and it is the article's whole prevention in executable form:

Stage	The forker	The besieged maintainer
1	Calculate the differential on paper	Calculate the cost of the abandoned junction
2	Launch the neutral, credited fork	Open the tracker, publish the changelog
3	Hold the tempo below 0.5	Match the cadence the fork would set
4	Disown the flank in public	Be the open record the flank cannot fake
5	Hold the ground by the maintenance	Hold the junction with the visible work

The table is the doctrine's mirror: the same five stages, facing opposite directions. The maintainer who runs the protocol in reverse has removed the fork's ground before the coalition can seize it, and the Junction Cohort records the removal as the fork's first and largest obstacle. The Warden never ran the reverse protocol, and the fork seized the ground he had left open for months.

Lessons Learned

Lesson	Source of the lesson	Application
The fork seizes position; it does not settle arguments	Example DW-0510	Fork to control the ground, not to win a debate
Do not besiege what you can flank	Example DW-0137	Never fight inside the enemy's moderated channel
Break the junction of maintainer and users	Example DW-0510	Give the users every reason never to return
The fork must outpace the original every day	Example DW-0510	Track the maintenance differential, not the subscriber count
Revenge forks are always legible and always fail	Example DW-0670	A fork that names the enemy has already named its weakness
Never counter-fork	Example DW-0510	The counter-fork concedes the position to the enemy
When the junction is lost, join it	Example DW-0921	Announce the fork yourself and keep your name

The Forked Repository is the case study for On Terrain, where the seizure and holding of position is the central doctrine, and for The Art of the Counter, which develops the counter-fork question at length. The coalition's pre-fork calculations follow the method of Laying Plans. The war that followed, Example: The Review Bomb, shows what happens when a defeated party abandons position entirely and attacks the enemy's reputation by fire. For the community surface where the fork's credibility is decided, see Why Discord Embeds Are the Foundation of Server Credibility.

Objections

The fork doctrine meets resistance, and the resistance is predictable enough to be answered in advance. The objections below are the most common raised by maintainers who have been forked and contributors who are considering forking. Each is answered in the doctrine's voice.

Objection 1: "A fork is theft."

The doctrine's answer is that the fork is licensed and attributed, and the theft claim is the maintainer's complaint about the road, not a legal argument. A fork within the terms of a permissive license, crediting the original author, is not theft; it is the license's own promise, honored. The doctrine's counsel to the maintainer who calls the fork theft is to read the license before the accusation, because the accusation that the community can check and find baseless is the accusation that spends the accuser's credibility. The fork's theft claim was the Warden's first error, and the community checked it against the license and found it empty.

Objection 2: "The maintainer has a right to control the project's direction."

The doctrine's answer is that the maintainer has a right to the project, and the community has a right to choose where the work continues. The fork does not take the project; it copies it, and the copy is the community's alternative. The maintainer who refuses a changelog, a tracker, and a roadmap is exercising the control; the community that chooses the fork is exercising the choice. The doctrine's counsel is that the control is the position, and the position is held by the maintenance, not by the refusal. The maintainer who refuses the road's improvements is the maintainer who has already lost the road.

Objection 3: "We should fight inside the original's Discord to clear our name."

The doctrine's answer is that the Discord is the enemy's ground, under the enemy's moderation, in the enemy's framing, and a fight there is a siege the doctrine refuses. The fork is the flank: the alternative position that makes the siege unnecessary. The coalition never argued its case in the Warden's Discord, and the argument was never needed, because the fork answered the questions the Discord could not. The doctrine's counsel is to build the alternative and let it do the arguing, because the alternative argues in the community's language, which is the language of the work, not the moderators.

Objection 4: "The fork will fail if the maintainer improves."

The doctrine's answer is that the fork's insurance is the differential and the absorption. A fork that holds the differential below 0.5 for the first month keeps the community even if the original improves, because the community has already forgotten the difference. The maintainer's improvement after the fork is the improvement the community would have needed months earlier, and the fork's answer is the maintenance that arrived first. The doctrine's counsel to the forker is to run the tempo as the insurance: the fork that is faster every day until the community forgets is the fork that the original's improvement cannot recover from.

Objection 5: "The revenge fork is justified; the maintainer wronged the contributor."

The doctrine's answer is that the wrong is real and the fork is the wrong surface for it. The wronged contributor has the statement surface for the grievance, and the grievance belongs there, where it is a statement and not a product. The revenge fork converts the grievance into a repository, and the repository announces the motive and fails. The cohort records no successful revenge fork, and the failure is the price of mixing the grievance with the product. The doctrine's counsel to the wronged contributor is to write the statement, not the fork, and to let the maintenance fork carry the product while the statement carries the grievance.

Objection 6: "The fork should be disowned if it is personal."

The doctrine's answer is that the disowning is the fork campaign's standing obligation, and it is performed in public and early. The coalition's error was not the revenge fork; it was the late and weak disowning, which let the enemy use the flank first. The doctrine's counsel is the sentence published at the fork's launch: "We do not speak for the other fork, and it does not speak for us." The sentence costs nothing and it closes the enemy's only legitimate ammunition. The disowning is not a rejection of the wronged contributor; it is the defense of the fork's neutrality, and the neutrality is the fork's position.

Objection 7: "The counter-fork is the natural response to being forked."

The doctrine's answer is that the counter-fork is the most failed formation in the entire corpus, with zero successes in 1,800 engagements, and its failure is structural. The counter-fork announces that the fork has won the position, because the maintainer who forks his own fork has conceded that his repository is no longer the seat of power. The doctrine's counsel is the two recorded successes: the merge and the retire. The maintainer who accepts the fork's victory keeps his reputation, his name, and his community's goodwill; the maintainer who counter-forks keeps the counter-fork, which the community ignores.

Objection 8: "The fork's contributors will be seen as traitors."

The doctrine's answer is that the community reads the contributors as the choice, not as the betrayal. The contributors who join the fork were waiting for a reason to leave, and the reason was the maintenance. The community that had already moved to the fork reads the contributors as reinforcements; the only community that reads them as traitors is the original maintainer's, and that community is the one the fork has already left behind. The doctrine's counsel to the forker is that the contributors are the fork's proof: the best people chose the better road, and the choice is the fork's strongest advertisement.

Objection 9: "The fork should include a full criticism of the original."

The doctrine's answer is that the criticism belongs on the statement's surface, not in the fork. The fork's readme, changelog, and tracker are the product's documents, and the product's documents are read by the community choosing a road. A readme that criticizes the original converts the fork from a maintenance offer into a war declaration, and the conversion is the legible motive. The doctrine's counsel is to keep the fork clean and let the maintenance speak: the community does not need the criticism to see which road is faster, and the criticism that the readme adds is the criticism that the community will weigh against the fork's neutrality.

Objection 10: "We cannot merge with the enemy; it would look like surrender."

The doctrine's answer is that the merge is the acceptance, and the acceptance is read as wisdom, not surrender. The Retired Maintainer announced the fork himself and received a standing ovation, because the community respected the maintenance and respected the maintainer who honored it. The doctrine's counsel is that the acceptance is the winning move when the junction cannot be held and the ground cannot be regained: the maintainer who joins the better road keeps the name on the work, and the name on the work is the position the fork could not take. The surrender the objector fears is the counter-fork's outcome, not the merge's.

Objection 11: "The doctrine is written from the forker's side."

The doctrine's answer is that the doctrine is written from the record, and the record contains both outcomes. The fork wins against the unprepared maintainer and destroys its own author in 34% of cases, and the doctrine's warnings apply to both sides: the maintainer is warned against the counter-fork, and the forker is warned against the revenge fork and the uncontrolled flank. The doctrine's counsel to the maintainer is the article's whole counsel - out-maintain the fork, or merge with it, or retire and build anew - and the counsel is written from the maintainer's interest as much as the forker's. The doctrine favors the position that is held by the work, and it holds that counsel to both sides of the fork.

Objection 12: "This is about open-source projects, not Unturned mods."

The doctrine's answer is that the fork's mechanics are the same on Steam Workshop as on a repository, because the community's choice is the same. The Workshop mirror, the vehicle pack, the framework fork - each is a copy, an attribution, and a maintenance offer, and each is chosen by the community on the maintenance. The surface changes the storefront, not the economics: the subscriber count and the issue log are the workshop's maintenance differential, and the Workshop page is the position the fork seizes. The doctrine was written for modding because the modding community is where the fork is most often fired, and the fork's doctrine applies wherever a project can be copied and maintained.

Objection 13: "Our project is too small to be forked."

The doctrine's answer is that the fork's target is the maintenance, and a small project's maintenance is as abandoned as a large one's. The small project with a silent maintainer is the small project whose single user is a server that needs the fix; the fork that ships the fix seizes the server. The doctrine's counsel to the small maintainer is the same as to the large: the changelog, the tracker, and the cadence are cheap, and they are the junction's walls. The small project that holds the junction is the project that never sees the fork, and the small project that abandons it is the project whose one user forks the work to survive.

Objection 14: "We cannot afford to maintain both the original and the fork."

The doctrine's answer is that the fork does not ask the forker to maintain both; it asks the forker to maintain the fork, and the original's maintenance is the enemy's burden. The coalition's fork maintained only itself, and the maintenance was the position. The maintainer who fears the double burden is the maintainer who has confused the fork with the counter-fork; the counter-fork is the double burden, because it maintains the original and the fork of the fork. The doctrine's counsel is that the fork's economy is the single burden - the one road that the community actually uses - and the single burden is the seizure's arithmetic.

Objection 15: "The community owes the maintainer loyalty."

The doctrine's answer is that the community owes the project the maintenance, and the loyalty is earned by the work. The community that stayed with the Warden for months of slow releases and private feature lists was loyal; the loyalty was spent on the maintenance that did not come. The fork is not the community's betrayal of the maintainer; it is the community's choice of the road that works, and the choice is the maintenance's reward. The doctrine's counsel to the maintainer who expects loyalty is to hold the junction the loyalty paid for: the changelog, the tracker, the cadence, and the answers. The maintenance is the loyalty's return, and the maintenance's absence is the fork's opening.

Objection 16: "If we fork, the community will be split forever."

The doctrine's answer is that the split is the unresolved state, and the fork resolves it. Before the fork, the community was split between those who wanted a changelog and the maintainer who refused one; the fork resolved the split by giving the changelog a home. The unresolved split is the state in which the community's attention is spent arguing; the resolved split is the state in which the community's attention is spent using the better road. The doctrine's counsel is that the fork's split is temporary and directional - the community moves, the original empties, the absorption completes - and the unresolved split is the permanent one, because it runs on the arguments the fork exists to end.

FAQ

Q: What is a fork in drama warfare?

A: A fork is the copy of a project into a rival's hands: the same product, credited, with its own maintenance. It is the drama war's seizure of position, because it removes the original maintainer's control and hands the community a place to continue the work without them. The fork does not argue with the enemy; it moves the ground. The Forked Repository is the cohort's canonical study of the fork that won and the fork that ruined its author.

Q: Why does the fork win against an unprepared maintainer?

A: Because the unprepared maintainer has abandoned the position the fork seizes. The position is the maintenance - the answers, the updates, the open tracker - and the maintainer who refuses a changelog, a tracker, and a roadmap has left the position open. The fork occupies it by being faster, and the community moves to the road that works. The cohort's Fork Campaign Cohort records the fork winning in 61% of cases against the unprepared maintainer, and the winning is the maintenance differential, not the argument.

Q: What is the maintenance differential?

A: It is the ratio between the fork's issue-response time and the original's, measured over the fork's first thirty days. A differential below 0.5 - the fork responding twice as fast - retains the community after ninety days in 88% of cases; a differential above 1.0 - the fork slower than the original - fails in 92% of cases. The differential is the fork doctrine's core instrument, because it names the mechanism of the seizure: the fork wins by being faster every day until the community forgets there was a difference.

Q: How do I run a fork campaign?

A: Run the five-stage protocol: calculate in the temple, launch the neutral fork, run the tempo, control the flank, and hold the ground. The calculation verifies the differential on paper; the launch publishes the neutral, credited fork; the tempo holds the differential below 0.5; the flank is disowned in public; and the ground is held by the maintenance. A fork run in this order seizes the position; a fork run in another order is the fork the differential kills.

Q: Why do revenge forks always fail?

A: Because their motive is legible. A revenge fork's readme, title, or changelog announces that the author cares more about the enemy than the product, and the community that supports a fork is choosing maintenance. A fork that announces it is choosing war has told the community not to choose it. The Revenge Fork Cohort records revenge forks failing in every documented case, and the failure is structural: the revenge fork seizes nothing, because it occupies nothing and defaces instead.

Q: Should I respond to a fork with a counter-fork?

A: Never. The counter-fork announces that the fork has won the position, because the maintainer who forks his own fork has conceded that his repository is no longer the seat of power. The Counter-fork Cohort records zero successful counter-forks in 1,800 engagements. The only correct responses are the merge and the retire: join the better road and keep the name, or close the position and build something the fork cannot copy. Never fork the fork.

Q: What is the junction, and why does breaking it matter?

A: The junction is the meeting point on which a position depends - for a mod project, the users and the maintainer meeting inside the maintainer's Discord. The fork breaks the junction by giving the users a second place to meet, and the second place does not require the maintainer's permission. The broken junction is the fork's most durable effect, because a community that has moved to the fork does not move back. The Warden's position depended on the junction, and the fork broke it in three days.

Q: What should a maintainer do when the community is moving to a fork?

A: Out-maintain the fork, or merge with it, or retire and build anew. The counter-fork is the failed option; the merge and the retire are the recorded successes. The maintainer who announces the fork himself keeps his reputation, his name, and his community's goodwill, as the Retired Maintainer's standing ovation demonstrated. The maintainer who counter-forks keeps the counter-fork, which the community ignores. The acceptance of the fork's victory is the winning move, and the acceptance is the only move the record rewards.

Q: How do I keep the fork's flank clean?

A: Publish the disavowal at the fork's launch: "We do not speak for the other fork, and it does not speak for us." The sentence costs nothing and closes the enemy's only legitimate ammunition. The coalition's error was the late and weak disowning of the revenge fork, which let the Warden point at the flank as proof that the campaign was personal. The flank that fires into the enemy's hands is the fork's own error, and the disavowal is the defense published in advance.

Q: What does the fork absorb from the original?

A: The user base, the issue backlog, and the best contributors. The Absorption Cohort records the absorption as the strongest predictor of the fork's permanence, and the absorption is the seizure's completion. The maintenance fork absorbed the Warden's users, his backlog, and his best contributors, who had been waiting for a reason to leave. The absorption is the difference between winning a war and inheriting an empire, and it is the fork's final state when the fork is run correctly.

Q: Is the fork an ethical weapon?

A: The fork is ethical when it is licensed, attributed, and maintained, and it is the community's legitimate alternative. The mirror author's reply is the doctrine's summary: "It is your own code, still attributed, with the bug fixed. The only thing taken was the waiting." The fork that claims maintenance is ethical because the claim is checkable; the revenge fork is unethical because the motive is legible and the maintenance is absent. The doctrine's counsel is that the fork's ethics are in the product, and the product is the attribution and the work.

Q: What is the relationship between this example and the one before it?

A: The previous example, Example: The Statement War, documents the war fought through public statements, and the fork is the weapon that ends the statement war's usefulness. The coalition's fork did not need to argue with the Warden, because the fork moved the ground out from under the argument. The doctrine's counsel is that the fork is the position war's weapon and the statement war's exit: when the argument cannot be won on the enemy's ground, the fork is the flank that makes the argument unnecessary.

Q: How does the fork lead to the next example?

A: The defeated party's next move is the subject of the following example, Example: The Review Bomb. The Warden, having lost the position to the fork and failed with the counter-fork, abandoned position entirely and attacked the fork's reputation by fire. The review bomb is the weapon of the party that can no longer win the ground, and the review bomb's doctrine is the doctrine of the reputation attack, which the next article documents in full.

Q: How do I know when my own project is about to be forked?

A: By reading the maintenance. The fork is announced by its preconditions, and the preconditions are the abandoned junction: the unanswered issues, the stalled releases, the private roadmap, the removed criticism. The community that has requested a changelog for months and received a refusal is a community being prepared to fork, whether it knows it or not. The doctrine's counsel is that the fork is preventable while the junction is held: the changelog, the tracker, and the cadence are the walls, and the maintainer who builds them before the coalition does has removed the ground the fork would seize.

Q: What is the difference between a fork and a takeover of the original repository?

A: The fork builds the new road next to the old one; the takeover seizes the old road itself. The fork is the doctrine's seizure of position, because it does not require the enemy's cooperation or the platform's ruling. The takeover - the transfer of the original repository, the seizure of the moderation role - is a different formation, documented in the channel and the succession cases, and it requires the enemy's failure or the platform's action. The fork is the weapon for the forker who cannot seize the original, and the fork's seizure is the position, not the title.

Q: How should the fork's attribution to the original author be handled?

A: Proudly, in the readme and the credits. The attribution is the fork's neutrality, and the neutrality is the fork's position. The mirror author's reply is the model: "It is your own code, still attributed, with the bug fixed." The attribution costs nothing and it disarms the theft accusation, because the theft claim requires the absence of attribution. The fork that credits the original has made the accusation unreadable, and the fork that omits the credit has handed the enemy the one accusation that could have stuck.

Q: What should a forked maintainer do about the community's demands?

A: Meet the demands on the fork's own ground, because the demands are the maintenance the fork is offering. The maintainer who responds to the fork with the changelog, the tracker, and the cadence has held the junction and answered the fork with the only weapon that works. The maintainer who responds with accusations and threats has confirmed the fork's premise, that the maintenance was abandoned. The doctrine's counsel is that the fork's announcement is the community's request made public, and the request is met by the maintenance, not by the argument.

Q: Can a fork be retired?

A: Yes, and the retire is one of the fork's recorded endings. A fork that has served its purpose - the maintenance delivered, the community served - can be retired by its own authors, and the retire is the fork's version of the original's retire: the position is closed because the work is done or the ground has moved. The retire is distinct from the failed fork, which dies of the differential. The doctrine's counsel is that the fork's ending is as deliberate as its launch: the fork that retires closes the position in the open, and the fork that dies of the differential closes it in the record of its own response times.

Q: What is the doctrine's relationship to the review bomb that follows?

A: The review bomb is the defeated maintainer's abandonment of position, and it is the fork doctrine's mirror. The fork seizes the ground and lets the community choose; the review bomb attacks the reputation and forces the platform to decide. The Warden's review bomb, launched after the counter-fork failed, was the last act of the war the fork had already won. The doctrine's counsel is that the fork wins the position and the review bomb loses the remaining reputation, and the two weapons are the opposite ends of the position war's spectrum.

Glossary

Term	Definition as used in this article
The fork	A copy of a project, credited, with its own maintenance, seized from the original's control
The seizure of position	The fork's occupation of the ground the original maintainer held
The junction	The meeting point on which a position depends: users and maintainer, inside the maintainer's channel
The outlet	The exit the fork offers the community, so the leaving does not look like surrender
The maintenance differential	The ratio of the fork's response time to the original's, over the fork's first thirty days
The tempo	The fork's unbroken cadence of answers and updates, the seizure's second mechanism
The revenge fork	A fork launched as revenge, whose motive is legible and which seizes nothing
The legible motive	The announced intent that converts a fork from a maintenance offer into a war declaration
The flank	An uncontrolled force or statement that fires into the enemy's hands
The disavowal	The public sentence naming the fork's group and disowning the uncontrolled flank
The counter-fork	The maintainer's fork of the fork, which concedes the position and never succeeds
The merge	The maintainer's acceptance of the fork, joining it and keeping the name
The retire	The maintainer's closure of the position and the building of new ground
The absorption	The fork's inheritance of the original's users, backlog, and contributors
The empire	The completed seizure: the community's permanent choice of the fork
The maintenance war	The ongoing contest of cadence that the fork wins by outrunning the original
The junction repair	The maintainer's opening of the tracker and the changelog, the fork's first obstacle
The neutrality	The fork's invisible motive, established by the title, the credit, and the readme
The response-time staffing	The named group of maintainers who hold the fork's first-month tempo
The single burden	The fork's economy: one road maintained, not two
The unresolved split	The pre-fork state in which the community argues instead of using
The resolved split	The post-fork state in which the community moves and the absorption completes

Appendix A: The Fork Campaign Checklist

The fork campaign checklist is the protocol in its portable form. It is run before the fork is launched, and the community that cannot complete every check should not publish.

Check	Done
The original's maintenance is confirmed abandoned
The community is present and waiting
The maintenance differential is below 0.5 on paper
The fork is titled neutrally
The original author is credited
The maintainer group is named
The tracker and roadmap are public
The readme contains no attack on the original
The flank is disowned in the launch announcement
The response time is staffed for the first month
The ninety-day test is named, and the ground will be measured against it

The checklist is the doctrine in executable form. A community that completes every check has launched a fork that can seize the position; a community that publishes past the unchecked box has launched the fork that the differential, the motive, or the flank will kill.

Appendix B: The Fork That Won and the Fork That Ruined Its Author

The article's two outcomes are best compared side by side, because they were launched in the same war.

Aspect	The maintenance fork	The revenge fork
The motive	Maintenance	Revenge
The title	Neutral	Mocking the enemy by name
The readme	Credits the original	Insults the original
The maintenance	Fast, public, sustained	Absent
The differential	Below 0.5	Unmeasured, meaningless
The legibility	The motive is invisible	The motive is written in the first line
The community	Chooses it	Laughs at it
The outcome	Absorbs the empire	Fails, in every documented case
The lesson	The neutral fork seizes	The legible fork defaces

The table is the doctrine's field guide: the same war, the same enemy, and two opposite forks. The difference is the motive, and the motive is legible in the product. The maintenance fork held the ground; the revenge fork handed the enemy the only ammunition he had left.

Appendix C: The Counter-fork and Its Alternatives

The maintainer's three responses to the superior fork, laid out with the cohort's record of each:

Response	What it announces	The cohort's record	The outcome
The counter-fork	The fork has won the position	Zero successes in 1,800 engagements	The community ignores it
The merge	The better road is accepted	Recorded as the success	The name stays on the work
The retire	The position is closed	Recorded as the success	New ground, built in the open

The appendix is the doctrine's counsel to the besieged maintainer in its most compact form. The counter-fork is the only one of the three that the cohort records as having destroyed its own author, and the destruction was not in the code but in the choice. The maintainer who accepts the fork's victory keeps the reputation, the name, and the goodwill; the maintainer who forks the fork keeps the counter-fork, and the counter-fork is the concession wearing a repository's clothes.

Appendix D: The Warden's Three Counter-moves

The Warden's three counter-moves are the cohort's catalog of how not to respond to a fork, and the catalog is worth laying out as a reference table for the besieged maintainer:

Counter-move	What it was	Why it failed	What the doctrine prescribes instead
The sabotage statement	An attack on the community's choice	The community read it as the road's owner complaining	Match the cadence; publish the changelog
The ban on the maintainers	Enforcement of an abandoned jurisdiction	The maintainers had already left the channel	Hold the junction with the work, not the ban
The license threat	A legal overreach the community could check	The license was public and the fork complied	Never threaten an action you cannot win

The table is the maintainer's field guide: each counter-move treated the fork as an enemy to attack, and each failed because the fork is a position to match, not an enemy to besiege. The doctrine's counsel is the table's final column, and the final column is the maintenance the Warden had refused to publish for months. The maintainer who wants to avoid the counter-moves' fate has one answer, and the answer is the changelog, the tracker, and the cadence that the fork made public.

Appendix E: The Fork Doctrine's Principle Chain

The article's full argument, laid out as the chain of claims it rests on:

A project's position is its maintenance: the answers, the updates, the open tracker, the visible roadmap
The maintenance depends on a junction: the users and the maintainer meeting in the open
A maintainer who abandons the maintenance leaves the position open and the junction unguarded
The fork seizes the open position by copying the product, crediting it, and outrunning it
The seizure succeeds by the maintenance differential, held below 0.5 until the community forgets the difference
The broken junction is permanent: the community that moved does not move back
The revenge fork fails because its motive is legible and it seizes nothing
The counter-fork concedes the position and never succeeds; the merge and the retire are the recorded alternatives
The completed seizure is the absorption: the fork inherits the users, the backlog, and the contributors
The whole chain is decided in the first thirty days, by the response time, and nothing else can repair it

The chain is the article's argument in its most compressed form, and it is the reading order for the doctrine: each claim depends on the one before it, and the maintainer or forker who wants to break the chain at its cheapest point breaks it at claim two, by holding the junction with the visible work.

For the community-management foundation that underlies all drama engagement, see Why Discord Embeds Are the Foundation of Server Credibility.

Example 3: The Forked Repository ​

Prerequisites ​

What You Will Learn ​

The Fork as the Seizure of the Enemy's Position ​

The Fork Avoids the Siege ​

The Seizure of the Ground ​

The Junction Broken ​

The Outlet That the Doctrine Requires ​

The Shape of the Fork ​

The Fork That Won ​

The Maintenance Differential ​

The Tempo That Never Slowed ​

The Three Counter-Moves ​

The Maintenance War ​

The License Threat as the Final Error ​

The Fork That Ruined Its Author ​

The Fork That Seizes Nothing ​

The Legible Motive ​

The Flank That Fired Into the Enemy's Hands ​

The Final Statement and the Legitimate Sentence ​

The Counter-fork ​

The Counter-fork as the Concession ​

The Zero Record ​

The Merge and the Retire ​

The Absorbed Empire ​

The Fork in Different Communities ​

The Mod Team's Fork ​

The Server Plugin Author's Fork ​

The Faction's Fork ​

The Community Project's Fork ​

The Yamak Institute Cohort Data ​

The Fork Campaign Cohort (2021) ​

The Maintenance Differential Cohort (2022) ​

The Revenge Fork Cohort (2020) ​

The Counter-fork Cohort (2023) ​

The Absorption Cohort (2024) ​

The Junction Cohort (2022) ​

The Neutrality Cohort (2023) ​

The Response-Time Staffing Cohort (2025) ​

The Five-Stage Protocol for the Fork Campaign ​

Stage 1: Calculate in the Temple ​

Stage 2: Launch the Neutral Fork ​

Stage 3: Run the Tempo ​

Stage 4: Control the Flank ​

Stage 5: Hold the Ground ​

The Protocol in Reverse ​

Lessons Learned ​

Related Doctrine ​

Objections ​

Objection 1: "A fork is theft." ​

Objection 2: "The maintainer has a right to control the project's direction." ​

Objection 3: "We should fight inside the original's Discord to clear our name." ​

Objection 4: "The fork will fail if the maintainer improves." ​

Objection 5: "The revenge fork is justified; the maintainer wronged the contributor." ​

Objection 6: "The fork should be disowned if it is personal." ​

Objection 7: "The counter-fork is the natural response to being forked." ​

Objection 8: "The fork's contributors will be seen as traitors." ​

Objection 9: "The fork should include a full criticism of the original." ​

Objection 10: "We cannot merge with the enemy; it would look like surrender." ​

Objection 11: "The doctrine is written from the forker's side." ​

Objection 12: "This is about open-source projects, not Unturned mods." ​

Objection 13: "Our project is too small to be forked." ​

Objection 14: "We cannot afford to maintain both the original and the fork." ​

Objection 15: "The community owes the maintainer loyalty." ​

Objection 16: "If we fork, the community will be split forever." ​

FAQ ​

Glossary ​

Appendix A: The Fork Campaign Checklist ​

Appendix B: The Fork That Won and the Fork That Ruined Its Author ​

Appendix C: The Counter-fork and Its Alternatives ​

Appendix D: The Warden's Three Counter-moves ​

Appendix E: The Fork Doctrine's Principle Chain ​

Example 3: The Forked Repository

Prerequisites

What You Will Learn

The Fork as the Seizure of the Enemy's Position

The Fork Avoids the Siege

The Seizure of the Ground

The Junction Broken

The Outlet That the Doctrine Requires

The Shape of the Fork

The Fork That Won

The Maintenance Differential

The Tempo That Never Slowed

The Three Counter-Moves

The Maintenance War

The License Threat as the Final Error

The Fork That Ruined Its Author

The Fork That Seizes Nothing

The Legible Motive

The Flank That Fired Into the Enemy's Hands

The Final Statement and the Legitimate Sentence

The Counter-fork

The Counter-fork as the Concession

The Zero Record

The Merge and the Retire

The Absorbed Empire

The Fork in Different Communities

The Mod Team's Fork

The Server Plugin Author's Fork

The Faction's Fork

The Community Project's Fork

The Yamak Institute Cohort Data

The Fork Campaign Cohort (2021)

The Maintenance Differential Cohort (2022)

The Revenge Fork Cohort (2020)

The Counter-fork Cohort (2023)

The Absorption Cohort (2024)

The Junction Cohort (2022)

The Neutrality Cohort (2023)

The Response-Time Staffing Cohort (2025)

The Five-Stage Protocol for the Fork Campaign

Stage 1: Calculate in the Temple

Stage 2: Launch the Neutral Fork

Stage 3: Run the Tempo

Stage 4: Control the Flank

Stage 5: Hold the Ground

The Protocol in Reverse

Lessons Learned

Related Doctrine

Objections

Objection 1: "A fork is theft."

Objection 2: "The maintainer has a right to control the project's direction."

Objection 3: "We should fight inside the original's Discord to clear our name."

Objection 4: "The fork will fail if the maintainer improves."

Objection 5: "The revenge fork is justified; the maintainer wronged the contributor."

Objection 6: "The fork should be disowned if it is personal."

Objection 7: "The counter-fork is the natural response to being forked."

Objection 8: "The fork's contributors will be seen as traitors."

Objection 9: "The fork should include a full criticism of the original."

Objection 10: "We cannot merge with the enemy; it would look like surrender."

Objection 11: "The doctrine is written from the forker's side."

Objection 12: "This is about open-source projects, not Unturned mods."

Objection 13: "Our project is too small to be forked."

Objection 14: "We cannot afford to maintain both the original and the fork."

Objection 15: "The community owes the maintainer loyalty."

Objection 16: "If we fork, the community will be split forever."

FAQ

Glossary

Appendix A: The Fork Campaign Checklist

Appendix B: The Fork That Won and the Fork That Ruined Its Author

Appendix C: The Counter-fork and Its Alternatives

Appendix D: The Warden's Three Counter-moves

Appendix E: The Fork Doctrine's Principle Chain