Cadence和Synopsys的5nm全流程设计工具已获得三星认证，可用于5nm生产线
06-06
企业软件团队如何与上游开源项目团队保持健康的协作关系一直是业界的热门话题。
OSChina编辑部作者萝拉用详细案例介绍了什么是“上游优先”原则，并表示“（上游优先）与善意无关，是开放合作的必要态度，甚至是争取权利”你采取行动，在社区中赢得声誉和影响力，社区信任并尊重你，你的决定就有分量。
”在开源中国写了这么久的文章，我常常感到自我怀疑。
总有一些读者会留下诸如“开源应该免费”之类的评论，让你想和他吵架。
这些评论就像重锤敲在小编的脸上，让小编不禁问自己：这些年写了哪些文章？难道这一切都是徒然吗？我们似乎了解开源的一些常识性原则，但又似乎不明白。
这种恼人的情况经常发生在开源的另一个重要原则——“上游优先”中。
这个原则反复出现在一些开源布道者的口中，未免有点诚意。
什么是“上游优先”？ get的字面意思相信你已经理解了一大半了。
一旦你进行了分叉操作，你分叉的项目就是你的上游。
另一方面，上游优先是一种鼓励您直接与开源社区互动并从源头解决问题的工作方式。
关于“上游优先”，还有一个有趣的故事。
当时红旗Linux还没有崩溃，仍然是国产Linux版本的标杆。
对于是否采取“上游优先”，内部存在争议。
这对当时还在红旗Linux工作的李建生产生了影响：当时很多国产Linux发行版就自己做孤岛开发。
但是，比如说我在一个包里加了一些功能，半年后我发现上游做的事情比我多，而且更完整。
有些bug甚至早就被修复了，而且修复得非常好，而且还增加了功能。
然后我不得不废弃我所做的所有工作，然后再次获取上游包。
无疑，李建生认为“上游优先”是必要的，但大环境让他感到力不从心。
几年后，李建生成为中国为数不多的全职开源文化布道者之一。
他在接受 OSCHINA 采访时表示，这次争议几乎是他开源职业道路上的一个岔路口。
今年刚刚当选ASF（Apache软件基金会）理事的蒋宁也有同样的感触。
姜宁在接受OSCHINA采访时表示：观念的转变是最困难的。
国内的开源参与者大多抱有搭便车的心态，只把开源当作一个可以让自己快速上手的免费工具。
如果使用过程中出现问题，你可以在社区提问或者自己修复，无需向上游回馈任何东西。
人们不习惯与上游社区进行任何互动。
姜宁将这些问题归咎于理念问题和缺乏开放协作意识。
除了转变观念之外，要想把这个原则落实到实践层面，还得走更长的路。
01 可以不给上游反馈吗？答：要看实力。
事实上，无论是哪种开源许可证，都没有要求“上游优先”。
不用说，其他宽松的许可证，即使是最强大的GPL也只要求：“分发时必须提供源代码”。
这里的“提供源代码”是指用户想要获取源代码的时候。
，他有办法获得。
它没有规定必须反馈给上游，更没有规定上游优先级。
那么，为什么在没有要求、没有规定的情况下，我们还要做上游反馈的事情呢？这个问题其实很多开源布道者都讨论过，比如之前提到的姜宁和李建生。
他们的论点基本上围绕以下3点：1）降低自己的维护成本。
一旦分叉，就意味着与上游解耦，不再参与上游的维护和更新，分叉版本的生死由分叉者负责。
然而，代价却比想象的要大得多。
此外，即使您负担得起这些维护成本，您也很可能会重新发明轮子。
但如果你将修改反馈给上游那就是另一回事了。
合并后，所有维护工作都由上游承担，立即解放你的双手。
2）方便下次使用上游更新。
如果你想使用从上游更新的新版本，你需要在你自己的分支上进行调整。
更新速度越快，适配工作量就越大。
但如果你自己的代码已经在这条“主线上”了，你就可以零成本享受它。
3）不要孤军奋战，多与上游沟通。
想要深度参与开源，确实需要和上游沟通。
沟通也是开源的魅力所在。
你不再孤单，而是可以与众多有相同兴趣爱好的开发者进行交流和讨论。
与上游沟通得越深入，你就越有可能联系到项目创始人甚至你的偶像。
也许您还会发现它们非常有帮助。
在这个层面上，分支的主体是“个人”。
我一个人的力量有限，就算分出去，最多也只是一条沟渠，很快就会干涸。
最好最明智的做法就是拿出分享的精神，拿着自己的代码，逆流而上，找到一个组织。
但在组织和集体层面，可能会出现另一种情况：这种分叉不是偶然的，而是有特定目的的。
例如，南非亿万富翁 Mark Shuttleworth 为了实现自己的梦想，从 Debian 中分叉了 Ubuntu；另一个例子是MySQL。
创始人因Oracle收购一事勃然大怒，分叉了Maria DB。
这些分叉后来散发出相当大的力量，丰富了开源项目的前景。
他们的逻辑是直接创建一个新的社区，而不遵循上游社区的逻辑。
修改之后，他们依然会发布新版本，打造出自己的特色，成长为一条浩瀚的河流。
但事实上，中国更普遍的情况是公司层面的“借贷主义”。
开发者没有任何理想主义的目的，只是为了完成任务。
比如，老板想要一个XXX的解决方案，给出了几个月的时间和几十万的预算，于是项目经理就直接从上游项目拿过来，花了一些时间修改变成了这个解决方案。
这个项目没有任何反馈上游的动力，区预算也没有能力维持和支持。
从长远来看，这种做法毫无意义且浪费。
因此，明确了上述三种情况后，“是否需要向上游反馈？”的问题就来了。
瞬间就变成了“我有实力不向上游反馈吗？”如果没有，请继续阅读。
02 我们有实力，但为什么要优先上游？ “我认为 GPLv2 是一个很棒的协议。
我喜欢它的原因很简单：我给你源代码，你给我你的修改，我们就扯平了。
” ——Linus Torvalds，Linux之父，从一开始，Linus就清楚地认为他需要一种机制，能够确保下游的修改能够反馈给他。
我们无法回到“上游优先”最初被提出的时候，但有一点是肯定的：包括Linux内核社区在内的许多社区都在遵循和遵守这个“开源潜规则”。
在2017年Linux内核社区围绕“上游优先政策”的讨论中，Linus明确表示永远不可能停止实施“上游优先”政策。
后来Linux基金会也公开表达了“上游优先”的重要性，认为如果（代码贡献者）没有这个（社区）自律，内核早就在自重下崩溃了。
2016年，Linux基金会发布了一份报告，呼吁采用开源方法来解决“技术债务”。
报告指出，一旦项目积累了技术债务，就会出现交付时间延长、安全问题增加、维护任务加重、无法与上游同步等症状和不利影响。
他们给出的解决方案是“开源”。
这里开源最重要的原则就是“上游优先”。
与上游保持一致的开发节奏几乎可以避免绝大多数技术债务。
当然，这需要你积极参与上游项目。
你不能强迫上游往对你有利的方向发展，但你可以通过贡献和分享来影响上游，让上游和其他贡献者逐渐明白你的需求是什么。
整合上游开源项目的开发流程。
以上是来自上游的调用。
也有实力雄厚的下游公司在分叉很久之后重新加强与上游公司联系的例子。
其中，最著名的就是谷歌的Android开发社区。
众所周知，Android的底层是Linux内核，从上游Linux内核到各种Android设备终端的链条中，有很多利益相关者，往往会经历多次分叉，以及一堆具体的变化。
高通、三星等SoC厂商基本上都会为每个主要芯片版本制作一个SoC专用的核心，然后每个核心都会获得针对特定设备的硬件支持。
这导致了非常混乱的 Android 内核碎片。
Android.com 官方文档指出：“这些修改非常广泛，设备上运行的代码中有多达 50% 是树外代码（不是来自上游 Linux 或 AOSP 通用内核）。
”因此，谷歌Android的臭名昭著是显而易见的。
早在 2018 年，LWN.NET 上就有帖子批评 Android 开发社区因不采用上游优先政策而造成麻烦。
事情的起因是，今年2月，Android内核中的（悬浮拦截器/悬浮拦截器）首次以唤醒锁的形式出现。
在接下来的一年多时间里，Android开发者收到了大量但相互矛盾的建议。
举例来说，你想修复X来合并这段代码，但是当X修复后，开发人员跳出来要求他们修复Y。
修复工作似乎永远无法完成。
与此同时，Android 开发者也因不向上游上传代码而受到公开批评。
大多数批评是 Android 正在秘密开发短期解决方案。
毕竟，一旦代码交付并且应用程序开始依赖它，进行任何更改都会变得更加困难。
这使得大多数 Android 设备使用多年前的内核版本，而错过了新的 Linux 内核功能。
近两年来，Android社区的局势出现了逆转。
2019 年 9 月，在 Linux Plumbers 大会上，谷歌软件工程师 Todd Kjos 在自我分析 Android 出现这种情况的原因后透露，Android 将奉行“上游优先的开发模式”，确保新代码首先进入主线 Linux 内核而不是直接位于 Android 源代码树中。
此外，谷歌还承诺“努力上传 Android Common Kernels 上游的所有树外补丁”。
在他们的时间表中，谷歌计划在今年年底前完成现有功能的上游升级并隔离供应商变更。
并且，从2017年开始，该公司计划采用这种“上游优先”的发展模式，以避免未来出现此类问题。
谷歌有这个实力吗？但兜兜转转之后，我还是回到了“上游优先”。
除了谷歌之外，最大力推行“上游优先”原则的公司就是红帽。
红帽在其自己网站上的文章和各种公开演讲中强调了这一原则。
▲ 红帽开源参与指南中的第一项是“上游优先”。
在2018年的GOTC大会上，红帽全球副总裁兼大中华区总裁曹恒康描述了红帽整个“上游优先”的路径：红帽之前完成了我们的商业版本之后，我会把它作为社区版本发布。
但我发现了一个问题。
很多所谓的生态伙伴或者公司不会将自己写的代码贡献给上游，他们的供应就会被断绝。
红帽觉得这些东西不能满足上游优先级的概念。
去年，我们只是将 Stream to RHEL 放在红帽企业软件的上游。
我们为什么这样做？因为我们拿到代码后，把它变成一个可用的代码，然后从红帽代表那里拿到，变成企业版软件，然后贡献给上游，所以不会有任何遗漏。
以前Stream OS在Red Hat下游存在遗漏问题，但现在不会有遗漏。
真正能够实现红帽当时的想法的是上游优先的理念。
“上游优先”开发的理念是，基于开源项目的产品中包含的任何更改（功能、错误修复）都应首先提交给项目，然后再包含在产品中。
这最大限度地减少了长期维护的负担。
——Dave Neary03，红帽开源和标准团队成员。
既然要反馈，就必须优先考虑反馈，甚至拿到上游票一路看下去。
事实上，无论你有多强，在开源道路上“上游优先”都是不可避免的。
一个重要的原则。
既然无法回避，那就参与其中吧。
Dave Neary曾在一篇文章中详细解释了如何实现“上游优先”原则。
在他看来，如果开发者想要实现某个客户的需求，可以尝试直接询问项目，但不要像乙方那样期望社区能够在规定时间内满足所有需求。
毕竟，社区没有得到任何好处，也不想被利用。
所以，最好的办法就是用自己的团队来解决。
有一个问题：因为上游不在你的控制之下，你不能像Red Hat那样等到上游合并完成后再交付给客户；您只能事后将其发送回上游开源项目，这会产生时间滞后。
。
当时间差无法消除时，你应该尽可能快地反馈给上游。
因为随着时间的推移，变化会在本地分支累积，使得迁移到上游变得极其麻烦。
对于许多外行来说，向开源项目提交功能和补丁似乎很简单。
事实上根本不是这样的：首先，将代码从稳定分支返回到上游必然会涉及大量的返工；其次，刚刚提交的代码往往难以消化。
即使切割成独立的补丁，每个补丁也需要独立提交和接受。
这项工作无疑是艰巨的；第三，有些社区的审核合并周期非常长，这么长的周期非常考验人的耐心。
;最后，很有可能你的解决方案不会被上游认可，而上游根本不打算合并你的分支。
这是非常压倒性的。
对此，Dave Neary提出，理想的工作方式是针对上游项目不稳定的分支开发功能。
这样，一旦补丁准备好，你就可以请求合并，而当你想将新功能移动到你自己的产品中时，这些功能实际上是向后移植到稳定分支的，同时也减少了你自己的维护。
成本。
当然，Dave Neary也表示，这种方法有一个前提：在所有工作开始之前，你需要在社区内公开讨论，从而确保你提出的解决方案有可能被接受。
要知道合并有多难，国外甚至有一家叫Collabora的咨询公司，专门帮助客户把自己的代码带到上游社区，帮助企业与主线社区建立联系。
找到了？最重要的一步是与上游维护者建立关系。
简单来说，就是经常和他们沟通，和他们建立良好的关系，或者干脆自己成为他们中的一员。
当你有了话语权，事情不是很容易做好吗？有文章讨论过这样一个问题：“上游优先就意味着善良吗？”在作者看来，这与善良无关。
这是一种开放协作的必要态度，更是一种话语权的争夺。
你的行动在社区赢得了声誉和影响力，社区信任你、尊重你，你的决定就有分量。
这就是开源的样子。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-18
06-18
06-18
06-18
06-18
最新文章
Android旗舰之王的过去与未来
智能手表不被开发、AR眼镜被推迟，Meta的产品经历了一波三折
为什么Cybertruck是特斯拉史上最难造的车？
更新鸿蒙3后，文杰允许你在车里做PPT了
新起亚K3试驾体验：追求“性价比”，韩系汽车仍不想放弃
阿维塔15登场！汽车配备了增程动力，理想情况下会迎来新的对手吗？
马斯克宣布创建 ChatGPT 竞争对手！ OpenAI的CEO给他泼了冷水， GPT-5可能会发生巨大变化
骁龙无处不在，是平台也是生态