软件定义未来，开源定义软件
根据中国信息通信研究院的数据显示，2020 年中国数字经济占国内国民生产总值（GDP）的 38.6%，整体规模达到 39.2 万亿。数字经济的重要基石就是软件，软件在现代数智化社会中扮演着越来越重要的角色，未来世界将由软件来勾勒定义，而开源俨然已成为软件开发、交付的新模式。
开源也已经上升到了国家层面，今年国家“十四五”规划发布的时候，提及到了“开源”，而且在上个月底，工信部发布了《“十四五”软件和信息技术服务业发展规划》，《规划》中多次提到了“开源”，涉及开源人才培养、开源社区/基金会发展已经开源生态构建等，利用开源来加速构建“软件定义”技术体系及创新应用生态，从而助力中国数智化社会的发展。
开源的发展和生态繁荣离开多方力量（个人、企业、组织、高校等）的共同参与，而“upstream first”被认为是参与开源的正确方式。判断一个企业或组织是否在真正拥抱开源、贡献开源、主导开源的有效方式就是查看他们是否在真正践行“upstream first”理念。
什么是 Upstream
Upstream（上游） 这个术语通常指数据流，对应的是 downstream（下游）。对于开源项目来说，upstream 指开源参与者贡献开源项目以及此项目版本发布的地方。参与者在 upstream 做贡献（功能特性、缺陷修复、决策制定等），最后流向（分发） downstream，为用户所用。关于 upstream 的一个很好例子就是 Linux kernel（内核）。Linux kernel 是众多 Linux 发行版的 upstream，分发者从 upstream 获取 Linux kernel 的版本，然后加入其他的内容（systemd、GNOME、GNU 套件等），构建出不同的 Linux 发布版本，供用户（downstream）使用。
为什么 upstream first 很重要
upstream 是开源项目贡献者共同协作的地方，功能特性的添加、缺陷的修复、相关决策的制定都发生在上游，其重要性不言而喻。Upstream first 可以：
- 降低成本
如果是 downstream 的研发方式，需要团队将 upstream 的功能特性和自维护的 downstream 进行合并，随着版本的迭代、功能的增多，这种合并是非常痛苦且成本高昂的，而且存在很高的风险，因为一旦 upstream 发生了较大的变化，且这种变化和 downsteam 自维护的功能无法兼容的时候，可能会导致自维护的 downsteam 后续都无法使用 upstream 的最新功能特性了，甚至连安全补丁也可能无法使用了。导致产品的功能、性能和安全性都无法得到保证。
而如果采用 upstream first 的模式，积极与 upstream 进行沟通，将功能特性都贡献进 upstream，不管后续如何迭代发布，版本中都会包含有自己想要的功能特性。这就省去了维护臃肿的 downstream 的维护成本。
- 保证软件供应链安全
软件安全攻击在近些年已经发生了转变，从对即有漏洞集中攻击的传统软件攻击转变为了软件供应链攻击，也就是说攻击开始向着 Upstream 转移。因为在如今的开源时代，已经很少有从零开始来构建软件了，更多的是利用既有的开源组件来构建软件，而这些开源组件就成了 upstream，如果对 upstream 进行攻击，那么受攻击的 downstream 可能是指数级的，这种攻击点在 upstream 而影响 downstream 的方式也就是现在常见的软件供应链攻击。
所以要想防止软件供应链攻击，确保软件供应链安全，保证 upstream 的安全就显得只为重要。因此，upsteam first 的理念就能够用来提升 upstream 的安全，因为所有的贡献都在上游，缺陷、漏洞、补丁都发生在 upstream，只要 upstream 的安全性能够得到保证，downstream 的安全性也将得到足够的保障。upstream 和 downstream 的有效协同，将构建起软件供应链的安全屏障。
- 助力良好开源文化的构建
Upstream first 一直是众多优秀开源项目践行的开源参与方式。坚持 Upstream first 的理念，有助于构建良好的开源文化，培养更多的开源人才，让个人、企业或组织从开源这种协作创新中获益。从而推动整个开源的良好发展。
良好的开源文化是一个摇篮，能培育更多优秀的开源人才，壮大开源发展的队伍，加速开源发展；也是一座桥梁，既可以吸引国外优秀的开源项目走进来，也可以助力国内优秀的开源项目走出去；更是一张中国名片，向全世界展示更多的中国元素。
极狐(GitLab)：upstream first 的践行者
极狐研发团队从 2021 年初开始组建，虽然成立时间不长，团队规模也还较小（目前有九位开发工程师），但我们对 GitLab 上游社区的代码贡献量已经取得了非常不错的进展。以最近的一次GitLab release（14.5，发布时间为2021年11月22日）为例，GitLab 上游社区总计有 201 个来自社区贡献者的代码合并请求（Merge Request）被成功合并，如下图所示：
而在这个release中，有40个来自极狐研发团队的代码合并请求被成功合并，如下图所示：
由此可知，在 GitLab 14.5 release 中，极狐的代码贡献量占到了社区总贡献量的 20%。另外，在下图中我们可以看到各大公司对 GitLab 14.5 所做出的代码贡献量（极狐暂未被统计在其中），图中显示的第二名是西门子，其代码合并请求数为 10 个，远低于极狐的 40，据此我们可以推断在最近的 GitLab release 中，极狐研发团队对GitLab的代码贡献量已仅次于 GitLab Inc. 达到了全球第二位。
另外，有两位来自极狐研发团队的工程师进入了个人贡献者榜单的 Top 10，其中曹宝栋以 16 次代码合并请求位于榜单的第二位。数据来源同上图。
极狐(GitLab)研发团队前端研发人员的 upstream first 实践
极狐(GitLab)研发团队前端开发人员 Jeremy Wu 作为极狐(GitLab) upstream first 的践行者，在工作中发现了 GitLab 的一些 security 问题，直接贡献到了 upstream（GitLab），最后获得了 upsteam 的赞赏。以下是 Jeremy Wu 关于 upstream first 的故事：
Jeremy Wu 是极狐(GitLab)研发团队的前端开发人员，主要工作是前端方向基于 XSS 攻击的防范。简单的来讲就是“不相信用户的输入”，通过一系列方法将用户的输入“消毒”，并展示到用户界面上。关于安全性问题的发现，Jeremy Wu 是通过 issue 里的 ~security 标签来查找的，而且完成的安全性相关的代码修复都是基于 ~security 和 ~easy for new contributor 来做的。他以 onboarding warm up 为出发点，去找寻“潜在的安全问题”，这些安全性问题可能导致用户的输入内容劫持网站。
因为安全性问题的发现与修复是一个长期的过程，在代码提交的时候需要由专业的安全团队去做代码审查，防止有代码会存在潜在的安全性问题，在这个前提下安全团队会定期去检查代码和通过一系列的 CI 自动化扫描来查找是否有潜在风险。对于 GitLab 来说，更是有着严格的代码安全审核流程，而 Jeremy Wu 是非常熟悉这个流程的。他把 security 贡献的 upstream first 归纳为三个步骤：
- 首先需要去对应的 issue 下面找到对应的 issue owner，然后询问是否可以着手修复这个对应的 issue，owner 如果觉得可以会把这个 issue assignee 改为“你”，接下来就可以开始修复工作。而 Jeremy Wu 对修复流程也是驾轻就熟，他用如下三步就会完成问题的修复：
a. 找到未经“消毒”的内容片段 b. 将该片段引入“消毒”代码 c. 把“消毒”后的代码替换到源片段
通过以上三步即可完成安全性问题的修复。
- 如果在做的过程中遇到了一些技术性的困难，可以直接在 issue 里与 issue 的 owner 进行沟通，讨论如何解决。沟通大致为：
- 当前所遇到的问题的一段详细描述
- 如何复现遇到的问题
如果描述且复现步骤清晰，一般不需要经过第二轮沟通则可以解决。但在实施过程中，Jeremy 为了更加熟悉 GitLab 本身，他选择先去找到代码对应的页面（找入口），然后通过上述方法给代码补丁之后再对对应页面进行观察，是否与之前渲染的内容有出入，若无出入则可以将代码提交，并进行 merge request。
- Merge Request
当 Merge Request 做好之后，GitLab Dangerbot 会自动为“你”推荐对应的 MR reviewer 一般来说是三个（frontend/backend/database + maintainer + security），然后 Jeremy Wu 会手动在 MR 的 channel 里 ping 上述的 issue owner。如果在 MR review 的过程中有一些代码建议以及修改，在与对应的 reviewer 进行交涉以及代码修改之后代码即可以被合进 upstream 的仓库。
一般来说，到这个阶段某个 issue 就可视为结束了。如果需要后续的跟进，upstream owner 会创建对应的 follow up issue 来跟进。
Jeremy Wu 一直使用这种工作方式与 Upstream（GitLab）进行协作，其出色的工作获得了 Upstream 的赞赏。
极狐(GitLab)研发团队后端研发人员的 upstream first 实践
曹宝栋作为极狐(GitLab)研发团队后端研发人员，也在积极践行“upstream first”的理念，曹宝栋积极参与 GitLab Hackathon 并获得了奖。而他把这次经历进行了如下总结，期望能指引更多的人贡献开源，人人都去践行“upstream first”的理念。
- GitLab Hackathon 背景介绍
GitLab Hackathon 是一个虚拟活动, 任何有兴趣为 GitLab 贡献代码、文档、翻译、用户体验设计等的开发者都可以参加。如果合并请求 (MR) 在活动期内被合并了, 将会获得相应的奖品奖励。更多背景介绍可以查看活动详情链接：https://about.gitlab.com/community/hackathon。
- 参与的方式、过程
开发者可以通过日历来订阅 GitLab Hackathon 的活动: 订阅链接。
在开始之前, 开发者需要在选定的 Issue 中留言, 表明自己有兴趣解决这个问题。这样可以避免多位开发者选择同一个 Issue 的情况。如果不甚理解的也可以通过视频How to join the upcoming GitLab Hackathon来学习参与方式与参与流程。
对于刚接触 GitLab 的开发者。从贡献文档开始是比较容易上手的。在贡献代码的过程中遇到任何问题。 都可以到 Issue 中留言来寻求帮助。
- 最后的获奖
如果开发者的 MR 在规定的时间内被合并了，那么将会得到奖品奖励。奖品也是非常具有吸引力的。
| 奖品类别 | 奖励条件 | 奖品 | 图示 |
|---|---|---|---|
| 冠军 | 获得最多积分的个人 | 特别礼盒, 以及跟 GitLab CEO Sid Sijbrandij 的25分钟通话机会 |  |
| 亚军 | 积分第二多的个人 | Miir Coffee Canister 或者 Fabric Charging Pad |  |
| 合并奖 | MR 被 merge 的人 | Tanuki Shirt |  |
可获得的收获
开发者可以在 GitLab 中找到各种话题的 Issue，并且很容易加入讨论。Hackathon 对开发者来说是一个很好的契机, 可以感受到开源开放的团队氛围，能获得来自全球的开发者的帮助。提升自己技能的同时也会熟悉贡献优秀开源项目的整个流程。
极狐(GitLab)始终保持“开放开源、人人贡献”的理念，以 Upstream first 为指引，一直鼓励极狐人积极投身参与开源贡献，因为我们相信 Upstream first 能够构建良好的开源文化。
Upstream first：培育真正开源文化，构建良好开源生态
开源是开源参与共同体（community）通过协作创新的极致体现。也被视为能够解决国内“卡脖子”问题的有效手段。Upstream first 理念是能够培育真正开源文化，构建开源生态的基石。
极狐(GitLab)自成立之日起就秉承“开源开放，人人贡献”的理念，鼓励所有极狐人积极参与开源贡献，努力践行 Upstream first，我们期望能够通过极狐人的努力来夯实开源发展基础，完善极狐GitLab 开源生态发展；打造开源软件品牌，构建生态完善的开源社区、开放联盟；推广普及开源文化，培养更多开源人才，扩大开源生态发展；促进产学研协同创新，释放“软件定义”创新活力，助力国内软件产业的开源开放、创新发展，提升国际竞争力，从而加速全球化布局。
开源是世界的开源，我们期待更多的有志于开源事业发展的有志之士加入，共同践行开源实践，缔造开源开放文化，助力我国开源文化的发展，让开源发展为“十四五”规划的发展，我国数智化社会的构建的重要抓手。
