这是一个开源的时代，这也是一个开源价值被逐渐认同的时代，大家如何认识开源，如何使用开源？如何平衡社区开发与公司开发的关系？ 在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成员 必须是公司里某一领域非常专业的工程师。 我们要求每个工程师必须归属一个项目组，在此基础上，工程师可以按照自己的兴趣加入任何项目组。我们相信，只有兴趣才是工作最大的动力。 基于这样的组织结构，项目组内部可以形成研发闭环，产品、开发、测试、部署、运维都可以在项目组内部完成，大大消除了部门之间的沟通成本。当然这对团队成员也有很高的要求，他们不单单要专注于自己的工作，还需要对其它领域的工作内容也比较熟悉。 总结我们在开源实践中最重要的收获，归结起来只有两点：首先是技术，我们学习和利用开源社区的技术，同时也贡献自己的工作；但更重要的是，我们要学习和运用开源社区的管理精神，时刻保持开放透明！ |
