OpenStack开源实践-InfoQ

这是一个开源的时代，这也是一个开源价值被逐渐认同的时代，大家如何认识开源，如何使用开源？如何平衡社区开发与公司开发的关系？

在 10 月 15~17 日召开的 QCon 上海 2015 上，我们设置了开源专题，探讨了开源相关的话题。UnitedStack 平台开发部负责人、OpenStack 社区活跃开发者邵国健，分享了他们在参与OpenStack 社区开发方面的一些经验：《OpenStack 开源实践》（幻灯片）。本文即根据演讲内容整理而成。

一. 为什么参与社区开发

OpenStack 作为一个全球的开源项目，汇聚了几千名优秀的开发者参与其中。我们知道一个公司的研发水平总是有限的，作为工程师，参与社区开发能够让我们突破这种限制，能够与全球最优秀的开发者一起交流和工作；学习和吸收社区正规的开发规范和开发流程；同时也能够系统地培养自学能力。

另一方面，参与社区开发对公司而言也是非常有价值的。可以让公司能够更深入地理解 OpenStack 整个生态体系，理解每个新功能背后的需求，比如，当我们可以去阅读社区的邮件列表、BP、讨论，参与在线会议时，实际上是为了了解一个功能是如何演进的，知道这个功能怎么用，更要理解为什么会有这个功能；另外，参与社区开发能够让公司了解社区的发展方向和趋势，为未来的产品和开发工作提供指导，在变化来临之前提前做好准备。

在 UnitedStack，我们有 85% 的工程师参与 OpenStack 社区开发，并向社区提交了代码，其中有 70% 的工程师的代码已经被合并到社区项目。这些工程师平时的工作就与社区有很大的关系，工作的一部分就是研究社区项目。

二. 开源项目与公司项目

在基于 OpenStack 进行二次开发的过程中会遇到许多困难和挑战，同时在运营 OpenStack 的过程中，我们也会不断收到来自内部和客户的需求。那么，我们是如何处理开源项目与公司项目之关系的呢？

这里说的开源项目主要是 OpenStack 的官方项目，而公司项目则指我们的 UOS 项目。两类项目的区别还是挺大的。

首先，开源项目的需求来源主要是社区讨论，当然实际上可能来自厂商需求，但最终确定需求的一定是社区讨论；而我们的公司项目的需求有一部分来自社区，即由产品驱动，而另一部分则由客户驱动，因为 UOS 不单单是要让 OpenStack 各个组件稳定运行，更重要的是要让 OpenStack 真正落地到客户的具体生产实践中，这中间肯定会不断加入客户的需求。

其次，开源项目的开发流程比较严格，发布周期比较长，现在 OpenStack 社区基本保持每 6 个月发布一个大版本的频率；而 UOS 项目的开发流程稍微灵活，能够根据具体情况进行调整，比如如果线上出现严重 bug，我们就会临时发布一个版本做 hotfix，而社区就没有这种需求；同时，对于一部分自研项目，我们的开发周期也尽可能短，让客户能够尽快用上功能更丰富、体验更好、更稳定的版本，我们尽可能通过完整的测试流程来保证产品质量，缩短发布周期。

最后，对于交付方式，OpenStack 的目标是提供一个稳定版本，只需要在保证功能的基础上，避免代码中出现严重 bug 即可交付；而 UOS 的目标不仅是让 OpenStack 真正在客户生产环境中稳定地运行，同时需要给客户提供持续运营的能力。

UOS 项目

UOS 项目主要分为两类，第一类是社区项目，主要基于 OpenStack 原生项目进行开发；第二类是自研项目，主要是指在实际生产中，由于社区不提供或者做的不够好的，我们自研的项目。其中，社区项目大概占所有项目的 45%，而自研项目大概是 55% 左右。

社区项目主要包括 OpenStack 的主要项目，比如用于认证的 Keystone 项目，用于计算的 Nova 项目，用于网络的 Neutron 项目等，我们都在这些项目基础上做了深度的二次开发。

自研项目包括面板项目、计费系统、工单系统、动态配置服务、线上健康检查服务等。以面板项目为例，我们几乎重写了 OpenStack 整个控制面板，同时提供功能全面的运营管理系统对整个平台的资源进行统一管理。

社区项目

我们对社区项目采取的策略是这样的：对于不满足需求的功能，在社区项目的基础上做二次开发，但在开发之前必须要深入理解项目的代码结构和开发方式，这也是我们之前提到参与社区开发的目的，因为只有理解掌握了，才知道怎么去改进它。

在开发过程中，我们遵循一个原则：只做扩展，不做修改。也就是尽量以插件的形式进行开发，不对原生代码做侵入性的改动。这样做有几个好处，一是在未来大版本升级时，可以最大化地减少代码冲突，以最小的代价更新到新版本；二是保持所有原生 API 的兼容性，这样就可以利用 OpenStack 现有的生态圈，更方便地与 OpenStack 现有系统和周边工具进行集成。

