第二章：评价框架：成熟度模型的历史（CMM/CMMI）、软件生态成熟度评价的维度划分
好，咱们进入正题。
上一章聊了聊为什么要做生态成熟度评价。这一章，咱们得把评价的“尺子”本身搞清楚。说白了，就是先看看前人是怎么量尺寸的，再琢磨咱们自己的尺子该怎么画刻度。
2.1 成熟度模型的前世今生：从CMM到CMMI
说到成熟度模型，绕不开CMM。我当年刚入行时，公司要过CMMI三级，那阵仗，简直了。全公司上下都在补文档，连我写个注释都要被拉去评审。现在回想起来，虽然过程痛苦，但确实帮团队建立了一套规范。
CMM（能力成熟度模型），最早是卡内基·梅隆大学软件工程研究所搞出来的。初衷很简单：帮美国国防部评估软件承包商的能力。它把软件开发过程分成了五个等级：
- 初始级（Level 1）：过程混乱，成功靠个人英雄主义。说白了，就是“看天吃饭”。
- 可重复级（Level 2）：有了基本项目管理，能重复之前的成功经验。嗯，至少知道上次是怎么成功的了。
- 已定义级（Level 3）：过程标准化，文档化。全公司用同一套“菜谱”做菜。
- 已管理级（Level 4）：量化管理，用数据说话。不再是“我觉得”，而是“数据说”。
- 优化级（Level 5）：持续改进，主动优化。这境界，有点像武侠里的“无招胜有招”。
后来，CMM演变成了CMMI（能力成熟度模型集成）。为什么？因为大家发现，光管软件开发不够，还得管系统集成、硬件开发、采购等等。CMMI把这些都揉到了一起。我个人觉得，CMMI最大的贡献是引入了“连续式表示法”，允许你只改进某些特定过程域，不用非得整个公司一起升天。
核心要点：CMM/CMMI的核心思想是“过程决定质量”。它假设只要过程成熟，产品自然成熟。这个假设，在软件生态评价里，需要打个问号。
为什么会这样？你想想看，一个生态里，光有好的“过程”是不够的。比如，你代码写得再规范，如果社区里没人用你的库，生态也是死的。所以，咱们得跳出CMMI的框架，重新定义生态的维度。
2.2 软件生态成熟度评价的维度划分
好，现在咱们来聊聊我自己的框架。我这些年做生态评估，踩过不少坑。比如，有一次评估一个开源项目，只看代码质量和社区活跃度，结果忽略了它的商业模式，最后项目因为没钱维护，黄了。从那以后，我意识到，生态评价必须是多维度的。
我把软件生态成熟度评价分成四个核心维度：
| 维度 | 核心问题 | 关键指标举例 |
|---|---|---|
| 技术维度 | 代码本身是否健康？ | 代码质量、架构设计、文档完备性、API稳定性 |
| 社区维度 | 人是否在参与？ | 贡献者数量、Issue响应时间、PR合并率、邮件列表活跃度 |
| 治理维度 | 规则是否清晰？ | 决策机制、角色定义、冲突解决流程、版本发布策略 |
| 商业维度 | 能否持续？ | 资金支持、商业模式、市场占有率、用户付费意愿 |
这四个维度，不是孤立的。它们互相影响。比如，技术好能吸引社区，社区活跃能推动治理完善，治理好又能吸引商业投资。嗯，这里要注意，千万别只看一个维度就下结论。
我的经验：评估时，先看“治理维度”。因为一个生态如果连基本的决策规则都没有，其他维度再好也容易崩。我曾经见过一个技术极牛的项目，就因为创始人一言堂，最后社区分裂了。
2.3 知识体系结构图
为了让你更直观地理解这四个维度的关系，我画了一张图。这张图是我做评估时，脑子里一直挂着的框架。
避坑指南：我曾经犯过一个错误，就是给每个维度打分后直接取平均。结果一个项目技术分很高，社区分很低，平均下来居然及格了。但实际这个生态根本活不下去。所以，我建议用“短板效应”来思考——最弱的那个维度，往往决定了生态的天花板。
2.4 从CMMI到生态评价：思维的转变
最后，我想聊聊思维上的转变。CMMI关注的是“过程”，而生态评价关注的是“生命力”。
举个例子。CMMI里，你文档写得好，过程规范，就能拿高分。但在生态里，文档好只是基础。更重要的是，你的文档有没有人看？有没有人基于你的文档写教程？有没有人因为你的文档而加入社区？
说白了，CMMI是“静态”的，它看的是你“有没有”。生态评价是“动态”的，它看的是你“能不能持续地有”。
我个人习惯，在做生态评价时，会先问三个问题：
- 这个生态有没有“自生长”的能力？（社区维度）
- 这个生态有没有“抗风险”的能力？（治理+商业维度）
- 这个生态有没有“进化”的能力？（技术维度）
这三个问题，比任何模型都管用。嗯，这一章就到这里。下一章，咱们会深入每个维度，看看具体的评价指标怎么设计。