在本系列的第一和第二部分里面，我们讨论了项目成功因素方面的术语，因为如果没有对什么是成功的共同理解，就无法共同取得成功。我们还谈到了影响成功的两个主要方面“项目的问题域（要做什么）以及项目的社区（做的东西给谁用）。

然而，问题域以及社区并不是软件项目本身。你可以把分类当作问题领域连续讨论几个星期，但分类的问题跟实际执行分类的库并不一样。问题空间是“如何从A点到达B点”。而项目则是“一辆本田雅阁”。

项目本身

是时候讨论交通以及谁可能需要它的问题了，也该开始讨论由什么来提供交通了。这些方面大都相当琐碎（且明显）但它们仍将影响项目成功，而做出审慎决策的项目相对于未经深思熟虑的项目更有可能成功。

首先，项目实际使用的容易程度如何？项目有可能是完全针对问题的，结果的精确度也是极佳的，并且有具备奉献精神和才华的维护者，但如果用户群不知道如何恰当地使用该项目的话，它也不会非常成功的。一个成功的软件项目将会下大力气为了现有用户和新用户去降低门槛。

分类作为一个计算问题已经被提到过。分类的一个困难是尽管就普遍意义而言概念是好理解的，但每一个需要分类的实际应用对分类库都有着独特的需求。因此，分类库往往要么太泛化—因而对于新人来说十分费解—要么又太具体而无法重用。这是准入门槛过高的一个例子。

另一方面，你还有像Spring这样的库，这让应用中的依赖注入简单易用。这是低准入门槛的一个例子。

帮助降低准入门槛的事情里面有一件事是很明显的：文档。文档必须明白清晰地进行记录，在可读性和细节上做好平衡，以便推进项目的成功。

清晰的文档是很难做出来的；许多项目几乎都不提供什么细节，因为维护者感觉用法是很明显的，但有的又提供了太多的信息，导致只见树木不见森林。尽管考虑清晰和考虑细节的文档都有很成功的项目可以拿来作为例子，但做好二者平衡的项目仍将拥有更高的成功机会。

源语言（及人工语言）也是一个因素，在大部分情况下，只不过是因为它带来了与相关语言社区的联系，并把该语言的理念以及思潮引入进来。

它还影响到那些认为自己能够使用给定项目的人。在开发过程的早期阶段，哪怕项目是用不同语言编写且恰好完美解决了手头的问题，用C写应用的开发者一开始不会打算看Java库；Java编码者正常情况下也不会去看C库，或者Scheme库。

这并不意味着源或人工语言可以以任何方式规避；语言之间当然有沟通的桥梁，以插件或甚至是架构性的方式如消息传递系统或HATEOAS解决。

然而，规避通常不是一种积极的方式；如果为了利用给定项目用户预计会使用外部的东西，那么就值得做出努力尽管这会进入其他项目的竞争。

授权（许可）当然也是一个因素。开源许可往往导致低的采购成本—使得下载和试用很容易。有些许可因为增加了限制而影响到项目的成功；比方说GPL就是一种病毒式许可，有的用户会选择回避，无论是出于自己的选择还是因为迫不得已。

如果项目费钱，那么其价值定位就非常重要；一个2000美元的项目仅带了100美元的回报用大多数的衡量标准来说都算不上非常成功。

这也会影响到项目相关的社区。免费提供的项目，代表的是让维护者感到满足的责任—而满足可能就包括真金实银，尤其是如果项目得到积极维护的情况下。维护者的努力如何得到补偿？如果对于维护者来说不值当，那么项目得到的维护也会越来越少，这是一种损耗性的模式，对于长期项目来说往往无效。

因此，维护者的满足是一个重要因素。如果维护者需要钱（有谁不需要呢？），那么他们如何获得回报？通常这是通过支持合同来实现的，维护者像客户提供问题支持、架构支持，或用一些其他方式提供优先支持等。

然而，项目的货币化也是一个社区成本；许多消费者厌恶以任何形式向“免费”提供某物的人还债的想法。

成功的其他一些衡量标准是项目年限、项目的发布数，往往被称为是“项目扰动”。维护数年的项目往往比更新或缺乏维护的项目更成功；也可能是很显而易见的事情，但是也应该纳入衡量的因素里面。

需指出的是，扰动并不是一个好的单独的成功指标。一个只有少数几个版本的项目可能会很好。比方说TeX的最后一次重大发布是1991年（尽管“重大”的定义有很多种解释）—但TeX仍然是排版的一个非常流行且知名的标准。

结论

你所看到的是对项目成功某些方面的一个非常粗略的概述，以及对成功的实际含义的一些思考。

你看到了对项目结构方面考虑的部分建议。里面有一些可行的建议。成功是一个合算的目标，给那些经历过的人带来了自尊。尽管打造一般意义上的优秀项目并没有简单的指南，我们至少可以两头下注，通过考虑成功努力的属性以及尽可能好地处理好这些东西来避免损失。