头图.png

“社会之所以能够运作，并不是人类有意使然，而是因为它是进化过程中出现的人类秉性。确切地说，它就是人性的一部分。” _——《美德的起源》马特·里德利_

所谓“助人者自助”，或许协作、互助这种能力就是我们为了满足人类与生俱来的一部分“个体私欲”而进化来的，让自己和他人都能从中受益。在开源社区中，这一点得到了很好的体现。“开源”本身就是一个社会性事件，它的流行很大程度上得益于协作以及由协作带来的创新。特别是随着云原生成为大势所趋，企业 IT 技术体系越来越朝着原生化、标准化的思路演进，这些都推动着开源来到一个新的黄金年代。

不得不说，今天的开发者是幸福的：云让基础设施使用起来像水、电一样便利；云原生将分布式的应用门槛不断下放；开源社区帮助开发者找到各种为自己所需的基础软件。剩下的，就是需要开发者自己去思考如何利用好这一切，比如通过主动融入更大范围的学习、交流、沟通圈子，以及借助开源社区的能力等方式，让产生于开发者群体中的“分布式”和“社交方式”的决策形成事实标准，进而让每一位开发者自己成为推动技术发展浪潮的主角。

OAM 社区 Maintainer Roy：我和社区一起成长的那些事儿

几天前，我们和开源的云原生应用标准定义与架构模型 OAM（Open Application Model）社区 KubeVela 项目的新晋 Maintainer —— Roy 进行了一次对话。现在的 Roy 是韩国汉阳大学计算机科学专业的一名在读研究生，一位阳光大男孩儿。当被问及平时有哪些爱好时，他不假思索地回答了“写代码”和“跑步”。

Roy
GitHub ID: @captainroy-hy

从 OAM 刚发布开始，Roy 就投入了积极的贡献。作为全球首个定义云原生应用标准与架构模型的项目，2019 年 10 月开源的 OAM 和 Roy 一样，都是年轻而快速生长的：年轻的 OAM 在今年锋芒显现，被评选为“2020 年度十大开源新锐项目”；年轻的 Roy 凭借自己的贡献成为 OAM 核心实现 KubeVela 项目的核心 Maintainer，需要从更加全局的视角帮助项目发展。

我们向 Roy 了解了他成为 Maintainer 的心路历程，并且从中得到了一些关于如何看待开源精神、贡献社区以及对 OAM 的理解等问题不一样的答案。

“发现 OAM 源于寻找云应用模型落地方案”

Roy 在实验室的研究方向是“云计算与云应用编排”，解决的问题是帮助应用开发人员屏蔽掉由底层基础设施带来的复杂性和差异性，使他们更好地运用云平台上丰富的应用管理能力，来构建和编排规模庞大且复杂的云原生应用。这在现阶段是非常具有挑战的一个课题。

随着云原生领域的迅猛发展，开源社区也涌现出了许多与之相关的开源项目，Roy 会经常关注一些云原生相关的开源项目。在他看来，OAM 的价值在于以一个俯瞰整个云原生领域的视角，通过建立全新的应用定义与交付模型，在应用层提供了一个用于构建和交付云原生应用的标准规范，这给过往一直专注于基础设施层的云原生领域开辟了全新的前进方向。

因为看到 OAM 实现的目标和自己的研究课题非常接近，加之有阿里巴巴、微软这样的大型企业背书，再加上自己对 OAM 社区核心初创成员过往开源经历的“背调”，Roy 逐渐建立了对 OAM 的信任，开始了真正意义上的“跟随”。

“第一次贡献与代码无关，但很重要”

Roy 对 OAM 的贡献是从翻译 oam-spec 的英文文档开始，“当时我在 Issue 里看到有开发者提出了这样的需求，在孙健波老师的牵头下就着手开始翻译。这个过程对我理解 OAM 的帮助很大，因为我需要将说明从头到尾完整地学习一遍”。

除了翻译文档，Roy 还介绍了很多除了写代码之外的社区贡献方式，比如：

在社区里提问题，甚至是提出对现有功能的质疑和吐槽，这些可以让项目成员更好地了解如何帮助用户；
回答其他成员的问题。如果你发现有的问题需要一遍遍地回复，就可以编写或者更新 FAQ 文档，以便给有相同问题的人员随时参考；
提供实践 OAM 的具体场景以及遇到的问题，基于具体场景的实践问题可以帮助社区快速定位用户需求；
提出新功能设计的想法，希望项目在未来具备什么功能、为什么需要该功能、初步实现思路，等等，都可以在社区中提出来，你会发现其他人也有类似的痛点，最终社区可能会推动实现这一新功能；
帮助项目进行教育和推广。你可以通过任意方式的分享去帮助 OAM 教育和影响用户，比如在用户群中讨论、撰写案例和博客文章等。

“OAM 是一个新项目，大家可以做出的贡献很多。其中，代码是一种重要的方式，但绝不是唯一的，你总能找到一种适合自己的方式参与到社区中来，而且一定会从给社区的贡献中收到回馈”，Roy 说。

