醒醒吧，不要再做自嗨式开源了！

最近某上市公司旗下的KubeSphere项目宣布停止对开源版本的支持，瞬间在开源社区里引起了强烈反响。从项目的流行度角度来讲，该项目是很成功的，在Github上有1.6万的Star。这次调整毫无征兆且生硬粗鲁，让社区的用户愤慨不止，纷纷到Github上吐槽抱怨。

过了几天，官方在他们的产品官网出了一个公告，但还是坚持这次的调整。 官方的声明如下：

对官方做出的这种调整，我表示理解，毕竟企业做商业化策略调整，无可厚非。但行事上欠考虑，过于生硬，完全可以采取更温和的措施，帮助众多用户完成过渡，寻求商业化策略调整和社区稳定的平衡点。

今天我不是来批评KubeSphere团队的，更想借这个事件，跟做开源的兄弟姐妹们说句掏心窝子的话：醒醒吧，不要再做自嗨式的开源了。KubeSphere背后是一家上市公司在维护，都会遇到各种挑战，更何况我们这些小团队维护的开源项目呢？

自嗨式开源这个说法会比较直接，可能会让有些朋友觉得不舒服。但确实是我的心里话，希望能够给到做开源的朋友们一些参考建议。

什么是自嗨式开源呢？主要是凭兴趣做一个开源项目，选择最宽松的授权协议，一个star就会让自己高兴半天，一次几块钱的打赏捐助就能让自己满血复活。这样状态的开源，就是自嗨式开源。

兴趣重要吗？重要，但兴趣是否等同于真实的用户场景呢？不一定。但我观察到还是有大量的开源软件作者凭兴趣出发，做了一个开源项目后，坚信一定会有人使用，并坚持不懈地完善软件。

我曾经批评过一位朋友，他要做一个数据库的管理软件。我说数据库管理软件已经有很多开源的项目了，为啥要重新做一个呢？后来就没有再聊过天。看开源软件群里面，他现在不做数据库管理软件了，改做UI框架了。是因为在做数据库管理软件时，他把技术栈从原来的C++换成了C＃，但在用C＃过程中发现没有好用的跨平台的UI，然后又开始做UI框架了。对这位朋友的技术和热情我是非常钦佩的，但做开源项目也不能这样豪横任性吧。：）

所以做开源，兴趣不等同于真实场景，方向的选择上还是要慎重。

再来说协议。很多开源软件的作者认为开源项目一定要用最宽松的协议，这样软件的开放性才是最纯粹的。我猜很多开源软件作者会把采用严格模式的协议当成一件羞耻的事情。做开源，怎么可以用GPL这类的协议呢？但大家看赚钱的开源项目，都是采用严格模式的协议，或者在宽松协议基础上加了很多的附加条件。比如最近比较火的智能体相关的项目，Dify、n8n都是如此。

所以做开源，一定要慎重选择协议。KuberSphere团队之所以停止对开源软件的支持，还不是因为有很多第三方的厂商拿着它去做项目嘛，从授权协议上来讲，你又禁止不了这种行为，这就尴尬了。

再来说说Star。很多开源软件的作者一直盯着Star，觉得这是一个证明自己项目成功的关键标志。Star是说明你的用户比较多，但用户多不一定会带来收益，带来的可能是更多的Issue、Feature，以及更多的要求和支持的需求。这个世界上不缺高Star的开源项目，有很多的高Star的开源项目最后不了了之，创始人甚至因为维护开源项目导致自己穷困潦倒。更有甚者，有的作者会采取一些手段来提高自己的Star，这不过是掩耳盗铃，自欺欺人而已。

所以做开源，Star数量不重要，重要的是有商业诉求的真实用户。

最后来说说捐助？很多开源软件作者开通了打赏通道，还会在项目的显著位置感谢这些打赏者。很多开源软件作者看到有人捐助，就开心鼓舞，又动力满满了。有人打赏是好事情，我们也需要为这些打赏的网友们点个赞。但话说回来，做开源不可能只指望这些打赏啊，还是要靠能跑通的商业模式。

所以做开源，不能靠捐助，一定要跑通商业化这条路。

这就是我想就KuberSphere这件事情跟做开源的兄弟姐们说的话，不要再苦哈哈地做自嗨式创业了。要认真思考自己的产品的方向，围绕用户的真实场景设计自己的商业模式，跑通开源商业化之路，这样才能够更好地支持社区的用户，形成一个正向的循环。

我之前有整理过系列的关于开源商业化的文章，大家可以参考：

• 关于开源软件的七大错误认知（上）
• 关于开源软件的七大错误认知（中）
• 关于开源软件的七大错误认知（下）
• 人间清醒，开源一定要做商业化
• 开源软件商业模式分析