技术人聊开源：这并不只是用爱发电

近年来，中国开发者已经成为全球开源体系中的重要力量。据不完全统计，中国的代码在全球开源社区的比重已占 40% 左右，目前全球 6000 多万开发者中，至少有 2000 多万来自中国。

开源是一个公司技术影响力的表现之一，走向社区与其他生态合作，拓宽技术的应用领域，为外部需求贡献的同时也能让自身技术走向成熟。

过去的 2021 年，蚂蚁的技术同学和全球各地的开发者们，共同参与到开源社区的建设和维护。

2021 CNCF 中国区 TOP10 的贡献者中，有 4 位来自蚂蚁集团。 过去的2021年，蚂蚁的技术同学和全球各地的开发者们，共同参与到开源社区的建设和维护。其中两位技术同学主要参与了 Dragonfly 和 Nydus 这两个互相关联的开源项目。

\
Dragonfly

Dragonfly 是一个开源云原生镜像分发系统，主要解决以 Kubernetes 为核心的分布式应用编排系统的镜像分发问题，2020 年晋级为全球著名开源社区 CNCF （云原生基金会） 孵化项目。
 

Nydus

Nydus 是蚂蚁集团发起的 Lazy load 原理的镜像加速项目，配合 Dragonfly 做 P2P 加速，能够极大缩短镜像下载时间、提升效率，并提供端到端的镜像数据一致性校验，从而让用户能够更安全快捷地启动容器应用，目前是 Dragonfly 的一个子项目。
 

小编与这两位同学，以及他们所在团队负责人，聊了聊他们眼中的开源。

@ 百蓦｜参与 Dragonfly 开源一年

​\
开源本身就是一种值得追求的奉献精神

 

我是 2020 年开始接触 Dragonfly 项目的，现在主要参与项目整体 2.0 升级。我们这个项目的维护者来自不同公司、不同团体，比如阿里云、字节跳动、去哪儿、Intel 以及上海交通大学等。

我认为项目开发过程中的首要工作就是制定标准，标准制定好了，结果就更容易达成一致。尽管大家来自不同公司，不论技术如何，对代码的理解有何分歧。

最终目的都是对项目质量负责，是一个合作和协作的关系。

 
目前来看，我认为开源在国内的情况大部分是偏实用，需要更多有奉献精神的程序员参与到开源工作当中。当然近几年国内也涌现了很多技术创业公司，开始投入到开源项目中，而非仅靠程序员自己的兴趣，利用业余时间投入。

开源本身就是一种值得追求的奉献精神

我做程序员的初衷是希望凭借自己的能力去改变一些事情，做开源也一样需要有一些技术信念。因为开源是个无偿的工作，不是商业化的东西，而是希望从中找到可以突破的技术点。

 
就像我个人非常喜欢的一位程序 David Heinemeier Hansson(DHH) 说过：

 
“
Writing open source software and giving it away for free has without a doubt been my most professional rewarding endeavor yet。\"
 

 

其实做开源的人都比较包容，做事也比较单纯，都是为了把一件事做好。

 

写代码不是 0 和 1

有的程序员比较理想主义，看到有问题的部分，就一定要指出并改掉。比如我自己，对瑕疵的东西看不惯，绝对会坚持正确的事情。

写代码要看具体场景、具体需求，没有绝对完美的答案，但是要时刻督促自己接近完美。

2021 年 9 月 9 日，Dragonfly 2.0 正式发布，这是我第一个从 0 到 1 完整参与的开源项目，比较有成就感，也很有感情。虽然从开发到第一个版本发布持续了一年时间，过程中遇到问题也会争论不休，但真正发布的那天大家都非常开心和激动。我们同学们都比较给力，我们会一直坚持把项目维护下去，打造云原生场景基于 P2P 镜像和文件分发标准解决方案。

 
我个人的短期目标是希望把 Dragonfly 做到 CNCF 毕业，后期会继续关注云原生场景镜像和文件分发还有哪些可以解决的问题，深入去研究。

 
毕业意味着会有更多的人使用，项目才真正开始。

 

@ Jim｜参与 Dragonfly 开源一年

