40 个 Star 的开源 ITSM 项目，为什么还值得继续做？

云与数字化 | 开源产品建设、AI Native ITSM、企业流程治理

40 个 Star 不是成功，也远远不是一个企业级开源项目的终点。

但对一个刚开始公开建设的开源 ITSM 项目来说，它是一个很小、很真实、也值得认真对待的信号。

前段时间我写过一篇《我为什么要做一个开源 ITSM 项目》。那篇文章的阅读数据比我预期好很多，也让这个项目被更多人看到。后来我又写了《中国企业为什么需要一个开源版 ServiceNow》《CMDB 为什么难做？因为它不是一张资产表》《插件市场：开源 ITSM 如何避免每个客户都改核心代码？》这些文章。

今天再看 GitHub，这个项目已经有 40 个 Star。这个数字放在开源世界里当然很小，不能证明项目已经成功，也不能证明市场已经验证。但是我越来越确定一件事：这个方向值得继续做，而且要比最开始想象得更认真。

因为 Star 背后真正有价值的，不是数字本身，而是它说明有一小群人开始关注一个问题：企业内部流程、IT 服务、资产、权限、审计、连接器和 AI 执行，能不能用一种更开放、更可控、更适合国内环境的方式重新做一遍。

01

40 个 Star 说明不了成功，但能说明方向有人关心

做开源项目最容易陷入两种错觉。一种是过度乐观：觉得只要发到 GitHub，很快就会有人使用、提 Issue、贡献代码、帮忙传播。另一种是过度悲观：看到 Star 很少，就觉得没人需要，方向可能错了。

现实通常在中间。企业级开源软件不是工具类小项目，不会因为一个酷功能就快速爆发。它面对的是企业内部真实流程，涉及部署、权限、数据、合规、安全、集成和长期运维。一个人点 Star，往往也不意味着马上会部署使用；但一个人愿意点 Star，至少说明这个问题在他的认知里留下了位置。

所以我不想把 40 个 Star 写成一篇庆祝稿。它不值得庆祝得太早，但值得复盘。它让我看到，国内确实有人在寻找一个开源 ITSM、开源 ServiceNow、AI Native 流程平台、企业连接器市场之间的交集。

早期 Star 的价值，不在于证明市场已经成立，而在于提醒你：这个问题不是只有你一个人在想。

对开源项目来说，这已经是一个值得继续投入的起点。

02

为什么我没有把它做成一个普通工单系统

如果只是做一个工单系统，这个项目其实没有太大意义。市面上已经有很多工单工具、客服系统、低代码流程平台、协同办公里的审批流。企业并不缺一个“能提交表单、能分派处理人、能关闭工单”的页面。

企业真正缺的是一个能够承载复杂流程治理的底座。工单只是入口，后面连接的是事件、问题、变更、发布、服务请求、服务目录、SLA、知识库、CMDB、权限、审计、组织结构和外部系统。只做工单，很快会遇到天花板；做流程治理，才有可能真正进入企业数字化深水区。

这也是为什么项目从一开始就不是“表单 + 列表 + 状态流转”的思路，而是希望覆盖 ITIL 核心流程，内置 BPMN 工作流引擎，支持私有化部署、多租户、RBAC、SLA、知识库、CMDB、AI 审计和连接器扩展。

这些能力不会在一开始就全部成熟。当前项目已经具备工单、事件、问题、变更、发布、服务请求、服务目录、SLA、知识库、工作流、RBAC、多租户、Docker Compose 部署等基础能力；CMDB、连接器市场、Skill 市场、插件市场和 AI 自动化能力，还需要持续打磨。

我愿意把这个边界说清楚，因为企业级开源软件最需要的是信任。把路线图说得过满很容易，真正难的是承认哪些已经可用，哪些只是雏形，哪些还在路上。

03

40 Star 还不能证明产品已经被市场验证，但可以说明这个问题开始有人关注

开源项目很容易把 Star 当成增长指标，但 Star 和真正的市场验证之间还有很长距离。一个企业级开源项目，只有被人真实部署、真实使用、真实反馈、真实依赖，甚至愿意围绕项目投入时间或预算，才算开始接近市场验证。40 Star 还远远到不了这个程度。

