夜莺开源监控突破一万 star，当我们离开的时候希望世人还记得我们

夜莺监控项目在上周突破了一万 star，算是一个小小的里程碑。在开源领域，通常把 star 数量看作项目的繁荣指标，star 数量越多，说明愿意关注你的人越多。这个数字的背后，是一群人对你的鼓励、认可和支持，当然，还有鞭策。

夜莺项目最早发起于 2020 年初，发展到现在接近四年时间。本文想借这个节点聊清楚三件事：我们为什么做开源，开源监控项目为什么难，以及怎样设计一个既能服务社区、又能让团队持续投入的商业模式。

核心要点

• 夜莺突破一万 GitHub star，是社区关注度和项目持续投入的阶段性结果，不是终点。
• 开源项目真正难的不是第一次发布，而是长期维护、响应用户、持续发版和保持产品方向。
• 纯技术 Support 很难支撑监控、可观测性项目的大规模商业化，因为开源越好，用户越不需要基础支持。
• 更可持续的模式是社区版保持功能闭环，商业版解决更复杂的企业级可观测性问题，两者定位不同但互相促进。
• 对夜莺团队而言，活下去是责任，留下一个长期有用的开源项目才是更关键的价值。

项目简介

夜莺项目最初是我们在滴滴的时候开源的，后来捐赠给中国计算机学会开源发展委员会进行托管，以基金会的方式运作。其 github 地址是 https://github.com/ccfos/nightingale，其中 ccfos 就是 CCF OpenSource，即中国计算机学会开源项目的统一地址。

项目至今，有 130 位 contributor 参与，共提交了 2600 多次 commit，发版了 170 多次，fork 数 1400，docker pull 228k，虽说我们还有很多不足，但这些数字让我们看到了持续进步的汗水。

如果一个开源项目可以坚持投入 4 年，甚至 10 年、20 年，我们坚信它的社会价值会越来越大。

项目发起初心

如果聊到项目开源的初心，那得追溯到 10 年前我们开源 open-falcon 那会了，当时确实啥都不懂，就是凭一腔热血为爱发电，当时觉得吧，我们搞了一个自认为还不错的项目，独乐乐不如众乐乐，放出来大家一起完善，项目会越发牛逼。当时的我们，也没有想过什么商业模式，只是想把这个项目做好，让更多人用，让更多人参与。

实际遇到了如下一些问题，如果你也做过开源项目，估计会很有同感：

• 维护者的心理压力大
  • 经常碰到不看文档的小白用户，问各种基础问题。就像一个二年级的小学生经常被问 1+1 等于多少，时间久了，会很厌倦
  • 偶尔会碰到颐指气使的人，用了你的项目，觉得你欠他的的一样，但凡遇到问题，不管是不是自己的问题就恶语相向

• 维护者时间精力有限
  • 大部分开源项目都是维护者兼职在搞，时间精力有限，毕竟养家糊口才是第一位的，搞开源是上层精神层面的追求了
  • 这会导致有些问题处理不够及时，显然，这会导致用户不满。周末照顾家人时收到陌生人提问那也是家常便饭，我不开心，用户也不开心
  • 当维护者调岗跳槽之后，基本就不会继续参与了，这对项目而言是致命的
• 项目功能发展设计其实还是靠你自己
  • 会有水平很高且愿意和你探讨项目设计发展的人，但确实数量不多，毕竟大部分开源项目影响力有限
  • 也会有参与者，通常是小修小改，偶尔还会碰到巨型 PR，是要改你的命名规范，因为他觉得现有的命名规范不符合他的审美

后来发起夜莺项目，我们就在思考如下这个关键问题：

如何才能让一些人才持续全情投入？只要有人持续投入，项目一定会越来越好，不管是功能层面、性能层面，还是文档、社区支持，只要有人持续参与，一切都会越来越好。但是人家得养家糊口啊，除非给人发工资。工资从哪里来？靠项目自身去赚不就行了。于是，，，我们创业了，做了一家公司叫快猫星云。

但是，事情远没有这么简单。

这也是开源监控项目最现实的问题：用户希望软件免费、稳定、问题有人答；维护者希望项目有价值、社区有反馈、团队能持续投入。两边都合理，但如果没有可持续的资源来源，项目很容易在热情消退后停止演进。

开源和商业的天然悖论

我们想到的第一个模式是靠技术 Support，因为 RedHat 就是这么干的。普通用户提供社区支持，商业用户提供商业支持，如果客户在生产环境部署了你的软件，为了防止紧急生产故障，买个 Support 以防万一，这理所当然，看起来是个好模式。但也仅仅是看起来，实操中会发现如下问题：