打造开源项目的全球影响力，

需要标准化和行业共建

 
我日常参与的开源工作有功能研发、优化项目性能、提高兼容性和稳定性、代码优化。也会经常在社区参与线上讨论，也会花很多时间和精力在 Dragonfly 开发者群、线上社区，帮别人解答问题。

 

参与开源，不只是使用

参与开源，不是说使用就算参与了，而是要更积极地反馈一些问题，尽力地让它朝着好的方向持续发展。

比如说一个项目帮你解决了一个项目问题，但项目自己又有一些问题没有覆盖到。这个时候，不应该置之不理，或者说没有涉及到你的使用覆盖面就不管，而是需要我们及时去社区反馈问题。

这样的反馈能让产品越来越好，也能为开源做更多的贡献。特别是公司内部使用的项目，有些改进不合到上游社区，是没有办法让社区享受到开源的红利。

 

同时推进标准化和参与度

要形成开源工作的影响力，标准化是非常值得重视的。一项技术如果不能作为一项标准，那么很难往外推广，获得行业认同。

同时也需要参与度，只有业界伙伴能使用、参与共建，那么技术才能获得认同。

推进标准和参与，才能让项目茁壮成长起来。比如 Google 想把 K8s 推成业界一个标准的容器编排平台，花了大量的努力做了一个很好的标准实践，让业界共同参与或者认同，最终才形成 CNCF 社区。

“人人为我，我为人人” 才能促进开源社区的正向循环。

我希望中国的开源项目，能在社区运营上更上一层楼，让更多的人使用，创造更多的交流，推向更多的人。

我也希望通过自己的努力把 Dragonfly 项目推成毕业项目，结合其他项目做一些更有意义的事。

@ 王 旭｜Nydus 所在团队负责人

​​10 余年开源经验

OIF 项目 Kata Containers 联合发起人

木兰开源社区 TOC 成员

 

 

开源团队管理应避免将目标捆绑在数据上，

以防赢了 commit 输了社区

 

我觉得作为一个团队管理者，管理好开源，最大的挑战恐怕不是业务压力，而是自身的勇气。

总有人会问我一个问题——

 

怎样平衡开源和业务 ？

我的思路是 upstream first，也就是上游优先。

把自己按照上游的要求来工作之后，你会在任何时候都考虑为相关合作方留出空间和接口，会把项目的核心功能和扩展功能做合适的解耦，会理智地进行妥协和权衡，但不会对风险置之不理。

在采用 upstream first 的工作方式后，业务支持和开源之间是不会有不可调和的冲突的，否则就要谨慎地考虑是不是选错项目了。

从目标设定来说，我确实有提升开源影响力和培养新人的目标。但在考察的时候，我们侧重的是这一年的工作成果是不是真的提升了开源的质量，而非分解到 commit 排名再去比较。

参与开源的工作，更重要的不是考核数量，而是激发参与者的创新 。

我眼中的开源团队管理 （团队开源管理）

从目标看，应该是更加偏向于“激发”的 OKR 方式，避免将目标绑死在某些数据上，以防赢了 commit，输了社区。

从过程看，要有持续的调整和辅导，帮助项目调整或坚定方向、提升团队开源社区参与能力。

从工作方式上看，要有开源上游一样的对正确工作方式的追求，让开源社区工作和自身业务统一起来。

在过去的一年，Nydus 在自身建设以及和 Dragonfly 项目的合作之余，也保持了与其他项目间的互动。

Nydus 团队和其主导维护的 KataContainers 安全容器实现了无缝集成。除此之外，Nydus 团队还和中国最早的 CNCF 项目、企业级开源镜像仓库项目 Harbor 合作，串联了云原生镜像的完整生命周期，之后又和 NEC 的国外开发者一起合作，共同推进 OCIImage 标准的演进。

就在今年年初，NEC 把 Nydus 为 containerd 写的 snapshotter 贡献到 containerd org 里做子项目。

开源社区里汇聚的各个开发者的不同需求和背景，会帮助代码释放它们的设计者在写下时都不能预见的潜能。

开放协作正是开源的价值所在！