Linuxeden开源社区
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 亿多行的代码，它们作为主干支撑着全球广泛使用的应用程序。
转自 https://www.infoq.cn/article/cjpGOkvphzkHN*vw4eNk