• 监控、可观测性系统，我们觉得是 P0 级服务，但是很多客户觉得不影响核心系统所以没关系，重视程度不高，如果是核心 DB 或 OS，那就不一样了
• 开源做的越好，比如功能越稳定、丰富，文档越完备，用户遇到的问题越少，越不需要 Support，如果开源做的不好，用户量起不来，也不会有商业用户
• 边界不好界定。如果只是夜莺软件本身出问题我们来提供支持理所当然，那客户问这个 promql 怎么写？达梦数据库怎么监控？这些问题就很难界定了

所以，技术 Support 根本没有大规模商业化的底层逻辑支撑。如果你只是个人项目，养活自己就行，或者只是想赚点外快，这个模式或许还行，如果只是想养活几个人，这个模式我都觉得很难。

另外，开源监控、可观测性项目，可选择的项目还比较多，你如果收费，别家免费，即便你做的更好，也很难有人买单。你有养家糊口的压力，但是其他有些项目的研发人员人家已经财务自由了，人家就是可以全职不拿钱做开源，你怎么办？

所以我们后来逐渐认识到，开源和商业不能只靠“免费软件 + 收支持费”来连接。这个模式在某些基础软件领域成立，但在监控、可观测性领域并不天然成立。原因很简单：用户真正愿意付费的，往往不是“有人帮我回答基础问题”，而是“帮我解决更复杂、更高价值、更贴近组织运行的问题”。

多方共赢的商业模式设计

其他领域不敢讲，监控、可观测性这个领域，如何设计一个多方共赢的商业模式？我的个人观点（注意，只是个人观点）如下：

• 开源的部分，需要是功能闭环的，即，不依赖商业功能也能用的起来。而且这部分功能要足够好，让用户觉得用的很爽，这样才能吸引用户。这部分承接了我们的精神层面的诉求以及商业营销层面的诉求。这部分功能，我们可以把它叫做社区版。我们要在社区版这块投入全职人力，给他们发工资做开源。
• 没有预算的开源用户，可以免费使用社区版，有社区提供的技术支持，虽然响应速度没有商业版快，总还会有人响应，比那些动不动就撂挑子的开源项目会强很多。
• 有预算的用户，可以购买商业版，商业版的功能要比社区版更强大，技术支持也更及时。比如开源版会重点做告警引擎功能，而商业版会做大一统的可观测性平台。其定位不能相同，定位相同了就没法取舍，比如一个功能是放社区版还是商业版，就很难界定了。

其他一些 ToB 商业公司同行可能会觉得我们这种做法就是毒瘤。因为我们开源的部分抢了他们的生意，但实际上，我们开源的是基础监控告警能力，即便没有我们，还是会有 Prometheus，会有 Zabbix 这些前辈在，如果 ToB 公司的生意能够被开源项目抢走，说明你的产品能力可能还需要加强。而社区版也承载了我们的精神层面的诉求，我们希望为社会提供一个好用的监控系统，让更多人受益，这是初心，我们不可能放弃。

把这个逻辑拆开看，夜莺社区版和商业版的关系不是简单的“少功能”和“多功能”，而是服务不同层次的问题。

活下去是责任，留下点什么才是关键价值

有些创业导师说，如果你只是为了钱，那不应该创业。实际上，创业的原因哪能是单一的。肯定是既要又要还要啊。

• 既要赚到钱，养家糊口，发得起工资，这是责任
• 又要部分员工可以全职做开源，满足一下精神层面的需求
• 还要让飞轮转起来，越做越好越做越大，让各方受益

如果，我是说如果，我们站在生命的尽头，回首往事，什么会相对更有价值？我想，可能是过程中一起经历的风雨，以及我们生命留下的痕迹，我们在开源项目上的付出，可能会是我这碌碌无为的一生中最深的那个痕迹了吧。

常见问题

Q1：一万 star 对夜莺意味着什么？ A：它意味着更多人关注、试用和认可夜莺，也意味着项目要承担更高的维护责任。star 不是最终目标，但它是社区反馈的一种信号。

Q2：为什么不能只靠技术 Support 养活开源监控项目？ A：监控系统如果足够稳定、文档足够好，用户对基础 Support 的依赖反而会下降；如果项目不好用，又难以形成足够大的商业用户基础。这让单纯 Support 模式很难规模化。

Q3：社区版和商业版应该是什么关系？ A：社区版要功能闭环、真正可用；商业版要解决更复杂的企业级问题。两者定位不同，才能既服务开源用户，又支撑团队长期投入。

小结

夜莺突破一万 star，是一个值得记录的节点。更重要的是，这个节点背后有一个长期问题：开源项目如何持续投入。我们的答案不是放弃商业，也不是削弱社区，而是让社区版承担公共价值，让商业版承担复杂场景和持续投入的资金来源。只有这样，开源监控项目才有机会走过 4 年、10 年，甚至更久。