但它能提供一种更早期的信号：这个题目是否有人愿意停下来多看一眼。对企业级开源项目来说，这个信号已经有意义，因为它的目标用户并不是泛开发者，而是企业 IT、运维、数字化、平台工程、架构师和开源二次开发团队。

这些人不会轻易被一个新仓库打动。他们会问很多现实问题：这个系统能不能本地部署？权限隔离是否可靠？数据模型是否清晰？流程能不能自定义？出了问题能不能排查？是否容易和已有系统集成？未来会不会变成又一个没人维护的半成品？

所以对我来说，40 Star 不是产品验证，而是问题验证。它说明“开源 ITSM + AI Native + 本土企业流程治理”这个问题组合，开始被一小部分人识别出来。接下来要验证的不是还有多少人点 Star，而是有没有人愿意跑起来、提 Issue、讨论需求、参与贡献，甚至把它放到真实企业环境里试一试。

Star 是注意力，Issue 是问题，部署是信任，贡献是共建。

一个开源项目真正往前走，要从注意力逐步走向信任和共建。

04

为什么中国企业需要一个更开放的 ITSM 底座

我一直认为，ServiceNow 最值得学习的地方，不只是 ITSM 本身，而是它把流程、数据、权限、连接器、插件和业务应用逐步组织成了一个企业服务平台。这也是它强大的地方。

但国内企业面对的环境和海外并不完全一样。很多企业有本地化部署要求，有多云和混合云环境，有飞书、企业微信、钉钉、OA、ERP、CRM、财务系统、监控系统、堡垒机、CMDB、数据中台等大量内部系统。真正落地时，难点往往不是买一个系统，而是让系统和企业现有流程真正接起来。

这就需要一个开放的底座。它不能只卖一个封闭产品，也不能让每个客户都改核心代码。它需要有清晰的数据模型、稳定的权限边界、可审计的流程执行、可安装的连接器、可扩展的插件机制，以及面向 AI 的工具调用接口。

这也是我最近反复写连接器、插件市场、Spoke 机制、Manifest、Skill 的原因。它们不是脱离 ITSM 的概念，而是企业级软件从“单体功能”走向“平台生态”的关键。

一个开源 ITSM 项目的长期价值，不是替代某个工单页面，而是让企业可以在自己的环境里构建流程、资产、权限、审计和连接器生态。

这比做一个轻量工具更慢，但也更值得。

05

AI Native 不是给工单系统加一个聊天框

现在很多企业系统都在加 AI，但我不认为“旁边放一个聊天框”就是 AI Native。真正的 AI Native ITSM，不能只回答问题，而要能理解工单上下文、识别流程状态、调用知识库、生成摘要、提出分诊建议、记录置信度、保留审计轨迹，并在必要时降级到人工判断。

企业环境里的 AI 最大问题不是能不能生成文字，而是能不能被约束、被测试、被审计、被追责。一个 AI 建议把工单分给谁，依据是什么？置信度是多少？有没有人采纳？采纳后效果如何？这些信息如果没有记录，AI 就很难进入生产流程。

因此项目里会把 AI 审计、LLM Gateway、RAG 知识库、智能分诊、摘要、工具调用框架放在架构层面考虑，而不是把 AI 当作一个前端装饰。当前这些能力仍然处于基础建设阶段，远没有到可以夸口“自动化替代人工”的程度。

但方向很清楚：AI 不是为了让工单系统看起来更先进，而是为了让企业流程在可控、可审计的前提下，逐步具备更强的执行辅助能力。

06

40 Star 之后，真正要补的是产品化能力

开源项目最难的地方，不是写出第一版代码，而是把代码变成别人愿意试用、愿意部署、愿意反馈、愿意贡献的产品。这一步非常琐碎，也非常关键。

对这个 ITSM 项目来说，接下来最重要的不是继续堆功能，而是补产品化能力。比如：部署流程能不能更稳；默认配置能不能更合理；文档能不能让一个陌生开发者顺利跑起来；测试能不能覆盖关键路径；权限和租户隔离能不能经得起回归；连接器生命周期能不能形成明确契约。

项目路线图里已经把这些问题拆出来了：v1.0 GA 优先保证 ITIL 核心闭环、AI Native 基础脚手架、私有化部署；v1.1 会继续补测试覆盖、拆分过大的控制器、推进连接器市场 v1、强化 RBAC；后续再推进 AI Evaluator、Skill Registry、飞书/钉钉/企业微信原生连接器和插件市场。

