座谈会：Apache基金会那些事儿

2018年10月13日下午，开源微服务项目ServiceComb的团队邀请Apache基金会高管，与国内Apache项目开发者相聚于上海。针对开发者所关心的主题进行了深入的交流。讨论问题主要包括：

如何从Apache软件基金会孵化器毕业成为顶级项目
对于构建持续增长的社区，有何建议？
项目的提交者和PMC成员不够活跃，我应该怎么办？
发版投票过程漫长，如何保持正确的发版“姿势”？
如何使用开源软件进行商业化？

下面提到的嘉宾分别为：

Justin Mclean，Apache孵化器主席
Roman Shaposhnik，Apache董事会董事
Craig Russell，Apache秘书长
姜宁，Apache CXF项目作者，Apache ServiceComb项目负责人
吴晟，Apache Skywalking项目作者
史少锋，Apache Kylin核心开发者兼PMC
张天伦，Apache Gearpump项目committer

姜宁：今天咱们聚集了国内大部分的Apache相关项目的committer，这些项目包括Beam、ServiceComb、Dubbo、Gearpump、Griffin、Kerlin、Skywalking和Weex。这些Apache项目大部分都还在孵化器中孵化，同时还有一些准备进入Apache孵化的项目。

我在2006年9月作为Apache CXF 项目初始 committer与Apache软件基金会结缘，2011年1月正式成为 Apache基金会成员。我作为基金会项目导师（Mentor）参与了多个来自中国的Apache孵化器项目。2017年，我作为项目负责人推动ServiceComb进入Apache 孵化器进行孵化，现在 ServiceComb已经很快就要从Apache孵化器毕业了。

虽然参与了许多Apache开源项目，坦白地说我对Apache的项目孵化流程并未有系统化全面的理解。直到ServiceComb这个项目，我经历了寻找Mentor，捐赠协议签署，迁移项目，孵化器发版，以及毕业准备这些流程之后，才对Apache孵化器孵化流程有了更加深刻的认识。

就在刚刚的交流中，我发现大家最关心的问题就是如何从Apache孵化器毕业。我们今天邀请到远道而来的Apache Member，Roman，Justin，Craig，和国内Apache项目开发者一起分享他们有关Apache孵化器孵化经验，以及开源相关的感悟。

如何从Apache软件基金会孵化器毕业成为顶级项目

Justin：从Apache孵化器毕业，首要为孵化项目构建一个社区，项目毕业意味着很多事情，比如要保持开发者的多样性，项目贡献者不能仅仅来自一个公司。此外，还应该尝试小版本发布（make micro releases）。

Roman：发布版本时，除了项目本身，还有许多合规性工作（mechanical stuff）要做，例如开源协议，发版签名，发版投票等等。项目进入孵化器后，要尽快尝试发布第一个版本。许多孵化项目（podling）都想在发布版本时中搞定这样或那样的功能，我总是跟他们说，没关系，项目不一定能够跑起来，甚至不一定能成功编译，一定要先把合规性问题解决，然后再专注于功能开发。

Justin：没错，要尽早发版、多做发版。

姜宁：发布版本尽管痛苦，但是要尽早去做。ServiceComb在发布第一个版本时，团队也非常痛苦，但是经历过这个阶段，后面会变得越来越顺利。

总结：孵化器毕业要点解读

构建社区
ASF一直坚信好的软件是由强大的社区构建出来的。诚然，代码是一个软件社区的重中之重，但Apache之道”Community over code”同样强调社区的重要性。它意味着我们的行事方式，如何看待彼此，如何进行决策，甚至如何编写代码。健康、互相尊重的社区非常重要，这不仅让社区的开发者有被尊重的感觉，也会带来切实的好处。一个健康、多样、包容的社区，可以促进项目不断成长，可持续发展。甚至，有助于用开源技术提供服务的公司获得商业上的成功。

保持贡献者多样性
ASF非常强调多样性原则。大部分开源软件项目都是创新型项目，多样性保证了开源项目的持续创新，也保证了社区的健康发展。开源项目鼓励所有个体或公司参与，让他们感觉能对项目有所掌控，或者会对项目产生一定影响。这样可以保证意见的多样性、用户的多样性、系统的的多样性。Apache项目通常是要求有三个以上不同公司的人参与开发，以保证项目不会因为其中某个公司的退出而终止。

尽早、尽量多的进行版本发布

对于构建持续增长的社区，有何建议？

Justin：要让大家觉得自己是受欢迎的。当有人在邮件列表中提问时，我通常会分配PMC成员关注问题，并咨询提问者是否还需要其他帮助，或者有其他问题，我把这个作为日常工作。这样也有利于开发者从用户变成提交者甚至PMC成员。良好的文档可以让大家更容易使用你的项目。而文档的缺失则可能造成用户的流失，人们编译编译代码，就再也不使用这个项目了，因为项目上手太难了。

