软件开发中的上游upstream

什么是”上游”

上游这个词本身来自于河流，意思是理源头较近的地方，也有相对的意思，在河流的任意两点，相对理源头较近的地方就是上游，否则，称之为下游。

在非软件技术领域，如供应链等，则指的是诸如原材料等生产过程较原始的阶段或本成品。

我们这里的上游，特定指的是开源项目，如Linux Kernel、Kubernetes、Docker、Hadoop、Kafaka等，由最初的发起者或非营利性组织的社区所维护，其他人可以自由的为原始项目（上游）做贡献，诸如提交代码、撰写文档、测试、设计等，然后，按照一定的规则，接受贡献或者拒绝，继而形成更大、更完善、能够解决更多问题的软件项目或产品。

“下游”又指的是什么？

其实，开源软件的项目上、下游也是相对的概念。所谓的下游，指的是某个开发者或某个团队，fork了上游的代码，形成了自己的分支，自行维护分支的更新，即相对于原初的开发者或社区，形成了自己的产品。项目产品的bug、安全漏洞、文档等统统都由自己维护。

下游如果发展良好，可能形成自己独特的分支，如Ubuntu之于Debian，OpenShift 之于 Kubernetes。

上游优先(upstream first)是什么

直接与开源社区互动并在源头上解决问题的办法，被称为上游优先（Upstream first）。

所谓上游，是一个相对的概念，意为“靠近源头的一方”。在开源社区中，主要指的是开源社区维护的主干版本。而所谓下游，是指基于上游开源项目衍生出的项目或产品。在 Github、Gitee 等代码管理平台中对开源项目的 fork 操作，就是一种对上游代码的拓展。

那么，上游优先就很好理解了：基于开源项目的任何修改都应该提交优先提交给上游项目本身，然后再包含在自己的产品中。与之相反的处理方式是只基于自己产品进行维护，对上游不做反馈。

为什么要使用“上游优先”？

上游优先是开源社区提出的优秀的开源理念，那么它优秀在哪里呢？

举个简单的例子：

葵花派长老将葵花点穴手传授给了白展堂和祝无双，在每次施展葵花点穴手时，都需要大喊一声：“葵花点穴手！”

这一天，长老对两人说：堂堂、双双，你们修炼已经圆满，为师已经没有什么能够传授给你们的了，各自下山游历吧！说罢便闭关修炼去了。

白展堂来到了同福客栈，因为葵花点穴手需要念五个字，被郭芙蓉四个字的排山倒海打得鼻青脸肿。

正所谓人总是在被虐中成长，白展堂发现使用一种手法只需要喊“葵花点”就可以施展武功，终于打败郭芙蓉。

随后，白展堂回到葵花派，将这种手法汇报给了长老，长老飞鸽传书，告知了所有门派弟子。

葵花派从此发扬光大，双双成为了衙门的捕快，各大弟子也都成为了惩恶扬善的侠客！

那么问题来了：如果白展堂没有将这种手法告知长老，会怎么样呢？

有两种可能。

其一，白展堂此生未收徒，葵花派因“葵花点穴手”需要念五个字，逐渐式微，从此江湖再也没有葵花派的威名。

其二，白展堂广收门徒，每日传授和教导子弟，将“葵花点”手法发扬光大，但每日忙忙碌碌，不仅要教导弟子学习“葵花点”手法，还要回葵花派学习长老闭关研习出来的新武功。

说到这里，我想大家已经明白了我所要表达的意思了。

白展堂研究出“葵花点”的手法后，回门派告知长老，这种行为就是“上游优先”。

为什么要使用“上游优先”？相信从这则小故事不难看出：

• 利于上游合并：随着时间的推移，下游的修改越晚反馈给上游，上游变越难合并下游的修改。
  • 假如白展堂在临死前再将“葵花点”手法告知门派，门派的葵花点穴手早就出到 9527 版了，手法可能很难和 9527 版葵花点穴手融合。
• 减轻维护负担：下游自己维护的成本太高，提高给上游维护，会降低下游维护成本。
  • 葵花派除了长老授课以外，要求白展堂单独授课讲解“葵花点”手法，白展堂打王者荣耀的时间都没有了，更别说研习新武功。白展堂整理出手法秘籍交给长老，由长老统一传授，白展堂又可以快意江湖了。
• 便于合作共赢：通过和上游合作，可以更为顺畅地与上游达成一致，得到上游的认可，也更容易将上游的修改合并进来。
  • 白展堂因贡献了“葵花点”手法被尊称为首席大弟子，长老在“葵花点”的基础上研习出提高葵花点穴手定身时长的法门，白展堂第一时间得到秘籍修炼，如鱼得水。
  • 反之，白展堂没有贡献“葵花点”手法自己自行修炼，长老研习出提高葵花点穴手定身时长的法门，白展堂发现和“葵花点”手法运功路线不一致，难以习得新版葵花点穴手，无法提升威力。

使用“上游优先”需要做什么？

首先，需要与上游达成合作。达成合作是反馈给上游的捷径，越密切的合作者提出的想法，越容易被上游所接受。

其次，需要保持与上游的沟通。达成合作不是一蹴而就的事情，需要与上游加强沟通，及时了解上游动态，否则，无法确保你的想法与上游的想法是否一致。

最后，需要将修改及时反馈给上游。上游的修改需要成本，及时的反馈可以节省成本，这也是上游收费接收下游修改的一个重要标准。及时的反馈，能够让合作变得更加通畅。

哪些开源组织或公司使用“上游优先”？

在开源世界中，开源项目对“上游优先”的宣传并不多，但实际上大部分开源项目对“上游优先”都是非常认可的。

“上游优先”的理念更加像是一种约定俗成，除了一些知名开源项目可能有提到或宣讲过该理念以外，更多的是默默践行这一理念。有很多开源项目没有对“上游优先”做过多的解释，但在开源过程中对开源项目的必要修改都会反馈到上游。

下面列举一些明确采用“上游优先”的部分开源组织或公司：

• RedHat：红帽组织对“上游优先”可谓是彻底贯彻，网站上能够搜到的关于“上游优先”的文章和演讲，红帽可谓是不遗余力。
• OpenEuler：OpenEuler 是华为的一个开源项目，用 OpenEuler 自己的话来说：OpenEuler 来自于社区，回馈到社区。
• Google Chromium：Google Chromium 官方的 Design Documents 中，将 Upstream First 放在了 General 一栏中。
• The Linux Foundation：LF 官网在“Best Practices to Contribute Code Upstream”中，可以找到 Upstream First 的介绍。
• ……（更多案例，欢迎补充）

参考

https://my.oschina.net/lihuimingxs/blog/4977991

https://www.redhat.com/zh/blog/what-open-source-upstream