1.18  开源基本原则

在研究开源现象时，有几个支持积极营销的基本细节经常被忽略掉。我愿意趁这个机会提出这些细节，因为它们在我们面对DotNetNuke项目中的一些问题时，提供了一些额外的处理角度。

开源信念的第1个荒诞说法，就是开源项目基本上都拥有一个能够直接支配的不受限制的资源池。尽管从纯理论角度讲，这可能是真的，但是现实情况是用户仍然需要一个专用的管理结构，来确保所有的资源都可以以一个有效且富有成果的方式合理配置。如果没有某些类型的中心管理权威机构，那么一群开发人员就永远不能始终如一地生成一个能聚集在一起的应用程序，极有可能的情况是，他们各自的努力将引发大范围的混乱。只要核心的程序员轻视这一概念，就绝对需要专用的管理来设置期望和目标、确保产品的质量、减轻风险、识别关键的依赖关系、管理范围并承担最终的责任。大家将会发现任何成功的开源项目都会有一个高效并且高度受人尊敬的管理团队。

同样与不受限制的资源管理荒诞说法相关，参与到开源项目中的资源，拥有能够在知识界精英中获得一个高度信任位置的能力和沟通技能的资源实际上极少。一般情况下，参与到开源项目中的资源能够处理面向消费者的任务，例如：测试、支持和较小的缺陷修复。这并不是说这些资源没有在项目的成功中发挥关键作用—— 每名志愿者哪怕是一点点的努力都会帮助项目取得成功。但我的观点是大多数开源项目通常有一个相对小的组，他们负责了大部分的架构功能增强工作。

另一个荒诞说法与任何人都可以直接或者立即影响开源项目这一开源信念相关。尽管这在某种程度上可能是真实的，但在用户在社区中获得任何类型的特权之前，用户通常需要建立一个可信任的声誉。极少有人被直接授予源代码储存库写访问的权利。任何人都有能力提交一个补丁或者功能增强建议；但是，开源项目并不保证会将它们添加到代码库中。实际上，所有的提交都要受到可信任资源的严格同级审查(peer-review)，而且只有在他们通过了所有的验证标准之后，他们才会将提交引入到源代码储存库中。另外，尽管某个特定的提交在单独判断时可能会相当有用，但是在升级支持之前还需要考虑一些较高层次的问题(如果没有完全解释清楚问题，则有可能会挫伤提交者的积极性)。从控制的角度来看，这与传统软件项目的源代码控制管理没有太大的区别。但是，开源模式对这种范例进行了极大的改变，授予每个人审阅源代码的权利。因此，所提交的需要处理的补丁数量可能极其庞大。

开源基本原则还有一些有意思的解释，偶尔还会导致意见的不同，在最坏的情况下还会使全部社区成员感到厌恶。这种情况经常发生，因为开源的指导方针相当不明确，并且还很主观。与DotNetNuke相关的一个相当热门的话题就是源代码的访问。

一些开源项目，在任何时候只提供开发源代码库的匿名只读访问。那些希望及时了解项目最新成果的开发人员欣赏这种完全透明的方式—— 即使他们不是核心项目团队的可信任成员，它们也可以阅读最新的源代码。这些开发人员能够接受这一事实，即开发代码在某个给定的日子可能处于不同的稳定阶段，然而他们乐意直接访问关键的修复或者功能增强。尽管这种模式确实能够促进更多外部的主动同级审查，但是它也经常产生许多严重的问题。如果开发人员决定在产品环境中使用预发布(prerelease)的代码，那么他们可能会发现他们维护了一个不安全或者不稳定的应用程序。这种模式会导致一种情形发生，即社区期望支持应用程序的许多派生变体，而不是一个一致的基准应用程序。另一个可能发生的问题，就是屈服于个人动机的开发人员可能倾向于在当前的产品版本中集成一些正在开发中的功能增强，并将它作为一个新的应用程序版本发布。尽管开源许可证允许这样做，但是这样会严重影响正式项目维护人员支持社区的积极性。在从一个版本升级到下一个版本的过程中，项目维护人员有责任始终确保一个受管理的移植路径。人们只有使用由项目维护人员提供的正式的基准发布，这种模式才能获得支持。没有这些恒定的构建，应用程序升级就需要手动操作，许多用户就会被应用程序的发展抛弃。出于这些原因，DotNetNuke选择限制开发源代码储存库的匿名读访问。相反，我们选择定期发行发布，这样就可以随着项目的发展为大家提供一个一致的升级机制。