最后，也是做社区项目最重要的一点，必须时刻保持与社区的同步，这并不是说需要保持代码的时时更新，而是需要关注社区的发展和趋势，对变化做到未雨绸缪。

从上面我们可以看出，基于社区项目做二次开发是一个比较辛苦的过程，不仅需要深入了解社区代码，还需要对需求和 OpenStack 生态系统有深度的把握能力，这对团队的要求是比较高的。

自研项目

对于自研项目，我们要求以社区规范进行开发，要求有完善的文档和测试用例，并且在需要的时候能够反馈社区。

三. 开源文化如何影响公司

既然开源社区和开源文化对我们如此重要，那么我们公司在开源文化的影响下，又做了哪些改变呢？个人感触较深的主要有三个方面：新人培养机制、信息传递方式和公司组织结构。

新人培养机制

我们希望利用社区优秀的资源对新员工进行培养。在 UnitedStack，新员工在入职的第一个月会全职参与社区开发，我们会要求他先阅读社区文档，了解 OpenStack 社区的项目结构和开发流程；然后挑选一个项目，让他向这个项目提交代码。通过这种方式，我们希望他能够完整地经历一遍社区的开发流程，这样能够对代码风格、测试用例、Git 分支管理等未来开发中常用的知识，都能有比较系统的感受和了解。

我们相信工程师在参与社区开发以后，能够在技术能力和工作协作方式这两方面得到提升，能更全面了解 OpenStack 的技术栈，熟悉文档、开发、测试各个环节。比如我们有位工程师，为了合并一百行的代码，先后向社区提交了五十几个 Patch，这从另一方面也说明社区开发的严谨性。

信息传递方式

开源文化让我们的信息传递更加开放透明。在公司内部，我们要求所有技术文档完全开放，所有会议纪要完全公开，这些要求其实很多公司都能做到，但最重要的一点，这一点我认为也是社区文化的精髓，我们要求所有的文档都要做到无障碍阅读。

什么是无障碍阅读呢？

对于技术文档，无论是一个对该领域完全陌生的初学者，还是在某一方面比较资深的工程师，在阅读完你的文档以后，都能够有收获，技术文档必须要做到深入浅出，这样才能鼓励公司内部的知识流通，让更多同事能够自由选择自己的感兴趣的内容进行学习，同时他们也能够帮助完善文档，让技术知识在公司内部沉淀和传播。而会议纪要的无障碍阅读，就是要让没有参加会议的人在阅读完会议纪要以后，也能够知道你们在会上讨论了什么事情，形成什么样的结论。

公司组织架构

最后，在组织架构上，开源文化促进我们更加扁平化。虽然扁平化这个词已经泛滥了，但我认为很多公司只做到了形式上的扁平化，而没有真正做到内在管理和工作方式的扁平化。

在典型的金字塔结构的公司中，指令由上到下传达，一线工程师按照指令执行工作。为了消除这种金字塔的结构，我们参照社区的方式，整个研发中心只由几个主要项目组组成。在每个项目组里选出一位 PTL 作为项目负责人，负责管理项目组内部的所有工作，PTL 在项目组内部有很大的自主权。为了协调项目组之间的工作，以及解决整个研发层面的事务，我们还成立一个技术委员会，由几位在各自领域非常资深的 PTL 构成。

PTL 作为整个项目组的负责人，负责项目组内部从产品、研发、测试、运维到部署等各环节的工作。我们对 PTL 的要求是要以社区方式运营项目组，比如开放内部文档给全体员工，接纳来自公司任何人的代码提交和建议。并通过提升项目组的质量，吸引更多的工程师加入项目组。

技术委员会（TC）代表整个研发的最高水准，负责公司研发相关的方向和决策的制定。TC 的所有工作并不是向某一个领导汇报，而是需要向全员公开。我们对 TC 有一个很重要的要求：问题止于 TC。也就是研发层面的事情，如果由项目组上升到 TC，那么在 TC 这一层面必须得到解决，没有再往上抛的余地，所以我们要求 TC 成员必须是公司里某一领域非常专业的工程师。

我们要求每个工程师必须归属一个项目组，在此基础上，工程师可以按照自己的兴趣加入任何项目组。我们相信，只有兴趣才是工作最大的动力。
基于这样的组织结构，项目组内部可以形成研发闭环，产品、开发、测试、部署、运维都可以在项目组内部完成，大大消除了部门之间的沟通成本。当然这对团队成员也有很高的要求，他们不单单要专注于自己的工作，还需要对其它领域的工作内容也比较熟悉。