企业软件团队如何与上游开源项目团队维持健康的协作关系一直是业界的热门话题。OSChina编辑部作者Lola用翔实的案例介绍了「上游优先」原则是什么，并表示「（上游优先）与善良无关，这是一种开放协作的必要态度，甚至是一种话语权的争夺，你行动了，在社区中赢得了声望和影响力，社区信任和尊重你，你的决策有了分量，这才是开源原本的样子。」
在开源中国写文章这么久，常常会自我怀疑。总会有一些读者会留下诸如「开源就应该免费」这样一听就想和他约架的评论，这些评论像一记记重锤锤在小编脸上，让小编不禁自问：这些年的文章难道都白写了吗？
开源的一些常识性原则，我们好像懂了，又好像没懂。这种令人恼火的情况，还经常出现在开源另一个重要的原则——「上游优先」（UpstramFirst）上。这一原则，反复出现在一些开源布道师的口中，有点苦口婆心的意思了。
什么是「上游优先」？相信大家看字面意思也gt到了一大半了，一旦你有fork的动作，你所fork的那个项目就是你的上游。而上游优先则是一种鼓励你直接与开源社区互动并从源头解决问题的工作方式。
与「上游优先」相关有一个有趣的故事。当时，红旗Linux还没倒闭，还是国产Linux版本的标杆，内部针对要不要采用「上游优先」产生了争议，这给当时还在红旗Linux任职的李建盛带来了冲击：
彼时许多国产Linux发行版只自顾自进行孤岛式开发。但是，比如说我在一个包里面添加了一点功能，半年之后，却发现上游比我做的东西更多，而且更完善，甚至一些bug人家很早就已经修复了，修复得很好，还加了fatur。那我不得不把自己原来做的工作全废掉，然后把上游那个包再拿过来。
无疑，李建盛是认为有必要「上游优先」的，而大环境让他感到无力。几年后，李建盛成为国内少有的全职开源文化布道师，在接受OSCHINA采访时，他表示那场争议几乎是他开源职业道路上的分叉口。
对此颇有同感的还有今年刚被选举为ASF（ApachSoftwarFoundation）董事的姜宁，同样是在OSCHINA的采访中，姜宁表示：
观念的转变是最难的。国内大部分的开源参与者都是搭便车的心理，只是把开源当成免费的、能让他快速交活的工具。把东西拿来用，用的过程出问题了，要么在社区问一下，要么自己埋头修一修，修完了也不回馈上游。大家不习惯和上游社区进行任何交互。
姜宁将这些难题归结于观念问题，是大家缺乏了开放式协作的意识。而除了扭转观念，要想在实践层面上做好这一原则，我们要走的路则更长。
01我可以不反馈上游吗？答：看实力
实际上，无论是哪个开源许可证都没有规定必须「上游优先」。其他宽松的许可证就不用说了，就算是最强力的GPL所要求的也只是：「分发时一定要提供源代码。」
这里的「提供源代码」，是指当用户想要得到源码时，他有途径获得。它没有指定你非要反馈回上游，更谈不上上游优先了。
那么，在没强制也没规定的情况下，我们为什么还要去做反馈上游的事呢？这个问题其实已经被不少开源布道者论述过，比如之前提到的姜宁和李建盛。他们的论点基本上是围绕以下3点的：
1）降低自己的维护成本。
一旦fork，就意味着与上游脱钩，不再参与上游的维护和更新，而fork者则要负责fork版本的生老病死。然而，这个代价要比想象中大得多。而且，就算这些维护成本你都能扛下来了，大概率也是重复造轮子。
但你把修改回馈给上游就是另一码事了，一旦被合并，所有维护都是上游在承担，立马解放双手。
）方便下次使用上游更新。
如果你想要使用上游更新的新版本，你需要在自己的分支上做适配，更新得越快，适配工作量越大。但如果你自己的代码本来就在这条「主干线」上，你就可以零成本享受到。
3）不要单兵作战，多和上游交流。
深度参与开源，你的确有必要和上游有所交流。交流也正是开源的魅力所在，你不再孤独，而是在众多有相同兴趣爱好的开发者中交流探讨。越往上游交流，你越可能联系到项目创始人甚至你的偶像，也许你还会奇妙地发现他们还挺乐于助人的。
在这一层面上，分支的主体是「个人」。我一个人力量有限，即使分支了顶多也是个沟渠，很快就会干枯。最好也是最明智的做法是，拿出分享精神，带着自己的代码，到上游去，找到组织。
但落在组织和集体层面，则可能另一种局面：这种fork不是意外，而是带有某种特定目的，比如南非富豪MarkShuttlworth为了实现梦想，从Dbian分叉出了Ubuntu；又比如MySQL创始人因为甲骨文的收购一气之下分叉出MariaDB。
这些分叉后来散发出了不可小觑的力量，丰富了开源项目的版图。他们的逻辑是，直接创建一个新的社区，不按上游社区的逻辑走了，修改之后照样发新版本，打出自己的特色，自己成长为一条浩荡大河。
但实际上，在国内更常见的一种情况是公司层面的「拿来主义」。开发人员并没有什么理想主义的目的，而仅仅是为了完成任务，比如说老板要一个XXX的解决方案，给了几个月时间和几十万预算，于是项目经理直接从上游项目拿来，花些时间修改变成了这个解决方案。
这个项目没有任何反馈上游的动力，区区预算也没有维护和支持的能力。从长远上看，这种做法是毫无意义且浪费成本的。
因此，把以上3种情况都捋清楚了以后，「我们需要反馈上游吗？」这个问题瞬间就变成了「我有实力不反馈上游吗？」。
如果没有，请接着往下看。
0有实力，但为什么还要上游优先？
「我觉得GPLv是一个非常棒的协议，我喜欢它的理由很简单：我给你源代码，你给我你的修改，我们就扯平了。」
——Linux之父LinusTorvalds
打一开始，Linus就想得很清楚，他需要一个机制，这个机制能确保下游的修改能够被反馈到自己手上。我们没法回溯「上游优先」最先被提出的那个时间点，但有一点是可以确定的：包括Linux内核社区在内的许多社区都在沿用并遵守这一「开源潜规则」。
年Linux内核社区一场围绕「上游优先政策」的讨论中，Linus明确表示：绝不可能停止实施「上游优先」政策。
后来，Linux基金会也曾在公共场合表示过「上游优先」的重要性，认为如果（代码贡献者们）没有这种（社区）自律，内核早就在自重下崩溃了。
00年，Linux基金会发布了一份报告，呼吁用开源的方式解决「技术债」（tchnicaldbt）。该报告指出一旦项目累积有技术债务，就会出现交付时间拉长、安全问题增多、维护任务变重、无法与上游同步等症状和不良影响。而他们给出的解决方案则是「开源」，这里的开源最重要的原则就是「上游优先」。
与上游保持一致的开发脚步，几乎可以避免绝大多数的技术债务。当然，这需要你积极活跃地参与到上游项目中去。
你无法强制上游向对你有利的方向发展，但你可以通过贡献和分享去影响上游，这样上游和其他贡献者才会渐渐明白你的需求何在。
集成上游开源项目的开发流程
以上是来自上游的呼吁。而有实力的下游在分叉很久之后，「迷途知返」重新与上游加强联系的例子也不是没有。其中，最有名的要数谷歌的Android开发社区。
众所周知，Android的最底层是Linux内核，而从最上游的Linux内核到各种五花八门的Android设备终端这个链条中，利益相关者众多，往往会经历多次分叉，而且还会加上一堆特定的更改。高通、三星等等SoC供应商们基本会为每个主要芯片版本制作一个特定于SoC的内核，然后每个内核都会获得特定设备的硬件支持。
这导致Android的内核碎片非常混乱。Android.