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

15. 在SaaS land&expand这个模式中，不可缺少的一环就是usage-based pricing。– 看看现在HCP上几个产品的pricing,你也许会发现一个问题，就是这个pricing unit的设计其实很有讲究。– 你设定的pricing unit除了要计算方便之外，必须避免Usage is discouraged when customers feel the marginal cost of consumption
16. etl 公司, Airbyte（https://github.com/airbytehq/airbyte）, – 刚刚close了B轮融资$150M, 估值已经飙升到$1.5Bn！不到20个月，已经刷刷刷地三轮融了$181M
17. 在SaaS模式已经被广泛接受的年代，后来者迅速开发Cloud版本抢占“基层”市场，几乎是个定式，只会到来得越来越快。
18. Win developer’s mind and heart! hashcorp – 他们旗下的repo加起来超过220k stars
19. 几乎没有哪个成功的开源社区，早期的时候没有在线下做大量后来看起来完全不scalable的事情。 纯粹误解: Github一上线，HN、Reddit各种线上宣传一下，回答问题和PR，然后做好技术和performance，社区啊用户啊就应该自己围过来了么？
20. 首先，Meetup不可少，抓住各种community抱大腿。– 一开始靠身边的亲朋好友宣传，速度当然很慢。后来，两位创始人很积极到各种Seattle当地的社区meetup、Ruby社区、QCon,DevOpsDay等等，在各种活动上寻找刷脸的机会
21. Hashicorp就开始全方位建立自己的社区，其中最重要的就是HUG - Hashicorp User Groups. 这个分散在世界各地的自发性组织，如今已经有37k+的会员，遍及53个国家。各种自发的Meetup和活动，不断深化与开发者的关系
22. Hashicorp对于Conference的投入格外重视。
23. 特别重要的是，主动出击，在一线跟早期用户深度交流。
24. 你要能叫出你的项目前100个用户的名字！
25. 社区不是最终目的。M小姐认为，终极目标，还是成为行业的事实标准. – 要实现这一点，产品设计、社区搭建，以及商业伙伴的合作，是不可割裂的整体。
26. 从产品设计上来说：不要憋大招，第一个产品只要能prove idea就可以。
27. 简单对比了几个比较顶尖的开源项目Star数和Contributor的比例，很有意思的发现是，这个比例惊人的相似，几乎都在0.03！
28. 有些开源公司将社群运营看成了一个纯粹marketing的“用户社区”，忽视了开源这个复杂生态中，每个stakeholder的重要性。– 要能在商业有起色之前，有如此热血的坚持，真爱是必要条件。
29. 产品设计的一套方法论, 首先，永远被摆在第一位的，Built for workflow, not technologies. – 他们将workflow拆解成三个部分：People, process, tools. – 设计一个workflow产品/工具的时候，很多人只是看着工具本身的功能，而没有想到，这里面对人的技能的要求是怎样的，对IT流程的假设是self-service还是工单系统，这些随着环境和具体技术的变化，有什么可以抽象出来保持一致的？
30. 尊重技术，但是更要重视human element. 就像前面说的Cloud Operation Model.他们发现你不能直接把最终的牛逼哄哄的最佳实践给客户，向客户展现your way to get there，就要接受在这个过程中一些不那么完美的方案。
31. 跟很多开源公司很像，Hashicorp也遵循transparent operation的理念，将公司的很多管理细则、决策原则等等，都公开在网上. 这个挺难的, 刚开始还比较容易, 当商业化逐渐深入, 很多事情反而扑朔迷离.
32. 两家公司都非常非常强调writing以及Over communication! 这个不错.