什么是”上游”

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

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

我们这里的上游，特定指的是开源项目，如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

软件开发中的上游upstream相关推荐

软件开发中的上游和下游
听了腾讯犀牛鸟王佳对开源的讲解中,对其中的专业术语上游(upstream)和下游(downstream)不理解,看了这篇blog理解了特此转载记录. 看了以下blog后个人理解:自然界上水是高处往低处 ...
彼之蜜糖，吾之砒霜——聊聊软件开发中的最佳实践
作者:sherrywasp https://www.cnblogs.com/sherrywasp/p/9436623.html "描述一个事物,唯有一个名词定义它的概念,唯有一个动词揭露它的 ...
视频互动直播软件开发中的连麦问题分析
直播行业发展至今,我们经常会听到很多朋友谈论"互动直播".那么何谓互动直播呢?其实互动直播的核心在于通过连麦技术,让视频直播有一个超过文字的更深层次的互动交流. 在视频互动直播软件 ...
统治软件开发中的著名定律
文| https://www.timsommer.be/famous-laws-of-software-development/ 翻译| 码农翻身和其他领域一样,在软件开发的世界中也有一些有趣而著名 ...
阿里研究员：缩短软件开发中的反馈弧
简介:开发者写好了某个功能的代码,想知道这个功能是不是实现了,代码还需不需要再改,这就是一种反馈.在软件开发中,尤其是联调时,缩短反馈弧有助于及时发现问题.采取对策,提高开发效率.那么什么样的反馈弧才 ...
软件开发重要性_在软件开发中考虑时间的重要性
软件开发重要性 by Crunch Tech 通过Crunch Tech 在软件开发中考虑时间的重要性 (The importance of time to think in Software Dev ...
测试自动化金字塔在软件开发中是如何使用的？
测试自动化金字塔,是一个指南,指导您进行什么类型的测试以及每种测试的数量.测试自动化金字塔有助于创建更高效的测试,并导致向客户发布更可靠的软件. 测试自动化金字塔的好处测试自动化的大部分好处显而易见 ...
论软件开发中的可信赖的工作
中大型软件开发,免不了团队开发,团队开发就少不了分工合作.在团队开发中,当然每个人的能力都很重要,但是我认为可信赖的工作是团队开发的首要条件,也是团队开发存在的基本保证.没有可信赖的工作,就没有团队分 ...
软件开发中的完整测试所包括的环节UT、IT、ST、UAT
软件开发中的完成测试环境所包括的环节包括:UT.IT.ST.UAT UT = Unit Test 单元测试 IT = System Integration Test 集成测试ST = System T ...

软件开发中的上游upstream