HashCorp Reading Notes

随谈

万字 大文章 https://mp.weixin.qq.com/s/Y2A7-Ui2nzUgodkEbgR6lQ

有很多理念,还是比较认同的:

  1. 技术挑战 放到 开源里面做, 这一点不是很认同, 我认为, 开源解决的是规模小的需求, 或者某个特定的的非常common的问题, 而当规模上来后, 是需要商业化来解决, 或者当需求变得复杂, 需要一系列的措施来解决, 是需要商业化的技术方案来解决.
  2. 个人或者小的团队, 就应该免费使用, 这个逻辑基本成立. 跨团队协作的需求, 商业化机会比较大
  3. 要把价格门槛低的核心产品做的简单易用,同时又要兼顾未来组织内部对产品的复杂需求。 -- 这个很认同
  4. 即使某些功能在开源中有,但是这些功能无法从一个完整的use case level来解决企业面对的问题。 真实操作中, 会将这个放大.
  5. 讨论放到一个具体的use case,而不是某一个功能,这样对于sales也会更好沟通
  6. 开源公司要拿到一些客户订单并不难。但是这里说到市场和销售,核心是repeatable/scalable。
  7. 利用开源形成事实标准,是企业最牢固的隐形护城河。
  8. 开源模式下,sales最大的挑战就是公司自己的开源产品。
  9. 开源模式的S&M (Sales & Marketing)花费应该比传统软件公司要少呀。但是Hashicorp S&M/Rev 比例超过60%,在整个public SaaS公司中,算是比较高的了. 时代在变, 有很多开源运作的成本, 处于技术和品牌交叉的, 这块如果放在marketing, 自然markteing的成本会大幅上升, 而且这个会成为趋势.
  10. 开源天生就是global的生意。-- Hashicorp和Confluent的国际业务发展都很快。两家商业化都是5年左右的时间,都已经有35%的收入来自美国以外。
  11. 渠道玩得溜溜的 -- Hashicorp在开始商业化以后第二年就开始大力发展partners, 三四年的时间,已经建立起来一个170+ ISVs,超过450个integration partner的网络
  12. 面对大客户,只是交给对方工具远远不够。 -- 最先进的enterprise software公司,输出的不仅是工具,更是工具背后的方法论(当然,输出方法论的成本也是不低的)。 -- 于这样一个大工程,你不能光是提供一系列工具,还要向他们展示the way to get there. -- 工具类产品比拼的往往不是单纯的性能,而是工具背后的代表新的生产方式的方法论。把best practice抽象成方法论,难度可不比工程上的性能提升要小。一旦让这个方法论成为事实标准,才是真正的护城河。
  13. 护城河绝不是单纯把产品做成大而全的平台,把一堆60-70分的产品盲目堆砌起来。
  14. Hashicorp的S-1中,把这个模式进一步细化为adopt, land, expand, and extend。其实本质也是PLG里的套路:
  • 用社区/marketing促进Adopt
  • 用简单易上手的产品+初始低价降低初始Landing的门槛
  • 基于Usage实现自然增长Expand
  • 最后用product portfolio在每个cohort中Extend
  1. 在SaaS land&expand这个模式中,不可缺少的一环就是usage-based pricing。-- 看看现在HCP上几个产品的pricing,你也许会发现一个问题,就是这个pricing unit的设计其实很有讲究。-- 你设定的pricing unit除了要计算方便之外,必须避免Usage is discouraged when customers feel the marginal cost of consumption
  2. etl 公司, Airbyte(https://github.com/airbytehq/airbyte), -- 刚刚close了B轮融资$150M, 估值已经飙升到$1.5Bn!不到20个月,已经刷刷刷地三轮融了$181M
  3. 在SaaS模式已经被广泛接受的年代,后来者迅速开发Cloud版本抢占“基层”市场,几乎是个定式,只会到来得越来越快。
  4. Win developer's mind and heart! hashcorp -- 他们旗下的repo加起来超过220k stars
  5. 几乎没有哪个成功的开源社区,早期的时候没有在线下做大量后来看起来完全不scalable的事情。 纯粹误解: Github一上线,HN、Reddit各种线上宣传一下,回答问题和PR,然后做好技术和performance,社区啊用户啊就应该自己围过来了么?
  6. 首先,Meetup不可少,抓住各种community抱大腿。-- 一开始靠身边的亲朋好友宣传,速度当然很慢。后来,两位创始人很积极到各种Seattle当地的社区meetup、Ruby社区、QCon,DevOpsDay等等,在各种活动上寻找刷脸的机会
  7. Hashicorp就开始全方位建立自己的社区,其中最重要的就是HUG - Hashicorp User Groups. 这个分散在世界各地的自发性组织,如今已经有37k+的会员,遍及53个国家。各种自发的Meetup和活动,不断深化与开发者的关系
  8. Hashicorp对于Conference的投入格外重视。
  9. 特别重要的是,主动出击,在一线跟早期用户深度交流。
  10. 你要能叫出你的项目前100个用户的名字!
  11. 社区不是最终目的。M小姐认为,终极目标,还是成为行业的事实标准. -- 要实现这一点,产品设计、社区搭建,以及商业伙伴的合作,是不可割裂的整体。
  12. 从产品设计上来说:不要憋大招,第一个产品只要能prove idea就可以。
  13. 简单对比了几个比较顶尖的开源项目Star数和Contributor的比例,很有意思的发现是,这个比例惊人的相似,几乎都在0.03!
  14. 有些开源公司将社群运营看成了一个纯粹marketing的“用户社区”,忽视了开源这个复杂生态中,每个stakeholder的重要性。-- 要能在商业有起色之前,有如此热血的坚持,真爱是必要条件。
  15. 产品设计的一套方法论, 首先,永远被摆在第一位的,Built for workflow, not technologies. -- 他们将workflow拆解成三个部分:People, process, tools. -- 设计一个workflow产品/工具的时候,很多人只是看着工具本身的功能,而没有想到,这里面对人的技能的要求是怎样的,对IT流程的假设是self-service还是工单系统,这些随着环境和具体技术的变化,有什么可以抽象出来保持一致的?
  16. 尊重技术,但是更要重视human element. 就像前面说的Cloud Operation Model.他们发现你不能直接把最终的牛逼哄哄的最佳实践给客户,向客户展现your way to get there,就要接受在这个过程中一些不那么完美的方案。
  17. 跟很多开源公司很像,Hashicorp也遵循transparent operation的理念,将公司的很多管理细则、决策原则等等,都公开在网上. 这个挺难的, 刚开始还比较容易, 当商业化逐渐深入, 很多事情反而扑朔迷离.
  18. 两家公司都非常非常强调writing以及Over communication! 这个不错.