“作为学生开发者，我是如何快速融入 OAM 社区的”

Roy 现在很大一部分精力都投在 OAM 项目的维护上。支撑他可以这么做的原因除了还在学校、时间比较自由之外，还有两个非常强的动力：一是通过参与 OAM 使自己的知识和技能不断增长；二是看到自己参与的项目真的能帮到很多开发者，并且已经被越来越多的人用起来，可以收获满满的成就感。

但作为一名在校研究生，一开始想要融入这样一个偏向工程实践的社区并不容易。缺少云原生领域在业界的实践经验、对一些成熟项目的知识盲区，对 Roy 来说都是不小的挑战:“曾经有前辈向我介绍一个出现在生产环境中的问题，因为包含很多术语，一开始我根本不知道他在说什么。直到他们给到具体的例子，甚至把代码都贴出来才能看明白。对实践场景的不熟悉，很容易导致我对功能需求的认识出现偏差。”

然而这些挑战也恰恰是 Roy 希望通过社区补齐的能力：“社区工作本身就是一种实践，这和你自己去学习课程、阅读教程完全是两个概念。”

在开源中持续学习

为了克服这些困难，Roy 首先是 Push 自己去学习和摸索相关的基础知识。云原生本来就是一个比较新且综合的领域，就拿 Kubernetes 来说，涉及的知识点、功能点非常多，有着不低的学习门槛。Roy 和我们分享了他利用开源社区进行学习的一些经验：“首先我会通过开源社区去学习并整理出一些官方最权威的文档，同时会看一些成熟的基于 Kubernetes 的开源项目。因为这些项目在落地过程中被不断完善，逐渐形成了相对成熟的实践参考，当我们遇到相似问题时是一个非常有用的学习对象。”

通过交流补充实践

向社区里的前辈们请教，是 Roy 补齐自己实践短板最有效的方式：“在社区中，我有机会和许多技术能力很强的前辈交流，比如和阿里云高级别的技术专家直接沟通，这对我来讲是非常宝贵的机会”。他认为社区工作最重要的一点就是沟通交流，不要“闭门造车”。只有大家对同一个问题有了相同的认知，并且对解决方案达成一个初步的共识之后，再去动手写代码，才是社区里协作解决问题的高效方式。

“成为 Maintainer 的过程，让我对 OAM 的理解更完整”

从实际参与社区到晋升为 Maintainer，Roy 大概经历了四、五个月的时间，帮助 KubeVela 完成了不少 Feature 的具体实现，得到了项目创始团队和现有 Maintainer 的认可。通过这些工作，让 Roy 自己也对 OAM “以应用为中心”的理念有了更完整的理解。在他看来，OAM 的出现及其目前的成绩，是云原生领域自然发展进程中的一个必然：

“云原生发展到现在，特别是 Kubernetes 出现以来，可以说经历了一个野蛮生长的阶段。它提供了高度可扩展的能力，让大家可以把几乎任意形式的软件都集成到这个平台上来。这一方面促进了 Kubernetes 和云原生的发展、繁荣，但也使平台上的应用管理变得非常复杂。”

作为一个一直关注云原生和 Kubernetes 领域的开发者，Roy 认为过往的开源项目基本围绕基础设施层，而 OAM 第一个提出了“以应用为中心”的理念，并且在不久前通过 KubeVela 的开源，将 OAM 的模型和 Kubernetes 运行时以更贴进 PaaS 平台用户和 PaaS 平台构建人员的方式，进行了完整实现。

“成为 Maintainer 对我来说是一种认可，也需要我承担更多的责任。未来，除了更多地倾听社区反馈、不断增强 OAM 及其子项目的能力之外，我也会向更多的开发者去普及 OAM 和相关开源项目的理念，帮助用户更快上手实践 OAM，就像孙健波等前辈做的那样”，Roy 表示。

“希望和更多开发者共建‘应用管理生态”

谈及对于 OAM 项目未来的发展，Roy 最希望的就是能够推动“下一代的、完全开放的应用管理生态”的逐步成熟。他认为 OAM 的发展，包括 KubeVela 的开源，已经搭建好了一个标准的云原生应用平台框架，这个框架具备高度的可扩展性和灵活性，对用户也非常友好，提供了不少开箱即用的应用管理能力，而更重要的是，这个框架还给了整个社区一个“一键组装”云原生生态能力成为 PaaS 的最佳路径，这样一个完全开放的、基于云原生社区能力的应用管理生态，其实已经初见雏形。

这次聊天最后 Roy 表达了这样的期待：“希望有更多的人参与到 OAM 社区尤其是 KubeVela 项目中，一起去建设这个日趋繁荣的应用管理生态，让越来越多的平台团队能够快速轻松的构建出强大而功能丰富的 PaaS，让应用开发人员真正享受到云原生带来的美好体验。”