我是温铭，深圳支流科技的联合创始人，开源微服务 API 网关 Apache APISIX 的 PPMC，OpenResty 软件基金会创始人和第一任主席，360 开源委员会发起人，极客时间《OpenResty 从入门到实战》专栏作者。
为什么写这篇文章？
还不是今年春节假期，在家不能外出憋坏了嘛。闲着也是闲着，不如把最近 3 年在基础软件领域创业的经验和教训总结下。
关于中国的开源项目、社区和创业，很多的分享都是讲自己的成功经验，其实背后还有更多尚未成功者的身影，他们的经验也能提供另外一个维度的视角。
我希望能通过这篇文章，让大家能够更深层次的理解下面这些和开源相关的常见疑问：
- 如何运营开源社区？
- 如何选择和评价开源项目？
- 国内外开源文化为什么会有差异？
- 技术创业的坑有哪些？
- 开源项目在国内如何商业化？
在读文章之前，我来花点儿篇幅介绍下自己的背景，这有利于你来更好的理解本文。
与开源结缘
我是一个服务端工程师，创业之前在互联网安全公司工作了 10 年，主要从事服务端的开发和架构，负责过木马云查杀、反钓鱼欺诈和企业安全产品。
我刚开始工作的时候，就有幸和当时国内 Python 社区的几位大牛共事：Zoom Quiet、March Liu 和 Albert Lee，除了技术上的提升之外，更多的是在开源文化上的启蒙和熏陶：选择开源软件而不是自己造轮子；对于邮件列表的认同；对参与开源项目的文档和翻译工作的尊重；对软件版权的重视；信息的公开和透明等。简单的说，就是树立了一个正确的三观，但还没有太多具体的实践。
后面在新项目的选型中开始接触 OpenResty，但苦于当时找不到学习的书籍和资料，只能摸着石头过河，磕磕绊绊的把系统搭建起来。随着团队中新同学的加入，OpenResty 相关知识的沉淀和升华，成为一个迫在眉睫的问题。于是，我开始通过 GitHub 开源项目的方式，来编写《OpenResty 最佳实践》这本电子书。随着贡献者和关注者的增加，需要一个更加实时的渠道来增加沟通，于是 QQ群、微信群也开始建立起来，并通过几年的自然沉淀，有了一个近万人的开发者社区。
认识的网友多了，自然就有了线下见面的打算，于是每年的 OpenResty 大会、定期的 meetup 也就应运而生了。至此，一个野生的社区，被一本电子书无心插柳的灌溉而且成长起来了。
随着社区的快速成长，很快，我就意识到软件基金会的重要性，和大部分的技术社区一样，我的脑海中也浮现出一样的疑问：为什么中国没有类似 Apache 这样的软件基金会？
当时我并没有想明白这个问题，而是转向了另外一个更让我兴奋的挑战：
既然没有，为什么不去做第一个吃螃蟹的人，来创立中国第一家合法的软件基金会，帮助国内众多的开源项目走向世界呢？
经过一番研究和比较后，我在 2015 年 10 月份向香港税务局递交了OpenResty 软件基金会有限公司的成立申请。没错，软件基金会本质上也是有限公司，只是没有股份的概念。
令人惊喜的是，锤子科技 2015 年底发布会的收入也想捐赠给国内的开源项目，这和 OpenResty 基金会创办的初衷一拍即合。后面的故事大家都知道了，经过两年多的曲折，OpenResty 软件基金会终于获得了接收捐款的资质，顺利收到近 100 万人民币的捐款。
2017 年初，我从 360 离职，以合伙人身份加入到某开源创业公司工作了 2 年。
2019 年 4 月创办了深圳支流科技，从零开始构建微服务 API 网关：APISIX，保持了每个月一个里程碑的快速发展，并在 2019 年 10 月进入 Apache 孵化器。Apache APISIX 主项目有 60 位贡献者和 14 位 committer，还有 1000 多名开发者组成的 QQ 讨论组（群号552030619）。
包括腾讯云、奇虎 360、贝壳找房、美国航空航天局、欧盟 eFactory 等知名公司或机构正在使用 Apache APISIX：
上面这些从无到有的构建开源社区、开源基金会、开源委员会、开源项目、开源创业公司的经历，让我对开源有了更多的认识和思考。从某种意义上来讲，我算得上是中国开源界纵切面上一个很好的样本。下面的内容就是我这个样本的一些思考了。
忘掉 star 数，活跃度才是衡量开源项目的唯一指标
我们在选择和评价一个开源项目的时候，GitHub 上的 star 数是最直观的一个指标，但也是严重失真的指标。
star 数受到很多因素的影响：项目成立时间的长短、是否有商业公司的强力 PR、是否有作弊刷量等。很多情况下，一个高 star 值的项目可能已经完成了当初的 KPI，疏于维护了。
那么，我们应该选择哪一个指标呢？GitHub 其实已经给出了标准的答案：pulse，也就是活跃度，这是 GitHub 内置的一个功能，每个人都有权限来查看此数据。下图是 Apache APISIX 的一个示例（一个月的活跃度统计数据）：
从上图中可以看到，在一个月的区间内，Apache APISIX 有 17 个贡献者参与，合并了 58 个 Pull Request，解决了 36 个 issue，新建了 21 个 issue，可见这是一个健康、活跃的开源项目。
我找了另外一个很高 star 数的项目，同样也是一个月的区间，没有 Pull Request 的合并，只解决了一个 issue，基本是休眠状态了。
如果选择了休眠的项目，那么在遇到问题的时候，你只有靠自己来解决，无法从社区得到有效的支持，这显然不是我们想要的。
除了项目的活跃度，还有另外两个维度来辅助考量：
- 贡献者的多样性。贡献者大都来自同一家公司，还是分布在多家公司？Pull Request 完全是由头部的一两个贡献者完成的，还是相对均匀的分布？
- Pull Request 和 issue 的质量。除了显而易见的数量，质量也是非常重要的：Pull Request 主要解决的是文档、注释、typo 这些问题，还是核心代码和功能点？issue 是否能够准确的描述和重现 bug？这些体现了整个社区参与者的质量，以及社区领袖的领导力。
首选软件基金会的项目
再来聊下另外一个大家经常问到的问题：为什么中国的开源项目成为国际化知名项目的并不多？是工程师都被 996 压榨的没有时间？还是我们不够聪明？
其实都不是，由中国工程师发起的开源项目绝对数量并不少，但其中不少都是 KPI 项目和独裁项目，很难形成社区和上下游生态，也无法形成开源文化的传承。
这两类项目它们都可能很活跃，按照刚才提到的活跃度的维度，是无法筛选出来的。这时候我们需要从社区的角度来观察：
- 是否有 committer 和 PMC 的选举流程？
- 是否有人有凌驾于 committer 和 PMC 之外的特权？比如只有一个人可以合并 PR 和发布版本。
- 是否有明确的商标归属权？
上面这几点不仅适用于评估成熟的开源项目，也适用刚起步的开源项目。
以 Apache APISIX 为例，有 Apache 基金会完善的 committer 和 PMC 选举机制，以及版本发布管理机制；所有 PMC 都是平权的，没有独裁者的存在，话语权需要用你的贡献来放大；代码和商标由 Apache 基金会持有，Apache 2.0 协议对于商业化非常友好。
“社区大于代码”，是 Apache 基金会的理念，也是被无数次证明过的正确理念。多年前我并没有那么认同，而经过现实的洗礼，现在我是这个理念的坚决拥护者。这也是我们坚持把 APISIX 捐赠给 Apache 基金会的原因，没有社区，就不会成长为国际顶级的开源项目。
对于普通开发者而言，没有必要去做这么多的功课，直接选择 Apache 基金会、CNCF、Linux 基金会的项目去深度参与和贡献就好。
这个话题可以进一步延伸：中国是否需要自己的软件基金会？我在 2019 年开源年会上做过类似的分享，我自己的答案是：先参与国外成熟的基金会，多孵化出来一些高质量的开源项目，影响出一大批三观正的开源贡献者，才能解决最根本的问题，建立中国自己的软件基金会并不是一个捷径。
技术人创业要迈过的第一关：不要自嗨
现在越来越多的工程师开始创业，技术上的优势很明显，但自身能否快速的成长，补上技术之外其他方面的短板，就至关重要了。这对于不少喜欢写代码的创业者来说，是一种跳出舒适圈的艰难挑战。所以，很多意识到这一点的技术大牛，一般都是担任 CTO 或者首席科学家的角色，比如 Nginx 和 Redis 的作者。
与销售、产品背景的创业者不同，技术人创业首先要避免的就是自嗨，这可能会有很多种不同的表现：喜欢优先解决技术难题，重复造轮子，追求完美等。
要解决自嗨的问题，关键是思维上的转变：
- 重视产品和商业逻辑
这是一个多大的商业机会？已有竞争对手有哪些？你的产品会带来什么改变？用户会因此买单吗？
在商业公司中，不管你的技术有多牛，都需要理顺这些基本问题。很大概率上，你并不是下一个“乔布斯”，你也不会开创一个新的万亿美元的市场。重视商业逻辑，是技术创业者的第一课。
- 把公司当做产品
如何把技术的优势，转换为有效的销售线索和付费订单？每个员工各自的优势是什么，如何最大化？团队的劣势有哪些，如何去补齐？
技术型的创业公司，需要 CEO 跳出技术的视野，把公司本身当做产品来看待。
远程工作中，充分的沟通是关键
开源项目天生就是分布式协作的，这是一种松散的结构。以 Apache APISIX 为例，现在有 60 名贡献者，虽然社区每个月都有一次线下的 meetup，但我见过面的也就 6、7 个人而已。
但对于开源商业公司而言，并不能简单的使用这种远程工作模式。在商业公司中，协作会更加的密切，而且对时效性的要求更高，当面沟通更能保证信息传递的完整性，这是远程工作难以替代的。当然，远程工作也有自己的优势，那就是吸引全球的人才。
所以，开源商业公司采用远程协作并没有问题，但一定要保证沟通的足够充分，拉平信息：
- 要视频沟通，文字只作为最终的记录。视频是沟通过程中信息丢失比较少的方式，是远程工作交流的首选方式。千万不要用文字来讨论非技术问题，这会带来巨大的信息差和误解。
- 保证沟通的尊重和善意。在开源项目中，大家因为没有雇佣关系，都是无偿做贡献，所以在异步沟通时特别强调尊重和善意；而在商业公司的远程办公时，因为缺少同事之间的沟通、吐槽和心理按摩，就更要注意沟通的尊重。
- 定期线下见面，增加相互之间的了解和信任。
另外一点，长期的远程协作，对于参与的工程师来说，除了需要很高的自律和自我管理的要求外，也要注意工作和生活的隔离，保持正常的社交活动和运动健身，否则很容易与社会脱节。
聚焦和快速发布
开源项目和创业公司一样，都是一直处于各种资源不足的状态。这时候，找准主线任务，并进行快速的发布和迭代，就显得至关重要了。
以 Apache APISIX 为例，使用者会提出五花八门的需求和意见，如何来评估是否要做以及优先级呢？其实很简单：
谁提出来的谁做，Apache APISIX 的 PPMC 保证会 review 你的 PR，达到要求就合并到主线。
听起来很简单，但其实很多开源项目是做不到及时 review 和合并 PR 的。这里面有精力不够的原因，但更多的是某些开源项目的核心开发者，想做另外一个层面的聚焦：保持代码的干净，不合并自己用不到的功能。这种做聚焦的方法当然是错误的，真正的聚焦是保持底层的稳定和灵活，以便用户可以添加更多自己的功能。
快速发布，频繁发布，也是 Apache APISIX 的一个特色。Apache APISIX 从 2019 年 4 月份开始编写代码，到 2019 年 6 月 6 号就发布第一个版本，如此快的速度，除了团队本身技术硬实力之外，也是因为这第一个版本“中看不中用”，它只有一个框架，并不能直接使用。但 Apache APISIX 之后每个月的 6 号都会发布一个新的版本，在春节前已经发布到了 1.0 版本。这种快速和频繁的发布，会逐渐现成社区的一种文化，带着项目向前发展。
对于开源创业公司也是一样，制定好长期的目标，围绕着目标来进行开发；筛选出用户的真实需求，树立行业的标杆。在这个过程中，你可能需要拒绝各种合作、定制开发等外部的诱惑，在做决策的时候需要提醒自己，这个是否符合公司的长远目标？要把有限的资源用来和时间赛跑。
最后
中国的开源社区和项目正在快速的成长，企业也接受了为基于开源的商业软件付费的概念，同时也涌现出了越来越多的商业开源软件公司。
和其他类似的 ToB 不同的是，开源软件天生是没有国界的，在中国这种大流量、复杂业务场景下起步的商业开源软件公司，一样可以去欧美市场做全球化的竞争。
期待看到更多的中国开源项目走向世界，也希望 Apache APISIX 和支流科技能在其中贡献自己的一份力量
