在本系列的第一部分如何确保软件项目成功中，我们提到了项目成功相关的一些术语，并大致罗列了一组跟项目成功相关的东西……尽管从某种程度来说“提到”意味着“彻底无视”。

我们通过提供一种开放式的思想实验来完成：你是如何定义这些术语的，你看到项目是如何处置这些东西的？在这些质量指标里面哪些令项目成功或失败？

问题域

• 使命宣言
• 可见性
• 解决方案适当性
• 流行度

社区考虑因素

• 质量
• 个人崇拜
• 支持向量

项目细节

• 易用性
• 源语言
• 授权
• 发布数

尽管许多人对上述的很多东西都会有自己的个人定义，但是我们还是先来看看其中一些一般定义，以便对这些术语作为成功因素的构成方式有一定的范围和角度上的理解。

问题空间

项目的问题空间指的是它是做什么的。

项目的使命宣言在相当程度上决定了项目能否成功。比方说Hibernate就把自己的问题空间定义为将对象模型映射到数据存储（通常为关系数据库）中去。

相对于那些拥有具体目标的项目来说，缺乏特定目标或目标难以解释清楚的项目往往很难成功。

可见性是另一个成功因素；一个更好捕鼠器也许会是一项出色的发明，但是如果没人意识到它的存在的话，它一样也不会出现在大多数对成功的定义里面。像TheServerSide.com、DZone、InfoQ、Reddit及StackOverflow等网站都把让项目具备可见性列为成功的重要因素。

项目也许定义明确，也可能有机会为人所熟知，但如果它未能实际完成自己的使命宣言要求的话，也不会取得成功。想象一下如果Hibernate因为数据中含有字母“A”而无法将数据持久放入到数据库—这一失败将会成为通往成功的巨大障碍。

最后，项目的流行度，即安装数与潜在使用量之比也是成功定义的一个重要因素。这个数字是相对的；如果有400个应用需要特定的解决方案，而给定项目在其中390个里面被用到了，则可以说该项目在这个领域是非常成功的。然而，如果有400万个项目都可以使用这个解决方案，但只有390个安装量的话，那么其流行度就算不上成功的积极因素。

当然这并不意味着项目不成功。正如开头介绍那样，角度就是一切—如果项目维护者预期用户是10个，但最终却收获了300位满意的用户，那么维护者可能就要乐坏了—而MegaSellOutCorp（百万销售级企业）则可能会把300用户视为彻头彻尾的失败。

软件项目社区

对项目成功的另一种衡量可以看看是谁维护该项目。从很多方面来说，维护一个牢靠且快乐的开发者社区和用户是项目成功的先行指标—因为如果社区满意了，那么前面列举的项目关注点就有很大的机会可以以令人满意的方式得到处理。

软件项目社区有两个重叠的群体：用户及维护者。许多维护者本身也是用户—正是用户的身份让他们一开始成为维护者。

我们先看看一下维护者社区。

维护者是否是一个大型的社区？有多少维护者是投入并为项目成功做出专门奉献的？成为维护者的一员是否无足轻重？他们接受技能不娴熟的维护者吗？如果是，他们担任的是什么角色？

如果项目没有准入门槛，并向不理解问题空间或项目结构的人赋予做事的权利，那么该项目的成功之路很可能就会比组织紧密、专注且重视价值的维护者群体运营的项目要坎坷。

当然，项目有时候也会有个人崇拜的一面，这可以是积极的，也可以是消极的。

个人崇拜是指这样一种社会结构，在这种社会结构里面，充当磁铁作用的是一个人的魅力或过去的声望，而非此人目前的贡献或技能水平。这样一位项目成员也许能为项目吸引用户或别的贡献者，尽管他并没有做出别的贡献。

这可以说是积极的一面，因为它向其他人表明，这位名人对项目的信任足以让公众参与项目，而一个有效的精英管理则有可能筛选掉任何奉承者，这样就可以让社区拥有更大的用户群以及从前者中抽取出来的贡献者。

但这也可能带来消极的一面。如果这位名人吸引到负面的关注，或者精英管理运转不畅，无法忍受额外关注带来的噪声的话。

此处还有一个因素是社区是如何相互沟通的。是否主要靠IRC？StackOverflow？基于Web的论坛？电子邮件？电话？上述一切均有各自的优劣；强有力且成功的项目可能会拥有上述众多的沟通渠道，且往往会把所有的公报汇集到一个集中的、可搜索的容器之内。

当然，还有一个问题就是如何衡量这些东西。有项目（如EKG）对邮件列表及其他渠道进行检查，希望从中能衡量出社区的健康状况和活跃度；可以按照频率、质量、意图等标准进行观察，再去衡量其中有多少活动，以及这些活动有多大用处。

如往常一样，应该做什么或者能做什么，这个问题并没有完全正确或错误的答案。在衡量社区沟通的监控方面，The Open Source Way努力收集很多的思考， 作为一个关注开源的网站，每个人都应该为这个知识的通用池做出自己的贡献。