大家好，我是 sealos 的作者，很高兴和大家分享我做开源以及运营一个开源项目总结的一些经验。

选择一个大市场

这点非常重要，你可以选择一个大的市场，或者一个高速发展的市场，谁都知道做算法教程的一定比一个编译器底层低频工具受众会广，如果从获取更多 star 的角度来看，选一个普遍需求就非常重要，比如 sealos 选择从安装 kubernetes 开始做起，因为几乎每个实践云原生的人几乎都需要一个安装工具，这是个非常好的切入口。

如果你现在还选择去在 openstack 生态做工具，那显然不符合时代大趋势，很难把项目做成功，因为它不符合大势的发展，存量市场也没有多大。sealos 选择 kubernetes 生态既符合当前市场足够大，也符合整个市场高速增长，所以可以搭上这趟车。

所以对技术发展的洞察力非常重要，不然可能你即使好不容易打造成功的项目也会在两年后停滞增长。

切中用户的痛点刚需

痛点是如何被发现的？首先说说 sealos ，痛点来自于我自己本身的工作，三年前我发现安装 kubernetes 实在过于痛苦，官方文档都没有提供高可用的教程，我就自己写了脚本，心想很多人应该都会用到这个工具，就开源了，直到迭代到现在 golang 版本。

所以当你工作中遇到问题时，或者抱怨别人的工具难用时，恭喜你，你发现了痛点！甚至有时候你用 google 搜索了很多都找不到解决方案，或者更好用的替代方案时，此事巨大机会就摆在你的眼前了。

不要去重复造轮子，甚至重复造别人已经造的很好的轮子，去重复制造除非你有非常大的优势，否则你更应该看一看市场上有没有马车，去补空缺，或者让在现有东西上去优化让他更好。

组合创新也很重要，用户需要的是马车，现在有马有轮子，这个时候最重要的就是组装一台马车出来给用户。

多于用户沟通采集用户的需求也很重要，但是采集需求不是说要按照用户说的做，很多人听说过福特汽车的故事，大概说福特如果采集用户需求，用户只会想要一台更快的马车，永远也不会提汽车的需求。 这里很显然是错误的理解了需求，用户真正的需求是”更快的车“，而不是”更快的马车“，马车汽车是解决方案，应该是由我们对科技的洞察提供的，甚至你可以把用户的需求更高的抽象成”用户想要移动的更快“，这样理解需求你就可以造时空穿梭机！ 这就是对需求的提炼与抽象能力。

好的作品是一切的核心

好的作品刚开始的时候评判标准来自我们自身，通常会有一个非常好的 idea 让你睡不着，想第二天就把它做出来，如此开始每天工作到半夜，发布之时你有满满的成就感，觉得她真的美爆了，简直是伟大的创造。

然后你找三五个体验用户，然后被泼冷水，发现用户要要的并不是你做的东西，还有非常多需要优化的部分，sealos 在某个时期就是这样，安装需要三次执行命令，早期用户反馈并没有让我感到兴奋，甚至有些打击我。

此时我下定决心打算进一步优化，把 70 分做到 90 分，最终我做到了，把所有东西做到一条命令中，为次引入了非常多的新技术，最终受到了试用者的好评。

打造早期种子用户

这时适合比较小规模的宣传，sealos 开始就获取了不少的用户，但是那时产品并不成熟，导致我每天需要处理大量用户的问题，我甚至都没有时间对产品进行迭代。

我发现长期这样下去不行，我把所有客户的常见问题列成一个长长的表单，然后每天花很多时间从技术层面一个一个解决，一些非常细节非常小的问题，但凡用户可能会问到的都通过技术的手段屏蔽掉，这段时间让产品成熟度上了一个非常大的台阶。

所以早期我觉得可以服务 10 个以下的用户，非常专心的专注于他们的反馈，去优化产品，一但 8 个以上都满意度很高了，那么恭喜，可以开始着力与宣传了。

早期宣传

sealos 的早期宣传几乎就是靠博客，我们也尝试过其它途径，如 google 广告，meetup 等，最终还是发现博客的性价比最高，以及一些技术文章，常见问题解答帖子等。

口碑传播期

知道一年多以后 sealos 实现了自然增长，其中有很大一部分是用户之间的相互推荐使用，能做到这一点取决于产品的质量。我还是会经常的挑一些客户聊天，咨询他们是否愿意把我们介绍给别的同事，有很大一部分开发者是愿意甚至已经这样做了。

利用媒体爆发式增长

我们在一些质量比较好的媒体上发表了文章，形成了一段时间的垂直上涨，其实这是连锁反应，那段时间上了 github 趋势榜导致了二次传播，甚至后面我们一直霸榜一周直到假期到来。

趣味性的病毒传播

遇到很多趣味性的内容有时能触发用户的分享兴趣，比如 sealos 的一个推广用语：”由于 sealos 可以把一周的工作量缩短到三分钟，可能会导致您工作不饱满而被老板炒鱿鱼“ 引起了不少人的兴趣并在群里面转发。