Roman：良好的文档确实非常重要。此外，我也有其他方面的建议。Apache软件基金会参与了一些项目，吸引了不少开贡献者。我们一直指导Google代码夏令营活动，夏令营由Google赞助，帮开发者更好的发展他们自己的项目。如果你可以让自己的社区参加类似的活动，对于社区建设无疑是有很大帮助的。因为大家来自中国的社区，我也建议一些中国的大公司，例如华为，也可以举办类似的学生项目，学生是一个项目最好的新鲜血液。

Justin：在会议中分享项目、建立技术博客也是不错的方式。

吴晟：Skywalking是中国开发者发起的一个Apache孵化项目，刚加入孵化时只有15个committer，而现在，代码层面的提交者已经达到了70人。我们提倡大家提交小的改动，这样很容易提交代码来做贡献，所以我们每次发布版本都会吸引一些开发者。当我们没有太多精力投入到测试时，我们会吸引开发者来提供测试，他们可以提交集成测试结果，可以提交测试模型，只要保持正确的编程风格，PMC的成员就可以进行审查，并合并代码。

Justin：这里我想多提一点，很多项目过于注重质量。有些Apache项目收到一些代码不太完美的提交，就直接丢弃了这些提交，然后自己从头搞起。其实这并没有关系，如果你收到了不太完美的PR，可以请社区成员帮忙改进质量。另外，在JIRA或Github上浏览issue时，如果发现一些比较简单的issue，你可以加个”easy to fix”标签，告诉大家这个issue比较容易解决，这样也可以吸引人来贡献。

吴晟：没错，我们也会跟踪一些讨论，有些时候我们可能会考虑过于理想的方案。但是好的项目有时候并不完全是完美的代码决定的，还要考虑不同的场景。这样项目才能不断壮大。

姜宁：我也谈谈自己的感受，我非常赞同Justin所说的“Low the bar”。我在参与Apache Camel项目开发时，它已经非常成熟了，但是我们还采用先提交后Review的方式进开发。有很多人为Camel提交Patch，我们从来不说“No”。有些人提交的代码质量可能并不太好，我们还是会接受这些补丁，让贡献者觉得自己得到认可。这样，开发者就不会想“啊，我还不够优秀，还无法成为committer，我提交的补丁也不够好，那我还是不提交补丁了。” 在我们合入代码时候，我们也会顺道帮助修复一下补丁上面的问题。顺便说一句，Apache Camel现在有200多个组件，目前项目只有大概4，5个人在维护，很大程度上是得益与这种降低社区门槛的方式。

总结：构建社区的建议

让大家觉得自己是受欢迎的。
编写良好的文档，降低初学者入门难度。
参与或组织类似Google代码夏令营的学生项目。
在技术会议中分享项目经验，建立技术博客传播技术。
提倡小的改动，乐于接受他人的贡献，乐于帮助改进质量，让开发者更容易参与社区贡献。

项目的提交者和PMC成员不够活跃，我应该怎么办？

史少锋：有些开发者成为提交者后就消失了，有时候PMC成员也不能非常及时的审查提交，有没有什么规则推动大家活跃起来？

Justin：我觉得提交者或者PMC成员不活跃并不是问题，不是所有人都必须活跃。但是如果项目的导师不活跃就是问题了，因为导师要指导项目，告诉项目成员正确的做事方法。我们没办法为提交者和PMC成员制定“（及时反馈的）规则”，这样对他们要求太高了。我们应该降低门槛，让更多人参与进来。

Roman：通常，每个项目的PMC都有VP（Vice President），VP主要负责合规性相关的工作，向Apache董事会汇报，但是VP也要担当起项目的领导者角色。即便所有其他PMC成员都在沉睡，VP也是唯一要保持清醒的人。VP是默认的那个要回答问题的人，当然不是技术相关的问题，而是回答管理流程相关的问题。如果邮件列表无人响应，你要写信给VP，告诉他，“嘿，大家似乎都睡着了，我们应该怎么办呢？”。VP有权利做出改变，他可以组织大家开始审查提交，让大家醒过来。

总结：PMC沉睡了怎么办

Apache基金会是个公益组织，不能通过强制要求来约束成员。
可以通过降低门槛，让更多人可以参与进来，解决社区响应不及时的问题。
VP承担项目领导责任，要时刻保持活跃。遇到问题可以向VP寻求帮助

