最近看到有人将一年前fork了ServiceComb Pack项目开源，做了很多匪夷所思欲盖弥彰的事情，于是写了这篇文章希望能对大家有所启发。
随着Github的兴起，我们很容易就是能在别人的代码基础上通过fork的方式创建自己的项目，但是为什么我们还是希望把我们的代码提交到上游代码库中？今天的文章就是想跟大家探讨一下这样的做的好处。
-
把代码修改合入上游，维护成本最低的协作方式。
开源项目的有很多的贡献者，大家之所以能够在一起协作的根基是代码开放的， 每个人都可以在别人的基础上添加自己的工作。但这样做有几个前提就是大家相互的修改不应该产生副作用，或者说我们需要有一个协调机制保证大家的代码放在一起还能够工作。 如果大家把代码都提交到上游项目中，在提交合并的过程中就解决了冲突问题，这是最省力也是最有效的协作方式。
Fork上游代码看上去挺简单的，但是从fork的那天开始你就要背负维护这个fork版本的生老病死的所有的责任。一旦你的代码和上游代码脱离的关系，就无法享受到上游代码更新带来的好处。 明智的人往往会在自己修改代码之后，努力将自己的修改推进上游代码以降低自己的维护成本。
-
随时可以使用上游代码的最新更新。
上游项目发布新版本了，我能在第一时间将上游项目集成到我的扩展项目中吗？这个和你如何引用上游代码有很大的关系。 一般来说如果你只是片段引用上游代码或者直接fork上游代码， 你需要自己做所有的修改适配。如果上游项目发展不是很快的话，你可以能花几天的时间就适配好了，但是如果项目发展很快，三个月出一个版本的话，你的适配步伐很难跟上上游的开发速度的。 一般来说fork版本的维护只有一个人， 而上游的开发可能是4~5个人， 同时社区还会有很多贡献者也在合入代码， 在这种情况下，上fork之后的版本往往采用的方式就是不会合入上游新开发的特性和功能的而自己独自地走下去。
如果你还想继续享受到上游开发带来的好处， 请将你的代码回合到上游代码中，因为这样做你仍然可以以0成本的方式继续使用上游代码。
-
可以让更多的人受益，推动项目成功。
众人拾柴火焰高， 一个成功的开源项目背后必然有一个蓬勃发展的社区。依托于社区我们可以做到很多平时一个人在公司无法实现的目标。 在开源项目社区中，大家共同的目标就是把这款开源软件做得更好。这里有用户报系统的bug，有贡献者将自己的使用心得转换成patch提到社区中了，有维护人员不断的添加新的功能并及时得到用户的反馈而又继续开发更炫酷的功能。开源项目依托于社区只所以可以不断发展壮大，正因为大家是相互协作的，力气都往一处使，每个人在贡献自己的力量的同时也为大家节省了很多开发协作的时间，依托于一个社区大家可以共享工作成果。 假如你想借助开源完善丰富你的产品的话，维护一个统一的社区比将社区分裂独自维护要简单很多。
最后说一下，fork别人的代码需要尊重别人的知识产权， 不能随意修改相关源文件的License header声明。具体的内容大家可以参考Linux Foundation专门给开源开发者开发的免费合规课程，同时在Apache软件基金会的License指导说明里面也有相关的描述。 要知道开源代码也是有知识产权的，如果你在一段不是你写的代码上面加上你的copyright，那就相当于对外宣称你是这段代码的作者， 这样行为很容易就被扣上抄袭的帽子。特别是如果你把fork的代码又开源的，虽然你保留的之前的提交记录， 并且在README上面也说了这是基于别人的代码修改出来的， 但是这不能成为掩盖你将他人工作成果宣称是自己工作成果的事实。