在Chapter 4, 社会和政治的基础架构的the section called “分叉能力（forkability）”，我们说了潜在的分叉能力对于项目管理的重要影响。但是当分叉确实发生时，我们应该怎么做？你应该如何处理，会发生怎样的情况？与之对应，何时你应当开始一个分叉。
答案取决于你选择的分叉类型。有一些分叉源于对于项目方向的友善但不可调和的异议；也有一些由于技术分歧和个人冲突。当然，很难说清楚二者之间的区别，因为技术争论也会包含个人元素。所有分叉的共同之处是有一队开发者（有时仅仅是一个开发者）认为与某些人或所有其他人一起工作的成本已经大于收益。
一旦项目分叉，对于分叉与“原”项目谁是谁非，没有明确的答案。人们会通俗的说分叉F来自于项目P，好像P继续沿着自然路径保持不变，而F则进入新的领域，但这实际上是一个观察者的声明。但这纯属个人感觉：当足够高百分比的观察者认可，这个断言便成为真。并不是说一开始就有一个客观事实，而只是一开始的一个不太完美的感觉。此外，感觉是客观事实，因为最终一个项目—或一个分叉—仅仅是存在于人们思想中的一个实体。
如果开始分叉的人们感觉自己是在建立主项目的一个分支，则感知问题可以立刻轻易的解决。每个人，开发者和用户会将分叉视为新的项目，有新的名称（或许基于旧有的名称，但容易与之区分），一个单独的网页以及单独的哲学或目标。当双方都认为自己是原项目遗产的守卫者，理所当然继续使用原来的名称时，事情会变的复杂。如果某个组织拥有这个名称的商标权，或对于域名或网页有法律控制，通常可以平滑的解决这个问题：这个组织可以决定谁是这个项目，谁是分叉，因为它拥有公共关系战争中的所有卡片。很自然，一般不会如此过分：因为每个人都知道权利动力学，他们会避免一场结局已定的战斗，会直接跳到结局。
幸运的是，大多数情况下可以轻松的区分哪个是项目，哪个是分叉，因为分叉从本质上是一个自信的投票。如果过半的开发者倾向于采纳分叉的过程，通常意味着没有必要分叉—这个项目可以自己走这条路，除非它有一个顽固的独裁者，按照独裁方式运行。另一方面，如果支持者少于一半，则分叉则明显是少数派的反叛，根据礼貌和常识，它应当认为自己是分叉，而不是主线。
如果某人在项目中威胁进行分叉，请保持冷静并牢记你的长期目标。分叉的存在不是对项目的伤害，而是开发者和用户的损失。你真正的目标，不是为了镇压分叉，而是最小化其损害。也许你会生气，你或许感到分叉是不公正和不请自来的，但如果这样公开表示则是对未决定用户的疏远。相反，不要强制人们做出唯一的选择，要与分叉实行可行的合作。首先，不要因为某人决定在分叉上工作，而删除其在你的项目中的提交权限。在分叉上工作并不意味着他立刻失去了在原项目工作的资格；之前的提交者之后还是提交者。此外，你应当展示与分叉保持兼容的愿望，并表达你希望开发者能够在二者之间搬运合适的变更。如果你对项目服务器有管理权限，一开始就公开提供分叉的基础架构帮助。例如，如果他们无法通过其他方法获得，可以为他们提供一个完整的，版本控制库的深度历史副本，这样他们就不必以无历史数据作为开始（必要性取决于版本控制系统）。询问他们是否有其他的需要，并尽你所能提供。这种支持表明了你不会阻挠他们，而且希望该分叉以自己价值成功或者失败，仅此而已。
这样做—以及公开这样做的—原因实际上并不会帮助分叉，但是通过尽可能的展示非报复心态，会使开发者相信你这边是安全带。战争中有时强制人们选择一边非常有意义（战略意义，而不是人的感觉），但是自由软件几乎从不这样做。实际上，分叉后一些开发者会公开的在两个项目同时工作，并尽可能保持二者兼容。这些开发者保持了分叉之后的交流。他们允许您的项目从分叉中有趣的新特征中获益（是的，分支也有你想要的），另外也会增长在未来合并的可能。
有时，某个分支变得异常成功，即使他最初的煽动者也认为他们开始于一次分叉，但成为人人都喜欢的版本，最终由于其流行性取代了最初的版本。一个著名的实例是GCC/EGCS分叉，GNU Compiler Collection（GCC，以前称为GNU C Compiler）是最著名的开源本代码编译器，也是世界上最便于移植的编译器。源于对GCC官方维护者和Cygnus软件的分歧。[29]GCC的一个最活跃的开发团队，Cygnus创建了一个GCC的分叉，称为EGCS。该分叉谨慎保持非敌对位置：从任何角度看，EGCS开发者从没有试图把他们版本的GCC描绘成新的官方版本。相反，他们集中精力使EGCS尽可能的好，比官方的GCC维护者以更快的频率整合补丁。EGCS受到了欢迎，最终一些主流的操作系统发布商决定将EGCS而不是GCC作为打包产品的默认编译器。此刻，对于GCC的维护者很清楚，坚持“GCC”的名称，而让所有人切换到EGCS分叉上需要每个人承受毫无必要的名称修改负担，对防止切换毫无意义。所以GCC采用了EGCS的代码基，再一次只有一个GCC，但因为分叉获得了极大的改进。
这个例子向我们展示了为什么不能单纯的将分叉视为一件坏事。分叉时可能充满痛苦和不受欢迎，但你不能必然知道它是否会成功。因而，你和项目的余下部分要一直留意它，不仅仅要准备好吸收可能的特性和代码，在极端情况下，如果分叉获得了项目的精神占有率，甚至需要加入分叉。当然，通过观察谁加入了分叉你也能预测到其成功的可能性。如果分叉由项目最大的抱怨者开启，并有少数不满的看起来起不到建设作用的开发者加入，他们将无法通过分叉解决问题，你也无须担心分叉会将原项目的动力带走。但是如果你看到有影响和令人尊敬的开发者支持这个分叉，你必须问自己这是为什么。或许整个项目被限制了，最好的方案是在主线项目采纳一些分叉打算的行动—从本质上，通过变成它而避免分叉。
这里的所有建议假设你将分叉作为最后的依靠。初始分叉前耗尽了所有的可能性。分叉总是意味着丢失开发者，只留下一个不确定的在以后获得新产品的承诺。它也意味着开始了对用户注意力的竞赛：每个下载这个软件的人都会问自己：“哦，这个还是那个？ ” 无论你是哪个，情况也是肮脏的，因为出现了原本不存在的问题。一些维护分叉的人们会维护软件的整体生态系统的健康，通过标准的自然选择论点：适者生存，意味着最终每个人得到更好的软件。从生态学的角度这或许是正确的，但对于单个项目来说则并不正确。大多数分叉并不成功，大多数项目不喜欢被分叉。
一个推论就是不要使用分叉的威胁作为极端的辩论技巧—“按照我的方式，否则我要将项目分叉！ ”—因为每个人都会意识到如果是无法吸引开发者离开原项目的分叉，不太可能长久存活。所有的观察者—不仅是开发者，还有用户和操作系统打包者—会对选择哪一方做出自己的判断。你不必表现出极端不情愿分叉，这样如果你最终这样做了，你可以光荣的宣布这是最后一条路。
在评估你的分叉成功可能性时，不要忽视所有的因素。例如，如果项目的许多开发者都有同一个雇主，那么即使他们不满且私下里倾向于分叉，也不太会大声说出他们的雇主是赞成还是反对。许多自由软件程序员以为如果代码有自由许可证，那么没有哪个公司可以控制开发。许可证确实如此，是一种终极意识，自由的保障—如果其他人强烈的希望分叉项目，并有足够的资源，它可以这样做。但是在实践中，一些项目开发团队大多由一个实体资助，没有证据说明这些实体的支持无关紧要。如果他们反对分叉，他们的开发者不会离开，即使私下里希望如此。
如果你还是确认必须分叉，最好首先私下联络好支持，然后使用不含敌意的语调宣布分叉。即使你对当前的维护者感到愤怒，或者失望，不要在这些信息中写出来。只需要不露声色的陈述导致你决定分叉的动机，以及你对所分叉原项目并无敌意。假定你考虑一次分叉（相对于对原项目的紧急保存），强调你分叉的是代码而不是名称，并选择一个与原项目不会冲突的名称。你可以使用一个包含或引用原名称的名称，只要不会造成识别上的混淆。当然，在分叉的主页上也可以突出解释其来自的原始程序，甚至对于替代它的期望。但是不要迫使用户解开识别争议，给他们带来额外的麻烦。
最终，通过为原项目的所有提交者，包括那些公开反对分叉的提交者赋予提交权限，就可以自动让事情开始运转。即使他们不会访问，但你的信息是明确的：这里存在争议，但是没有敌人，你欢迎来自所有竞争源的代码贡献。