这些工作看起来没有那么“性感”，但企业级软件最后拼的往往就是这些：稳定性、可维护性、可部署性、可审计性、可扩展性。没有这些，功能越多，风险越大。

40 Star 之后，我更关心的不是下一个 Star，而是下一个真实可用场景。

开源项目只有进入真实场景，才会暴露真正的问题，也才会长出真正的产品能力。

07

接下来我不会做什么

继续做，并不意味着什么都做。企业级软件最容易被需求拖散，尤其是开源项目，早期每一个反馈都很珍贵，但不是每一个反馈都应该立刻变成核心功能。

第一，我不会为了短期演示效果，把 AI 写成不可控的自动执行。企业 ITSM 里的每一次变更、审批、分派、升级，都可能影响真实业务。AI 可以建议，可以总结，可以检索知识，可以辅助判断，但高风险动作必须有权限、审计和人工确认。

第二，我不会为了满足单个客户场景，把核心代码改成一堆不可维护的分支。企业需求一定有差异，所以更应该把差异放到连接器、插件、流程模板和 Skill 里，而不是把核心系统改得越来越重。

第三，我不会把所有文章都写成项目宣传。真正有价值的内容应该能解释问题，而不只是介绍功能。读者不关心一个项目今天多了几个按钮，读者关心的是企业流程为什么难、CMDB 为什么容易失败、AI 为什么调不动系统、插件市场为什么能减少定制代码。

第四，我不会把 Star 当成唯一目标。Star 很重要，它能带来关注；但更重要的是 Issue、PR、部署反馈、真实用户问题和可复用的场景沉淀。开源项目最终要靠长期信任活下来，而不是靠一次推荐流量。

08

内容也在帮助项目做市场验证

最近公众号数据给了我一个提醒：表现较好的文章，不一定是最“技术正确”的文章，而是最能让读者理解“为什么要做”的文章。《我为什么要做一个开源 ITSM 项目》《企业为什么需要一个开源版 ServiceNow》之所以阅读更高，是因为它们不是在讲功能，而是在讲问题。

这对开源项目很重要。开源不仅是代码公开，也是一种持续解释问题的能力。你要解释为什么企业流程很难，为什么 CMDB 不只是一张资产表，为什么连接器不是接口代理，为什么插件市场可以减少客户改核心代码，为什么 AI Native 不是聊天框。

内容本身也会反过来影响产品。文章阅读、分享、收藏、评论、Star、Issue，都在告诉你哪些问题被读者理解了，哪些表达还太抽象，哪些方向可能存在真实需求。开发过程、排查思路、产品取舍、架构演进，都会成为内容素材；而内容又会帮助项目获得更早期的信任。

这就是我现在越来越认同的一句话：内容即产品，产品即内容。不是把内容当营销包装，而是把内容当作产品建设的一部分。

09

为什么还值得继续做

因为企业数字化的深水区，最终一定会回到流程问题。企业可以买很多 SaaS，上很多系统，引入很多 AI 模型，但如果流程不清楚、权限不清楚、资产不清楚、责任不清楚、审计不清楚，AI 也很难真正执行动作。

因为国内企业需要更适合本土环境的企业级开源软件。飞书、企业微信、钉钉、国产云、多云、私有化、等保、审计、内部账号体系，这些都不是海外产品简单本地化就能完整解决的问题。

因为开源 ITSM 可以成为一个很好的基础设施入口。它天然连接工单、流程、CMDB、知识库、服务目录、权限、连接器、AI 工具调用和企业内部系统。它不是最大的入口，但它足够具体，足够贴近企业日常运转。

也因为 40 个 Star 虽然不多，但它让我看到这个方向不是一个人的自嗨。有人愿意看，有人愿意收藏，有人愿意关注项目进展，这就足够支撑我继续往前走一段。

结语

40 个 Star 不是成功，但它是一个可以继续认真建设的理由。

接下来这个项目不会靠夸张叙事往前走，而会继续把基础能力做扎实：核心流程、CMDB、工作流、连接器、插件、AI 审计、部署、测试和文档。

企业级开源软件没有捷径。真正值得做的东西，往往一开始都很慢。但只要方向真实，问题真实，用户真实，慢一点也可以继续。