天啦撸，今天是2021年的最后一天了！为了纪念这过得飞快的一年，咱们来……
读一篇万字长文如何？
哈哈哈~
万众瞩目的Hashicorp都IPO快一个月了，我这错峰小作文错得有点彻底🙈2021年的最后一周选择躺平，正好补补课。毕竟在二级市场瑟瑟发抖的时节，还能稳步超越170亿美金的市值，绝对是geek的胜利🤓Hashicorp实在是一家太有意思的公司，加上两位co-founder（颜值很高而且）各种分享非常transparent, 研究的过程非常开心，收获还是很大。几个月前上市的Confluent，M小姐偷了懒，这回正好做个类比。对开源感兴趣的小伙伴，这篇长文，一定会对你有启发。可能有些技术的小伙伴只用过他们的产品未必知道这个公司？Hashicorp的理念是，Infrastructure enables innovation。也就是说infra不只是一个支持性的功能，而是技术甚至业务创新的必要条件。而Hashicorp要做的事情，就是用一系列Infra-as-code的工具，让开发者能自动化地管理从infra provisioning, security, networking, application deployment各个方面所需的基础设施。长文预警啊，不知怎么就写这么长了，大概真的是因为Hashicorp实在太有意思了！
财务数字的背后：越来越高的企业服务公司上市门槛
开源商业化 - 客户篇: 客户是谁？为什么大客户不是一蹴而就
开源商业化 - 产品篇：Packaging的艺术；社区 vs 收费版
开源商业化 - 市场与销售篇：拿捏好开源这个双刃剑
开源商业化 - 未来篇：All eyes on the CLOUD!
开源社区：22万star开源王者的playbook
把公司打造成产品：Tao of Hashicorp & 开源的公司运营
乍一看，整体业务数据跟Confluent真的好像啊！这一段是boring的经营数字分析：LTM revenue 都是$250+M——但是，这个体量都保持了50+%增速！客户总数也接近，都是2k+,超过$100k ARR的客户都是550+。而且因为是infra产品，Net Dollar Retention (NDR)也都很高，都是124%。一开始我觉得124% NDR已经很好了，然后一看发现美国上市SaaS公司top 25%的NDR竟然高达125%！仔细看的话，这些NDR的头部公司里面，除了Zoom, UiPath, smartsheet, Qualtfics, Docusign5家，其实绝大部分都是infra/dev tools公司（下面这个图还没有写上Gitlab, NDR>150%!）两家都是50+%的ARR YoY growth增长率看着不低，但是一般美国的SaaS公司上市的时候，都还在高速增长期。这个数字也就是中等偏上的水平（还是来自Clouded Judgement的博客，数据很多，推荐推荐）。而且这两家很像的是，增速都是靠SaaS产品拉起来的（这个后面单独说）。不过呢，整体public SaaS公司里，这个Median也就是34%，所以50%也绝对是一级玩家了。以前大家觉得$100M是SaaS公司上市的门槛，现在IPO时ARR中位数已经接近$200M了！不得不说，一级市场的资金越来越充裕，SaaS公司上市门槛也高了很多。
所以感慨一下，相当于十几亿RMB的收入规模，还要保持50+%的收入增速，无怪乎投资人能给出这么慷慨的PS溢价，美国市场真是企业服务公司的沃土！不过按照M小姐理性/盲目乐观的天性，还是愿意相信这在中国也是5年之类的事情。很多差异，其实没有大家吐槽的那么多。接下来，我们就要说说大家最关心的，开源商业化这个话题。M小姐觉得，Hashicorp是一个最值得研究的例子，主要原因是……
开源商业化 - 客户篇: 客户是谁？为什么大客户不是一蹴而就
Hashicorp走了绝大多数开源公司商业化的第一步：用Opencore的模式卖给大客户(enterprise)。不过，Hashicorp两位创始人（有点小nerd有点小帅的90后！）完全是技术出身，几乎没有正式工作经验。所以光是在“卖给谁”这个问题上，都走过不少弯路。这个在之后的产品篇值得具体说说。从客户数量和ACV来看很明显，而且跟confluent也类似，绝大部分收入都来自enterprise（没错，不要以为只有中国需要做大客户）。截至2021Q2，Hashicorp所有客户的平均ACV(Annual Contract Value) 超过了$140k。其中，超过$100k ARR的大客户有558个，覆盖了Forbes Global 2000中的300家，这些客户的平均ACV高达$460k！Hashicorp两位founder在回忆商业化路径的时候，很明确地说,It's very clear that we want to be an enterprise company.
之后招了Dave Mcjannet这样根正苗红的Vmware老兵来当CEO，还直接带来了个VP Sales，直接复制了很多传统Infra公司enterprise sales的经验，便是后话了。从大客户的服务方式、不同阶段客户的选择等等，从Hashicorp的经验中可以学到很多。这里说几点核心的。首先，大客户都会从on-prem或者self managed infra开始，所以，早期一定的服务（定制化？）还是需要的。这一点中国的同学们是不是就可以放心了，大客户在哪里都不好服务吼吼。Hashicorp很良心地把Subscription rev里面拆分除了License+support，占比分别是15%和80%，support还是占了绝大部分。professional services这种所有saas公司都避之不及的收入，占比倒是2-3%的健康水平。因为Support这块毛利也很高，所以整体来看，还是典型的软件公司毛利(80+%)。但是，正在积极推进cloud业务的Hashicorp,估计对license 这种pricing方式还有新的想法。我们稍后说。对比一下Confluent，还是挺惊讶地发现Confluent 的Service收入占比其实还挺高的，超过10%。但是很有意思的一点是，Confluent的services是正向的毛利率。这个是很有意思的一个选择。M小姐没有深挖两家具体的合同，但是说一个在AWS收获的小的感受: metrics define behavior. 如果services被视作一个赚钱的事情，那么公司降低其占比的动力其实就要小很多。在AWS，professional service的定义是，只能被用于expand客户新场景的事情，否则大部分都尽量交给ISV。Long story short, M小姐对于Hashicorp professional services 这样的定价，表示respect!其次，对大客户的选择是循序渐进的过程。不同阶段，需要的客户非常不一样。借助开源的力量，Fortune 500里面，79%的公司都下载过Hashicorp的产品。跟绝大部分的开源公司一样，你看他们的典型客户列表，大部分都还是比较传统的公司。然而！Mitchell在一次采访中，提出了非常非常关键的一点：不同阶段，你所需要的enterprise客户也是不一样的。他说，早期客户就是你的Design partners，所以他们对这些客户非常重视，两个founder都会经常到现场跟客户一起解决问题。每个季度都会定期去拜访，了解客户需求。但是这些enterprise有什么特点呢？Mitchell用了一个非常有意思的名称：Hipster Enterprise (他说是别的地方听到的，但是我也没有Google出来……）。他们非常techical, 对新的趋势和新的技术非常敏感而且乐于尝试。他们对于早期跟你一起打磨产品，甚至做你的evangelist，都很积极。对于Hashicorp, 这个Hispter Enterprise就是Twitch. 他们商业化开始的两年，对于Hashicorp非常重要，甚至敢于在所有server上都用了Hashicorp的产品。早在Hashicorp商业化刚刚起步的2015年，Twitch就在他们的Conference上站台，详细展示了他们如何支撑起200多万的同时在线viewers.Hipster Enterprise长期来看，的确不是什么好的客户。正是因为他们技术能力太强了，所以他们付费意愿都不会很强，也不会像其他典型的enterprise客户那样需要你的各种support。当你跟这些客户打磨好了以后，就可以转向真正典型的enterprise, 比如Fortune 500的公司。在国内谈infra的大客户，大家都会提到银行。有意思的是，Mitchell也提到了银行这个特殊的客户群体（再次表示，中美的差异的确没有想象的那么大！）。
他说，银行的IT budget实在是太多了。他们早期的一个银行客户，从第一笔$150k的单子，发展到百万美金的订单，足足用了4年。但是，那可是一个每年IT budget几十亿美金的大银行，这仍然只是九牛一毛。对此，Mitchell提出了一个很好的警醒：不要被银行大“大单”冲昏了头脑，生意要做，但是不要忘了，你的priority仍然是要build the machine，而不是服务一两个大客户。这让我想到，敝司投资的PingCAP，早年产品还非常不稳定的时候，敢于用这么alpha阶段的数据库产品的，是飞速增长中实在找不到好的方案、也没有资源和时间来自己开发的摩拜，以及一直喜欢尝试各种新产品的知乎。他们就是非常典型的Hipster Enterprise.同样的，早年PingCAP也拒绝了很多银行的项目。虽然场景足够有挑战性，钱也给得足够慷慨，但是在产品打磨的最早期阶段，合作方的技术水平和对技术前瞻性的理解，其实更是第一位的。
开源商业化 - 产品篇：Packaging的艺术；社区 vs 收费版
确定了客户只是第一步，这个产品篇，真的是重中之重。估计会很长吼吼。除了商业化产品的设计，Hashicorp还有一套非常核心的产品设计理念，我们在最后一节中介绍。不需要多介绍，大家都知道Opensource最主要的两种商业化模式，open-core和SaaS模式。因为核心的开源产品是免费的，商业化的时候，如何做产品Packaging是一个非常关键的问题。
卖平台还是卖单品，本来是Hashicorp在没有思考清楚自己的客户是谁的时候走的弯路。但是M小姐感觉，很多中国ToB公司都喜欢做所谓“平台”。所以这里面的经验教训，其实是很有借鉴意义的。
在infra公司中，Hashicorp算是少有的上市的时候就有多个商业化产品的公司。在美国这样的成熟市场，infra（甚至绝大多数SaaS）公司通常都是一个killer产品做得很深，到了后期才开始扩张产品线。但是看看Hashicorp，他们现在有8个产品（而且还在不断增加），全部都是从opensource产品开始。但是每个产品的收入和成熟度差异很大。两个明星产品Terraform (infra as code), Vault (secrets management)收入占到了85%。几乎成为了云计算backbone的Packer, 短期内似乎并没有商业化计划。这么多产品中，真正有商业化产品的目前是4个，Nomad还没有纳入SaaS产品HCP (Hashicorp Cloud Platform）。Hashicorp这个一开始就全面开花的路径，虽然现在看来，是符合“提供全套解决方案”的平台式逻辑，但是一开始还真算不上什么战略，甚至让公司走了一些弯路。两位创始人接受访谈的时候，都很坦诚地说，刚开始开发产品的时候真的没啥规划，都是根据自己的经验，想到开发者需要啥，就做啥。他们最经常提到的一个坑，就是2015年Launch了一个all in one的全家桶Atlas(是不是想到MongoDB Atlas, 创意天花板lol）。2016年的PR稿，你看看这个XXX system的架势，一上来就整一个无数feature的“平台战略”，是不是很像现在很多国内创业公司的pitch deck（我没有点名！）？当时两个刚毕业的愣头青连SMB，enterperise需要什么不一样的产品都不知道。完全没有想到这两类公司的需要有什么不同。后来他们意识到：It's just impossible to do when your business is anything for anybody. 2017年的时候，公司终于正式放弃了Atlas. 把Atlas中的这些工具都一一拆分出来。这个Bundling vs unbundling的选择是对公司影响最大的决定之一。比如，如何把分散的网站整合起来适合SEO，如何把这么多产品的Messaging变得consistent, 所有analyst relationships, devrel, marketing,甚至sales training等等资源都要重新打造。从资源消耗的角度上来说，虽然Hashicorp在产品的开发和迭代上，已经有绝对顶级的团队，但是产品打磨需要的时间和资源是快进不了的过程。Hashitomo在一次采访中说，2018年虽然我们Series D融了$100M的mega round,但是我们当时有4个产品。相当于每个产品的研发投入才$25M。对于团队其实非常有挑战。所以我们现在看到，Hashicorp两个产品占据85%的收入，这个明显的取舍，如果要按照卖平台的方式，是几乎不可能的。按照一开始bundling的思路，大概率就成了一个集合了8个60分产品的中庸平台，而不是现在这个，定义了Cloud infra管理方式的百亿美金伟大公司。第二个坑，就是多产品的研发与客户adoption的顺序不一致。下一个部分中说到Hashicorp怎么用一套Cloud Operation Model把这么多产品串联成一个解决方案，会具体说这个方案的设计。这里简单说一下，就是他们发现客户使用这些产品的顺序是上云(Terraform)->搭建多云安全 (Vault)--> 管理多云环境(Terraform+Consul)->管理多云环境中的应用分发(Nomad)。每个步骤对应不同产品。但是他们开发的时候并没有按照这个步骤。正是因为一开始对这个路径缺乏理解和规划，也导致整个sales和marketing的资源浪费。产品packaging与marketing messaging
很多开源公司，其实开始的时候都是技术先行，可能在项目和社区做起来的时候，并没有从产品角度思考得很清晰。那么开始商业化之后，怎么梳理好从产品到市场messaging的思路呢？
这一点对于Hashicorp这样的多产品公司尤其有挑战。Mitchell分享了他们CEO Dave McJannet刚上任的时候，如何引导两个创始人思考enterprise产品的marketing messaging的案例。里面用到的framework,或许对正在准备从项目到产品转型的开源创业者有不少借鉴意义。Dave一上来就说，我们需要一个corporate mission. 具体是：We need an one line: What is the solution that this product addresses? 然后在这个solution中拆分出具体的use case.至少从招股书上看，现在Hashicorp的mission很清晰：Our foundational technologies solve the core infrastructure challenges of cloud adoption by enabling an operating model that unlocks the full potential of modern public and private clouds.下面将Cloud Operating Model拆分为：a standardized approach to automating the critical processes involved in delivering applications in the cloud (infrastructure provisioning, security, networking, and application deployment).事实上，明确这样的marketing messaging不只是为了sales pitch, conference talk这些对外场合，也使得整个公司在制定product roadmap的时候有章可循——在不改变公司是engineering-led的前提下，反而还统一了阵线。一句话概括，不要因为Hashicorp全面开花的产品战略，就把“做平台”看成理所当然。Solving every problem for everyone is solving no problem for nobody.
这应该是是谈到开源公司商业化，大家最在意的问题了吧。
公认的最简单直观的做法是，只有team和enterprise才care的功能，就不要放在opensource里面，比如SSO,access control, auditing等。但是这里面总有一些难以把握的点，知易行难。参考一下，Confluent Open-core产品的commercial features (除了SLA和enterprise support之外）：Terraform的pricing就更简单直接了：Hashicorp的co-founder Mitchell在一次访谈中分享了一些非常实操的细节，对大家应该会很有帮助！首先，用一个很容易理解的framework区分用户需求, 把企业管理infra中会遇到的挑战分成三类，individual, team, organizational challenges .Enterprise版本遵循一个原则：technical challenges都要在免费的开源层面解决(We do not make technical challenges enterprise).比如，一般大家会把安全放在enterprise版本里面，但是因为Vault是一个安全产品，所以“you should not have to pay us to be secure as Vault”。开源版本里面也可以满足非常高的安全要求。但是，什么是organizational solutions呢？比如，是否满足GDPR，以及各种数据管理法规等等，都不是技术问题，所以放在付费版本里。对于Team,原则就是：个人或者小的team应该可以永远免费使用。但是，涉及跨团队协作的功能就要收费，因为这也是典型的organizational challenges.PLG产品的核心也是，要把价格门槛低的核心产品做的简单易用，同时又要兼顾未来组织内部对产品的复杂需求。因此，PLG模式中对于产品的设计，跟这里说到的，开源软件商业版的设计，其实有一些异曲同工之处。最典型的，就是设计PLG产品时候要考虑的三层Aha Moment.推荐大家去温习一下那篇万字长文哈~（不要被吓到！）其次，Sell use cases, instead of features。这个有点可能说起来有点抽象。从这个角度思考，主要是因为，一旦进入对具体功能应该开源还是收费的讨论，往往容易钻牛角尖。Mitchell说，要把讨论放到一个具体的use case,而不是某一个功能，这样对于sales也会更好沟通。一个具体的例子，如果要卖的是governance. 这里面包括了policy, framework，MFA(multi-factor authentication)等等。不论在内部（与研发团队）还是外部（与客户），都不应该讨论具体某个功能讨论是否应该收费，应该直接说，我们提供的是“为组织提供更强的policy”。
即使某些功能在开源中有，但是这些功能无法从一个完整的use case level来解决企业面对的问题。值得注意的是，这个messaging, 不止是对客户的，在对内沟通中也尤其重要。
因为这种engineering driven的公司，工程师们对于某个feature的讨论，容易陷入技术细节。要在日常沟通中，设立好一个大家align的决策框架。
最后，把视角拉远一点，来谈谈产品的timing. 以及，与其试图预测timing, 不如朴素地从自己的身边开始寻找机会。任何产品的成功，正确的timing无疑是必要非充分条件。但是，pitch deck里面所谓的通过什么行业趋势、gartner报告预判出的“大势”，其实都是后验的。真正的机会，很多时候都来自一线。现在回看，我们可以很容易说，Hashicorp抓住了企业上云、数字化转型、多云管理的趋势云云。实际上的确是的，比如下面这张图，的确可以说明，当企业从static的上一代IT管理模式向多云、混合云这种更复杂的infra转型，所面对的挑战。然而，Hashicorp的co-founder Mitchell很实诚地说，公司的第一个产品Vagrant. 2010年第一次release的时候，其实跟cloud啥关系都没有。当时Mitchell正在各种学校、startup、IT咨询等项目中，需要建很多网站,app等，结果发现自己要不断重复配置环境太麻烦，就做了Vagrant来自动做VM-base应用的provision和部署。有意思的是，他说一开始融资很不顺利，因为没有人愿意为Vagrant买单。反而是Docker出现以后，大家恍然大悟，都按照Docker competitor的逻辑来投资。但是，机会也是留给有准备的人。Hashicorp的两位founder没有停留在Vagrant vs Docker的战役中，而是很快地发现并理解了上云的趋势，迅速地围绕上云的workflow开发出了一系列的工具。看看他们的速度，也是非常可圈可点。前面也说道，直到现在，或许未来，Vagrant都没有商业化，但是了不起的创业者，就是会抓住每一个时机，不积跬步，就没有现在的百亿美金公司。最后的最后，值得思考的是，如何在中国的实际环境中理解这个timing的问题。以后想要写一篇文章更具体地说说，这里简单提一句，就是中国因为有了美国这个巨人的肩膀，我们看到整个上云的infra和PaaS发展都很快。这种环境中，一方面，很难有当年Hashicorp这种慢慢打磨和试错的luxury；另一方面，很多源自美国的工具，借助开源，也可以很快地介入国内市场。怎样在这样的时间差中，发现差异化的机会，并且迅速打造产品和社区，对于中国infra创业者来说，其实是更高的要求。
开源商业化 - 市场与销售篇：拿捏好开源这个双刃剑
虽然现在整个资本市场（其实也包括M小姐自己，lol）对开源很上头，但是有一说一，不要神话开源。开源是很好的marketing利器，但是对sales其实提出了更高的挑战。这里值得注意的是，在早期，开源公司要拿到一些客户订单并不难。但是这里说到市场和销售，核心是repeatable/scalable。就是怎么把早期偏服务的个例，经过product packaging，再构建一个sales & marketing machine，形成一个可复制的机制。在这个过程中，很多公司会发现，开源模式其实是个双刃剑。
经历了前期的产品打磨，我们看到成功的开源公司开始商业化之后，大小客户数量和收入增长都非常的快。比如Hashicorp, ARR超过$100k的大客户从200到超过550，只花了不到两年时间！事实上，Hashicorp即使在走了好些弯路之后，从$1M到$100M ARR，只用了惊人的不到3年时间！Confluent也是这样。ARR从$65M增长到$230+M,只用了不到3年时间，在几亿美金的体量，各种体量的客户增速都在50%以上。尤其是对于售卖Infra产品的startup，早期的信任成本非常高。在没有开源社区背书的基础上，可能连Hipster Enterprise客户都找不到。另一个角度来说，利用开源形成事实标准，是企业最牢固的隐形护城河。也就是说，一旦你成为了事实标准，社区用户即使没有付费，也是你的护城河，因为他们一旦有付费的需要，你的产品肯定是在优先考虑位置上，极大挤压竞争对手的空间。这里的竞争对手甚至包括，有可能将自研产品开源出来的科技大厂。科技大厂不是目标付费客户，但是他们内部使用开源产品替代自研产品，实在太普遍了。举个例子说明开源为什么能形成这样的护城河——甚至你不需要是这个idea的原创者。Hashicorp最经典的Terraform绝对是业界标准了。但是，这个infra as code的idea也不是Hashicorp原创，而是受到了AWS 2011年推出的CloudFormation的启发。Mitchell在CloudFormation推出的时候写的这篇文章，真是强烈推荐大家去读一下。文章不长，但是思路超级清晰。核心观点就是：AWS这个idea太牛X了，现在我还不需要(not yet),但是未来需要了，我就会做一个opensource版本出来。3.5年以后，2014年，随着Hashicorp自己的工作中遇到的痛点越来越明显，他们终于决定自己做一个开源产品。那时候，Terraform还是有点早于时代，18个月里都没什么下载，甚至一度在内部讨论是否要废掉。最后坚持下来之后，2017年才开始起飞，得到了Azure的公开支持之后，每个月下载量都double, 现在总下载量已经超过了100,000,000！即使坐拥AWS这样的大树，作为先行者，CloudFormation的影响力，都无法与Terraform相比了。当然，这个过程，就像Terraform所经历的停滞期，肯定不是一帆风顺的。开源跟PLG模式异曲同工，二者依赖社区和产品的力量，在最终爆发之前厚积薄发的过程，其实是很考验团队（以及投资人）的定力的。毕竟，ToB的产品，多招几个sales,好像70分的产品也可以很快见到现金流。
但是，企业最终的天花板，也酝酿就在这种定力之中了。
开源模式下，sales最大的挑战就是公司自己的开源产品。
也难怪Hashicorp的两位founder在访谈中都提到。Opensource "hurts" sales.直觉上来说，开源模式的S&M (Sales & Marketing)花费应该比传统软件公司要少呀。但是Hashicorp S&M/Rev 比例超过60%，在整个public SaaS公司中，算是比较高的了（我也不知道Monday.com那个比例是抽风了么……）首先，Infra软件公司上市的时候，除了Digital Ocean这样的异类，大多数还是以大客户为主。因为Mission critical的特殊性，销售成本本身就很高。Snowflake已经是是含着金汤匙出生的enterprise sales专业户，上市的时候，S&M/rev高达111%！远高于其他开源infra公司。另外，从资金利用率的角度来看，Snowflake上市前的总融资额，也比几个开源infra公司高出了好几倍。其次，前面也提到，infra公司的NDR一般都很高（120+%），而且，IPO通常都是在SaaS产品launch一年多的时间，大家也希望在开始发力SaaS模式之后，S&M费用的占比能够有较明显的下降（当然我也被Snowflake优化费用的能力震惊了！）下图是最新的美国public SaaS公司的运营指标。坦率来说，目前所有开源公司的确都还没有在S&M开销上展现出优势。但是这里说一个fun fact: 你猜猜Oracle最新的S&M/Rev占比是多少？不到19%！（即使完全去掉硬件收入，也就22%哦）开源商业化的另一个特点是，开源天生就是global的生意。Hashicorp和Confluent的国际业务发展都很快。两家商业化都是5年左右的时间，都已经有35%的收入来自美国以外。Hashicorp的产品在超过40个国家销售，美国以外的收入占比已经接近30%。Confluent 在美国以外的收入，不断增加，现在已经有35%。要知道，很多上市五六年的成熟SaaS公司，美国以外的收入可能也就是30%左右。这种扩张速度，对于一个公司来说，看着漂亮，其实里面的挑战之多也可想而知，毕竟面对的都是大客户啊。说回来，既然是针对大客户的底层产品，Hashicorp也遵循了很多ToB领域普适的经验。大概是因为有了个ToB老兵，Hashicorp在开始商业化以后第二年就开始大力发展partners, 三四年的时间，已经建立起来一个170+ ISVs，超过450个integration partner的网络。这一部分的经验其实跟大部分saas公司也很像，先找到product market fit, sales通路跑通了就开始scale. 要干脆利落的明确boundaries，把value add不高的工作都给partners.
Hashicorp向我们展示了一个非常重要的思路：
最先进的enterprise software公司，输出的不仅是工具，更是工具背后的方法论(当然，输出方法论的成本也是不低的)。撇开开源这个大的背景，我们看到Hashicorp的一个特殊性：与MongoDB这种数据库不同，Hashicorp的产品不只是“性能更好的XXX”，可以说是开创了新的品类，涉及到客户workflow的改变（后面我们会提到这一点）。这种情况下，面对大客户，只是交给对方工具远远不够。一方面，Hashicorp提供的管理infra这么底层的mission critical的工具，对于企业来说，信任成本是很高的——即使是在有opensource社区的加持之下。另一方面，从时间点来看，Hashicorp的爆发，抓住的是企业数字化转型和上云的节点。这样的大工程，涉及到一个复杂的、大企业没有经历过的流程。这就需要有很多hand-holding的教育（也许这就是为什么他们的support收入这么高的一部分原因？）。在2019年访谈中，两位founder提到，他们意识到，上云，以及管理云，是大客户的普遍需求。但对于这样一个大工程，你不能光是提供一系列工具，还要向他们展示the way to get there.所以他们总结出了一套Cloud Operation Model, 用自己的四个主打工具，串起来三个企业上云的核心步骤：- 用Terraform来做infra provision, 完成infra-as-code的转化；
- 用Vault实现multi-cloud security, 包括零信任环境下identity管理, token, data的保护等等；
- 用Consul搭建multi-cloud service networking, 包括流量管理、（现在很火的）service mesh等等；
- 最后，用Nomad吧Terraform, Vault, Consul连起来，实现跨云的、各种历史和新的application delivery.
前面提到，这个过程也是Hashicorp后来逐渐想清楚的。在访谈中，Armon说，It's funny: We didn’t build them in the order we see people adopt.Our thinking from the very beginning was you need Consul first. But in practice it turns out you need Terraform to deploy the apps to begin with, and you need Vault to secure them.因为一开始没有从客户的adoption顺序来考虑，在研发和早期的市场推广上，也踩了一些坑。这就是为什么，即使是对于非常底层的产品，我们也希望创始人能从use case的角度，深入思考，客户要更换或者添置一个新的infra产品，会从怎样的场景开始，在进入核心场景之前的路径是怎样的。基于此做早期产品研发上的取舍。另外一个类似的例子，就是M小姐最喜欢的开源项目之一，dbt(https://github.com/dbt-labs/dbt-core).
他们做的事情很好理解，就是在ETL向ELT的转变中，完成data warehouse到下游应用之间的data transformation。在硅谷最火的Modern Data Stack中，dbt几乎是默认的一环。同样是作为一个代表了workflow变迁的工具，dbt甚至提出了一个新的工种:Analytics engineer, 并且为其定义了一整套工作流程。看一下Linkedin（这都能在国内被阉割，伤感！）上的Job posts，真的是越来越多公司在开始招聘这个职位了。说是他们定义了新的data infra工作流程，可以说都不为过。多啰嗦一句。每次说到开源及开发者生态领域的投资，我都会说，我司很理想主义地认为，必须投资于代表国际水准的2.0产品，也就是说，质变，而不是量变。工具类产品比拼的往往不是单纯的性能，而是工具背后的代表新的生产方式的方法论。把best practice抽象成方法论，难度可不比工程上的性能提升要小。一旦让这个方法论成为事实标准，才是真正的护城河。护城河绝不是单纯把产品做成大而全的平台，把一堆60-70分的产品盲目堆砌起来。
开源商业化 - 未来篇：All eyes on the CLOUD!把Cloud/SaaS作为上市时点的重要增长引擎，似乎已经是开源公司的常规操作了。
谁让MongoDB已经把这个曲线走得这么美妙呢！从刚上市时候的几乎可以忽略，到现在MongoDB Atlas收入已经超过了总收入的一半，光是2021Q2就接近$200M!而且推出了这么多年，到2021Q3, Atlas的增速还维持在80%+，简直就是yyds.Hashicorp的套路也是这样，HCP推出一年多的时间，收入占比就从0.5%飙升到5%！HCP推出一年，收入增速超过370%，2021年超过$10M应该没有悬念，让人不得不充满希望！Confluent也是同样的套路。2020年才推出的Confluent Cloud，一直以250%的增速狂飙，到2021Q3,收入就达到了$26.8M，占总收入比重超过25%！原本以为上市是一个公司成熟的标志，看来对于开源公司，IPO是第二春的开始。其实，这也不是开源公司的专利。对于SaaS模式的接受程度提升，已经是整个行业的大趋势。由此我们看到，美国很多enterprise software公司这几年，收入体量增加了，但是增速不但没有下降，反而比IPO时候还要高出了不少（是收入增速，不是收入哦！！）从下图看到，很多开发者相关的公司，都是这个大潮的受益者。我们不能光是看个热闹，从两个角度再深入理解SaaS这个模式。
首先，这些公司能实现不断加速的增速，很重要的一点就是实现了Land & Expand的模式。
回过头来说，Hashicorp的S-1中，把这个模式进一步细化为adopt, land, expand, and extend。其实本质也是PLG里的套路：- 用简单易上手的产品+初始低价降低初始Landing的门槛
- 最后用product portfolio在每个cohort中Extend
这种模式是否成功落地，从cohort analysis中就可以看出来。Hashicorp这个数字非常漂亮，比如2018年的cohort的ARR从一开始的$26M,到2021年翻倍到超过$52M.直接带来的，就是超过120%的NDR，以及不断降低的S&M成本。Confluent也实现了类似模式。而且这个效应在大客户中更是明显。比如，他们好几个ARR百万美金级别的客户，都是从几十万ARR开始，4年时间ARR最高可以提高36倍！
在SaaS land&expand这个模式中，不可缺少的一环就是usage-based pricing。
On-prem或者self-managed infra的Opencore模式中，要实现这一点很不容易。但是这几年公有云和各种SaaS的教育，使得这些开源公司不仅是SaaS模式，在opencore模式中也在逐渐转型为usage-based. Hashicorp在S-1中就说："Over time, we intend to transition our committed contracts to a usage-based model."
看看现在HCP上几个产品的pricing,你也许会发现一个问题，就是这个pricing unit的设计其实很有讲究。对于一个比较新的品类，使用什么Metrics作为pricing unit,其实是需要认真思考的。
在硅谷研究了很多的SaaS pricing中，其中一条原则就是，你设定的pricing unit除了要计算方便之外，必须避免Usage is discouraged when customers feel the marginal cost of consumption。举个例子，一开始Slack按照message数量来收费，结果发现这不是让大家反而不愿意发信息了，这不是影响使用体验么。而且“不发信息”这个行为又太好控制了。后来改成“你能sync的历史信息”，这样不仅不影响使用体验，而且对于使用者，也无法改变“历史事件”，不够用了就只能付费。完美！
最后，开源公司什么时候推出SaaS产品？一个很明显的趋势是：越来越早。
现在上市的开源公司至少都是七八年历史，比如MongoDB, Confluent, Hashicorp, 都是在上市前一两年才开始有SaaS版本。但是有了这么多现成的playbook,现在的开源公司SaaS化步伐越来越快。比如之前提到的dbt，2016年成立的公司，2019年就正式Launch了dbt cloud（请忽略之前那个奇怪的Sinter）。也是典型的per seat收费。还有一家最近关注到的公司，很有意思，本来写好了一篇短文，忍不住提前说说。之前提到的dbt，做的是ELT中的T。有个2020年7月才成立的公司Airbyte（https://github.com/airbytehq/airbyte）, 做的是ELT中的L，就是作为connector, 将各种数据源的数据load到data warehouse里面，同时对这些数据源进行跟踪管理。这个年轻的公司，以“开源的Fivetran”形象出现，刚刚close了B轮融资$150M, 估值已经飙升到$1.5Bn！不到20个月，已经刷刷刷地三轮融了$181M。最新一轮看看这个融资速度，一举打破之前大家对于开源项目需要四五年时间培育的印象…connectors这个竞争激烈、已经相对成熟、技术门槛不高的领域，作为追赶者的Airbyte，今年10月份，产品上线15个月就推出了cloud 版本。
在SaaS模式已经被广泛接受的年代，后来者迅速开发Cloud版本抢占“基层”市场，几乎是个定式，只会到来得越来越快。
开源社区：22万star开源王者的playbook
Win developer's mind and heart!要说Hashicorp是铸造开源产品的王者，恐怕绝大多数人都不会有异议。他们旗下的repo加起来超过220k stars (是的，stars是一个vanity metrics, 但是到了这个程度也是不得不感慨一下啊！）！很多人以为，开源和infra产品，不就是Github一上线，HN、Reddit各种线上宣传一下，回答问题和PR，然后做好技术和performance，社区啊用户啊就应该自己围过来了么？几乎没有哪个成功的开源社区，早期的时候没有在线下做大量后来看起来完全不scalable的事情。就好像Hashicorp co-founder Armon 说的，别人看来都是overnight success, 但是这个Overnight我们花了10年。M小姐扒了Hashicorp两位founder好几个interview, 总结出一些也许不是那么意外，但是值得分享的经验。毕竟，赢得开发者的心智，需要最佳实践的支撑，让各位开源的从业者有信心持续投入到早期也许没有可量化受益的社区之中。首先，Meetup不可少，抓住各种community抱大腿。一开始靠身边的亲朋好友宣传，速度当然很慢。后来，两位创始人很积极到各种Seattle当地的社区meetup、Ruby社区、QCon,DevOpsDay等等，在各种活动上寻找刷脸的机会。后来他们发现Vagrant的使用场景中经常会跟Chef, Puppet这些当时相对成熟一些的开源项目一起出现，于是他们就跟这两个社区的人打好关系，一起打造帮助大家一起提升adoption的场景，相互做evangelists，后面两年，下载量从100狂飙到了10,000！现在，Vagrant每年的下载量超过了200万。Terraform也是一样，第一年不到1,000的下载量，随着参加的活动，从20多人的Meetup到几百人的大会，影响力就逐步上来了。当然，Slack, Twitter这些社交媒体工具都是必须，但是这些线上宣传，都无法取代各种积极的线下交流。经过早期抱大腿的积累之后，Hashicorp就开始全方位建立自己的社区，其中最重要的就是HUG - Hashicorp User Groups. 这个分散在世界各地的自发性组织，如今已经有37k+的会员，遍及53个国家。各种自发的Meetup和活动，不断深化与开发者的关系。其次，Hashicorp对于Conference的投入格外重视。除了参加各种conference, Hashicorp还说服董事会让他们花了很多资源在自己办conference上。早在2015年，什么商业产品都还没有推出。Hashicorp就举办了自己的第一个开发者大会，HashiConf.这次活动来了300多人（虽然看着声势还挺壮大的！）这才是第二次conference, 各大公司，Amazon, Stripe,Docker等等，都来站台。补充一下最近M小姐参加我们各种早期开源公司meetup的感受：
不要担心conference大家不来，小Meetup大conference,都是让公司得以凝聚社区的非常有效的方式。即使一开始只有百来人，一个conference都是非常值得筹备的。第三点，特别重要的是，主动出击，在一线跟早期用户深度交流。用Armon的话来说，Get on the plane!在一次访谈中，Hashicorp的早期投资人说，“（Hashicorp两位founder）各大公司的程序员见面，向他们介绍这个工具。Mitchell每年飞35万公里。在Mitchelle和Armon看来，开源项目的早期创业者除了要对自己的产品有信心之外，还必须全力专注于打造社区。”很多早期社区用户，尤其是前面说到的、对公司早期发展至关重要的Hipster Enterprise，就是这么来的。两位创始人说，当时能找到Twitch,就是因为从Mail list中收到一封邮件，问他们Consul能否在500个节点上使用。Armon马上就问对方是哪个公司的，很快就约了个咖啡，这才知道，人家希望在5,000个节点上部署，这比Consul当时最大的部署规模大了10倍还多。之后的一段时间，两人几乎就跟Twitch泡在一起，直到项目成功上线。难怪Armon多次在访谈中强调说，你要能叫出你的项目前100个用户的名字！有时候，一些开源公司谈起自己，都在说star有多少，社区有多少人，但是却没有积极地抓住任何跟重点用户一对一沟通的机会，去深入了解极致场景对于产品的需求。这种脱离一线的做法，很容易让公司陷入低水平社区的狂欢，在产品研发的优先级上失去主线。在此我又要引用一次PingCAP的co-founder & CEO 刘奇经常说的一句话：真实场景是最好的架构师。但是很多人只看着那些vanity metrics, 舍本求末，忽视了扎根真实场景的机会。但是，回到本质，社区不是最终目的。M小姐认为，终极目标，还是成为行业的事实标准。要实现这一点，产品设计、社区搭建，以及商业伙伴的合作，是不可割裂的整体。还是以Terraform为例。之前提到Terraform算是开源版的AWS CloudFormation, 但是最后怎么形成事实标准的呢？从产品设计上来说：不要憋大招，第一个产品只要能prove idea就可以。2014年刚推出Terraform的时候，只支持AWS和Digital Ocean, 并不是追求production-ready，只是要prove与CloudFormation区别最大的一点：支持多个云厂商。社区共建需要产品支撑：不同的开源产品，需要社区参与的力度是不一样的。比如，前面提到的Airbyte这种中间件产品，相比起跟MongoDB这种比较重的单品，对社区的依赖更重。Terraform作为一种工具，性能固然重要，更需要好的体验以及生态。简单对比了几个比较顶尖的开源项目Star数和Contributor的比例，很有意思的发现是，这个比例惊人的相似，几乎都在0.03！很明显，Terraform这样的工具，以及Airbyte, Spark，dbt这种偏向big data的，比例要稍微高一些。话说回来，Hashicorp一开始就很明确，Terraform生态需要活跃的社区支撑。因此，在不断强化核心workflow能力的同时，他们非常注重产品的易用性、以及开发工具的完备。2016年底，Terraform已经积累了750 contributors, 甚至包括了顶尖的科技公司，比如Azure，Google, Openstack等等。2017年，看到核心能力完备之后，他们推出了Terraform Registry,让大家可以将terraform modules不仅容易开发，而且还可以像模板一样在社区中分享。大大降低了门槛。Terraform的一个标志性事件是，2017年的时候，他们跟Azure达成了第一个公有云战略合作，launch了第一个full-featured Azure provider. 这是公有云厂商第一次公开正式支持Terraform.（不得不说，这一点Azure的确做的比AWS更友好）有了社区、周边工具、公有云正式合作关系的完备之后，2018年初开始，Terraform Enterprise, Cloud等商业化产品才逐渐开始推出。有些开源公司将社群运营看成了一个纯粹marketing的“用户社区”，忽视了开源这个复杂生态中，每个stakeholder的重要性。当然M小姐还是不得不说，要能在商业有起色之前，有如此热血的坚持，真爱是必要条件。看看Mitchell同学的Github，2021年的coding记录是这样一片绿油油。无怪乎人家要辞任CTO，无怪乎Hashicorp能一直创新，2020年还推出了Boundary, Waypoint两个产品。前面说了这么多战术层面的事情，但是靠着KPI，是撑不起这一切的。
把公司打造成产品：Tao of Hashicorp & 开源的公司运营
关于公司的组织，M小姐执意要单独用一个章节来说。放在最后压轴，希望你还有耐心读完。
Hashicorp其实最吸引M小姐的，是两位创始人对于产品设计的一套方法论：早在2013年就发布的，Tao of Hashicorp (这么东方的名字，一看就知道是有日本血统的Mitchell的杰作）。
作为一开始就有多产品的公司，他们把这套理论作为所有产品的Core design ethos，确保各个产品之间的一致性（consistency）。这个一致性不只是UI的问题，就像前面说的，是这一系列工具背后，对于什么是Infra管理的目标，什么是好的infra管理工具的方法论。这一套核心理念，不仅指导了整个公司的vision, 产品roadmap, 产品design, 也让社区的参与者和产品使用者，与产品的创建者能保持一致思路：This is is what you should expect from us.这个Tao里面包括了8个原则，我们选最核心的三点来体会一下：首先，永远被摆在第一位的，Built for workflow, not technologies.Hashicorp不是要为某个具体技术开发强大的工具，而是要针对workflow做一个好的工具，这个workflow可以是deployment, security, 等等，而对于底层具体技术做到agnostic.比如，一开始做安全工具的时候，市面上主要用云上的虚机或者on-prem的裸机。但是随着技术的演进，出现了container, scheduler,等等，但是因为一开始产品设计就是为了兼容多种技术，这使得用户即使自己的tech stack甚至公司战略变化，安全产品还可以保持一致，workflow仍然保持不变。这个原则之所以重要，就是因为它决定了整个产品一开始的架构设计。之后要改变就很难了。这里说的workflow，可不是一个简单的步骤和流程。从Hashicorp发布的Cloud Operation Model可以看到，他们将workflow拆解成三个部分：People, process, tools.设计一个workflow产品/工具的时候，很多人只是看着工具本身的功能，而没有想到，这里面对人的技能的要求是怎样的，对IT流程的假设是self-service还是工单系统，这些随着环境和具体技术的变化，有什么可以抽象出来保持一致的？要深入理解这一点，Hashicorp两位founder的这个短视频，非常非常非常值得一看：How does HashiCorp think about solving problems?第一，作为一个打造了这么多成功产品的公司，他们怎么选择要解决什么问题？他们的出发点就是，我们是否能发现一个核心的、足够普适的workflow的问题可以通过工具解决。要注意的是，这个workflow问题不是人为引入的一些复杂因素。比如Vagrant, 面对的问题就是你加入一个公司的时候，怎样让你迅速上手，搭建环境。其次，开发了这个工具，就要从workflow的角度教育市场，而不是期待技术足够好，大家就会一拥而上。再强调一次，“你要知道你前100个用户的名字”，这个无需赘言。最后，很有意思，设计一个工具，必须要Human-centric，而不是只关注技术。比如，Vault这种复杂的安全产品，你不仅要考虑用的是什么安全的技术，更要思考，谁来用？他们会怎么用？用的过程中会涉及到怎样的workflow?他们会和哪些团队怎么协作?从一两个人的团队到上千人的公司，他们的使用方式会有什么不一样？Core technology的迭代其实不是那么难，但是你要一整个组织去为了一个产品改变workflow，那就非常艰难了。因此，用户及其所在组织使用产品的workflow，是在产品设计之初就要思考清楚的。第二，Codification，就是我们常说的Infra as code.这个背后的核心理念是，Knowledge should be represented as code. 而不是用文档、甚至口头等方式。所以，所有的流程都要用code的形式表达、留存，还有versioned。在他们所有的产品中，要确保有infa-as-code的功能，让你可以do everything as code.有了这个基础，automation as code也就变得很自然了。第三，也是很有东方艺术的，Pragmtism，实用主义。也就是说，前面说了这么多principles,但是遇到实际情况的时候，因地制宜，保持开放心态，一切都是可以变化哒，我们不要做教条主义。Mitchell说，这种看似合理的灰度，其实让很多员工非常抓狂。怎么理解这个灰度呢？两个founder举了两个例子。首先，尊重技术，但是更要重视human element. 就像前面说的Cloud Operation Model.他们发现你不能直接把最终的牛逼哄哄的最佳实践给客户，向客户展现your way to get there，就要接受在这个过程中一些不那么完美的方案。另一个例子是，Immuabiltiy是Hashicorp的原则之一。Immutability是说，任何事情一旦创造出来就fix了，不能被改变。最直接的体现就是，不做任何的upgrade，因为upgrade的过程中有可能出现各种问题，而infra是非常牵一发动全身的系统工程。如果在一个VM上部署了v1，当出现v2的时候，就直接建一个新的server,而不是做upgrade.当然，这个有明显的trade-off, 就是放弃了git rollback等等灵活性，在statefull应用中也需要另外做一些externalize data的设置。不过，这也不是一成不变的。比如Consul, 没有versioning, 也不是immuable changes. 就是因为……现实需要，对于Consul这样的产品，允许变更更Make sense.推荐大家去看看Mitchell 2017年介绍The Tao of Hashicorp的视频。
过了这么多年，虽然有一些updates，但是万变不离其宗。整个思路听下来，M小姐相信，对于正在设计产品的你，一定会非常受用。
最后，跟很多开源公司很像，Hashicorp也遵循transparent operation的理念，将公司的很多管理细则、决策原则等等，都公开在网上。
比如这个How Hashicorp Works的网站，就从individual, manager&team, 以及company三个层面详细阐述了Hashicorp的实践细则。很多我们熟知的开源公司，比如Gitlab, 也是把非常详细的公司handbook都公开在网上。说一个数字，2018年Gitlab发布了第一版handbook,迭代到现在，这个Handbook已经超过2,300页，超过300万字！M小姐注意到的一个共性是，两家公司都非常非常强调writing（以及Over communication）!这让体会过AWS写作至上文化的M小姐，感觉无比亲切啊！比如对于Writing, 他们就有PRD(Problem Requirements Document)以及RFC(Request for Comment)两个模板和具体的写作guideline, 内部的各种问题（不只是产品决策），都通过这种清晰的写作来沟通。我想，这或许跟这些开源公司团队极度分散的运作模式也有关系。Haschicorp有1,650 employees, 分散在20个国家850个城市，在SF HQ的还不到总数的10%！Gitlab更是，1,500多个员工，全部全部全部都是远程办公，分散在66个国家！或许就是因为远程办公+异步协作，逼着公司不得不用文字进行沟通。而这种开放的运作模式，又吸引更多优秀员工加入公司。我们经常说，开源是一种先进的商业模式。在技术人才稀缺且愈发昂贵的今天，开源让员工有自由度的同时又有归属感，让公司能够超越地域的限制，在全世界范围内网罗人才，而不是在一个区域中内卷，只能拼工资。当然，经历过这种remote team工作方式的M小姐表示，要平衡这么多时区这么多文化，挑战真的是很大。不过，这样倒逼出来公司总结出核心理念、价值观和工作方式的总结提炼，或许更能筛选出一流的公司和创始人。
最后的最后，没错，真的要结束了，恭喜你看了这么久！那么继续一个轻松的话题：这么有意思的一家公司，当然不得不提一下这两位（颜值很高的）创始人，Armon Dager, Mitchell Hashimoto,以及跟他们配合了5年的老将Dave McJannet.通常我们觉得，ToB领域的创业需要很深的行业经验。但是我们看到，很多工具类的产品设计，其实更需要的是对开源的理解和产品的思考。像Mitchell, Armon,创立公司的时候都是初出茅庐的九零后，甚至尝试过卖书啊社交啊各种乱七八糟的创业idea。但是，看到他们能在短短几年中不断输出这么多不断深入的产品和技术思考，这种成长性，真是挺叹为观止的！早在2013年的时候，还没有Vault, Terraform这两个拳头产品，两个创始人当时分别是21,23岁，就有公司出价$50M要收购公司。要知道，当时俩人还有80% ownership，但是最后两人决定turn down了！8年后终于迎来IPO，说着轻松，当年拒绝掉几千万美元，需要的真不只是一点点commitment!他行事低调，但是在Hashicorp发展过程中起了至关重要的作用。看看这妥妥的ToB行业老兵的阅历，要知道，人家还是学经济出身，第一份工作在KPMG哦！一方面，这种在技术公司初步打造好产品之后，引入一个职业经理人来做CEO，是硅谷比较惯常的做法。比如MongoDB, Elastic, 都是这样，Snowflake更是CEO从第一天起就不是创始人，而是投资人躬身入局。据说，当时两位创始人想要说服Dave来做CEO，足足聊了18个月！基本是两周到一个月一次的节奏。Hashimoto回忆说，就跟谈恋爱似的。而且Dave不停问他们同样的问题，就是想要确保他们的回答是真实的。这俩哥们为了不做CEO，也是够拼的。这可不，Hashimoto同学在IPO前夕，连CTO都不想做，只想做一个安静coding的IC(individual contributor)。据说，Dave一直非常尊重公司engineering driven的文化，在引入成熟商业化机制的同时，把所有对外的、产品相关的核心决策，都保持对两位创始人的绝对尊重。如此稳定的队伍，真是可遇不可求。
最后的最后，我们再回顾一下Hashicorp过去10年的发展史。这或许不是一本完美的教科书，一开始几年融资也不顺利，中间也走过弯路，也曾经在市场上被撞得鼻青脸肿。但是，在云计算这个时代大背景下，有这么特别的几位创业者，抱着对产品的坚持，集合了全世界几万人的力量，绝对足以在未来IT的发展史中，留下一道值得铭记的痕迹。前面我们说到，在开源及开发者生态领域的投资，我司很理想主义地认为，必须投资于代表国际水准的下一代产品。毕竟赚钱的方式有很多，不论什么方向，创业总是不容易，既然选择了这个hard模式，为什么不放肆一下自己的野心和梦想呢。如果你对这个领域也感兴趣，欢迎在后台跟我聊天，也欢迎发邮件勾搭：monica.xie@matrixpartners.com.cn
既然是今年最后一篇文章，M小姐必须为自家的，有同样理想的团队打个小广告：
Founder 的话：
我们正在寻找1到2名具有良好工程素养的后端工程师，职位限上海或者杭州。
我们是国内最顶尖的工程产品团队，正在努力做一款世界级的开发者工具。有意向的话，可以直接联系我 t@bytebase.com。
除此之外，我们也在招募实习生和应届生，前后端，技术写作都有岗位，仅限上海。
所有岗位我们都能提供市场上最好一档的待遇，具体 JD 可以访问：
https://bytebase.com/jobs
多么难得的一家有理想有技术的startup,同志们，上！
2021年，感谢你们同走过。
戳一下这美丽的二维码，2022年，我们继续前行
点赞转发打赏三连发
我也没意见 :)
****原创不易，转载请注明出处****
往期回顾