在Apache软件基金会的组织结构中，Apache董事会根据基金会的管理原则，负责管理和监督对外合作的商业和事务，包括基金、知识资产、注册商标等。每个Apache项目都有一个PMC（项目管理委员会），负责项目的管理和监督，并定期向Apache董事会汇报项目情况。PMC有一位主席（Chairperson），也被称为该项目的Vice President，简称VP。VP由董事会指定，是董事会和项目之间的接口人，负责项目汇报、同时与PMC一同保证项目和代码遵从法规、管理商标事务、管理邮件列表等合规性问题，发展新的Committer和PMC成员。

发版投票过程漫长，如何保持正确的发版“姿势”？

张天伦：发版投票需要经过至少72+72个小时，过程非常漫长，又担心犯错误导致投票过少进而导致发版失败。并且，有时候发起投票，响应的人比较少。

Justin：犯一次错误没关系，可以向导师寻求帮助以避免重复多次犯错误。在开始的一两次发版中，有一些错误很正常，但是后续的版本发布就会越来越顺利。如果发版时响应人数比较少，可以直接在邮件列表中提醒孵化器项目管理委员会（IPMC）成员，特别是导师，进行投票。

Roman：我想大家对敏捷开发都比较熟悉，敏捷开发提倡小幅度的改动，多进行更新。如果你的项目遵循敏捷开发方式，将对版本发布大有裨益。我指导项目孵化时，除了首次发版需要在合规性方面花费很多时间，后面的版本尽量在每个月或每两个月发布一次，新版本不一定要加入很多功能，每月发一次版本，更容易让IPMC的成员审查新版本的变动。因此，首次发版，解决合规性问题，然后尽快发版，多做发版。

Justin：另外，可以将新版本改动写入版本说明中，可以让审查工作变得轻松很多。

Roman：没错，小幅度迭代也可以帮你构建社区。社区贡献者提交的补丁越小，越容易进行审查。

总结：Apache孵化器发布版本的要点

不要担心在发版时犯错误，大胆的向导师和IPMC成员寻求帮助，但要避免犯重复的错误
借鉴敏捷开发模式，小版本迭代，频繁更新
首次发版扫除一切合规性问题，后续版本专注功能和质量
让版本更新更容易审查

如何使用开源软件进行商业化？

Roman：开源商业化的模式是多种多样的。红帽（RedHat）就是一个很成功的例子，他们用开源收益颇丰。也有一些新的公司，例如我曾工作过的Cloudera，利用开源赚钱，至少赚到了买下Hortonworks公司的钱（众人笑）。

我大致可以列出3种开源商业化的模式。首先，几乎所有云服务厂商都使用开源产品，将其变成服务来进行营利，这就是一个很常见的商业化模式。例如，我很惊喜地看到华为云的流服务使用了Apache Flink，这就是华为使用开源盈利的方式。

另外一种比较传统但应用广泛的商模式，以开源软件为核心构建产品，并提供额外的组件和技术。这些额外的部分不一定是开源的。例如你的产品可以用Apache项目作为核心，然后加入GPL协议的组件，再加上一些私有的组件，然后就可以像微软出售Windows系统，或者Adobe出售Adobe Creative Suite那样盈利了。

第三种商业化模式，就是基于开源软件提供差异化的集成服务或者解决方案。将开源软件集成为一个更大的系统，提供给客户以进行营利。你可以运营一个专业的服务公司，用开源软件帮助用户简化业务。例如，你的公司服务于酒店或工厂，帮他们实现自动化运维。客户并不在乎你用什么软件或技术，他们只关心端到端的方案能够顺利实施。你的公司使用开源软件，可以按照自己的需求进行优化，也避免了收费的商业软件侵占你的利润。

Craig：在培训行业，经常有公司需要培训自己的员工来学习、使用Apache软件。我们曾短暂的考虑过和商业公司合作提供培训服务，然后与商业公司分享利润。但是这个念头只是一闪而过就被我们否决了，这样会与提供Apache软件培训服务的人形成竞争，这样有悖于Apache厂商中立的原则。所以，如果你想通过开源软件培训来盈利，大胆去做，这也是一个不错的开源商业化模式。

总结：开源商业化的几种方式

用开源软件提供服务，例如那些云服务厂商
基于开源软件提供额外的收费功能
利用开源软件提供集成服务，并提供商业支持
开展开源软件的培训服务

关于Apache基金会

Apache软件基金会是一个成立于1999年的非盈利慈善组织，英文名称 Apache Software Foundation，简称 ASF，最早源于开发Apache HTTP服务器的一个爱好者组织“Apache组织”。经过近20年的发展，Apache软件基金会已成为世界上最大的开源基金会，负责监管350多个免费的企业级项目和1.9亿多行的代码，它们作为主干支撑着全球广泛使用的应用程序。