(转)开源软件开放不仅是代码

开源的世界是开放的。订阅用户邮件列表，或者通过其他的渠道，你很容易了解到其他人在对这个软件做的工作哪些功能是好的，哪些功能还需要改进。阅读项目计划图或者供公开访问的bug列表能够帮助你了解这个项目发展的方向，谁在推动它，以及项目的团队组织是否良好。你还 能够了解其中人的个性以及社交的状况。

当你阅读这些记录的时候，要注意哪些问题还没有得到解答，而哪些问题已经被解答了。有几个活跃的人物在为这些问题提供解答，标志着这 个团队的强盛，只要其中的一个主要人物还在继续，项目就会延续下去。你还应该看看这些解答的内容。漫长的说明可能意味着在创建文档方 面缺乏有效的管理流程。这也意味着用户需要不断地寻找文件，而不是进行代码维护。例如，如果你发现这样的指示：“comment out the line that says x and add the following code …”，这也许意味着没有人负责制作补丁。
查看（或者让你的技术人员查看）开发指南。管理良好的项目有功能性路标，发布流程说明非常清晰，拥有自己的代码标准，以及用户体验（ 比如能够自动确认各部分代码是否冲突的单元测试）。浏览开发者网站能够帮助你了解开发团队计划发布哪些功能，并进行哪些类型的测试。

浏览bug跟踪系统能够告诉你这个软件测试的活跃情况，以及解决问题的效率。不要认为在bug跟踪系统中有很多bug的软件就是糟糕的。这意味 着这个软件被很多细致的人在使用，他们能够配合开发团队一起改进这个软件。查看一下问题的内容。bug跟踪系统也记录了各种建议要求，这 些内容反映出了用户对这个软件的发展期望。

更重要的是，你可以实际地尝试使用这个软件。很多情况下，你甚至不需要安装软件就能够看到演示。在 www.opensourcecms.com这个网站上， 有超过70个基于CMS的开放源代码LAMP，包括在这里提到的Drupal、Mambo和Joomla。eZ publish、Lenya和phpBB都在自己的网站上提供了DEMO 演示。在你体验软件的过程中，要让未来的用户参与进来。让他们试用软件，让他们把认为需要改进的地方列出来，并说明这些改进的重要程 度。在这个过程中让他们做主。这种做法能够让他们更好、更深入地了解解决方案，从而提高使用率。

在这里，对于评估商业软件来说，我也推荐采用这种做法。但是软件公司不愿意透露技术背后的技术人员，技术支持有多大帮助，以及企业周 转的情况。

 

如何分配节省下来的经费

技术并不是决定内容管理项目成败的首要因素。内容管理项目的成功依赖于内容迁移、改进商业流程，和应用推广。由于不用支付许可证费用 、缺少各种支持，解决方案的投资应该被调整，投放到对于内容管理项目成功影响最大的一些因素上。

你可以将更多的时间和精力投放到更好地理解需求、管理项目、改善商业流程、迁移内容，教育用户方面。在《Spending patterns during CMS implementation》（CMS项目实施的消费模式）一文中，James Robertson 在Step Two中写道，实施只是CMS项目三个阶段中的第一个阶段 。实施阶段后面是推动使用阶段，这个阶段中包括了数据迁移、培训、宣传解决方案所带来的好处、关注那些被推迟实现的需求以及在项目实 施后才涌现出来的需求。Robertson建议对于第二个阶段完成所需要的时间要有比较合理的预期，这个阶段可能会持续12个月，之后仍然需要增 强。

在解决方案安装后，要允许它发展。如果股东在项目的早期阶段就能够介入的话，他们就有机会了解这个软件在他们的商业流程中能够起到什 么样的作用，这会增强他们的参与感，他们也就更愿意去思考如何改进这个项目。你应该让这些商业用户了解这个软件还有潜在的增长空间， 这样他们在对待软件刚开始应用的范围这个问题上，就不会那么顽固。

怎样支持开放源代码软件

因为开放源代码软件代表你拥有更多的支持选择（商业公司提供的支持、咨询公司提供的支持以及开发团队提供的支持），应该对于企业的支 持需求进行全面的考虑。一些公司由于政策或习惯，总是购买支持服务。在一些情况下，如果支持请求比较频繁，这种投资就非常有价值。在 另一些情况下，软件运行不太需要人为干预，或者企业内的技术人员拥有该方面的技术，subscription模式的支持服务就不是那么有意义了。 开发人员经常会发现，从知识库或者使用公共搜索引擎寻求帮助比打电话或者用电子邮件求助更为方便有用。

如果希望获得商业软件风格的支持，可以寻找那些进行该开放源代码项目的公司或者第三方公司（比如SpikeSource和SourceLabs）。帮助实施 该解决方案的系统集成商也会提供从peruse-based到subscription-based的各种不同支持模式。

你实施项目的时候，你还应该考虑你应该如何回报开发团队。虽然没有人要求你应该把针对自己使用需求开发的代码开放给开发团队，但是你 可以这样回报他们。一个好的规则是如果代码所带来的竞争优势没有维护它的成本高，你就可以把代码回馈给开发团队，接下来事情可能会很 奇妙。这些代码会经受很好的程序人员的检查。如果这部分代码成为核心程序中的一部分，你在升级的时候就不用太担心了。这种做法的另一 个潜在好处在于：开发团队可能根据你所提供的代码，开发出对你很有用的新功能。然后软件就会变得更好，吸引更多用户来使用，从而也就 具有了一个更可靠的未来。

结论

有些公司寻求的是一个能够解决具有共性问题的、直接的解决方案，开放源代码内容管理软件对于它们来说非常具有吸引力。然而，传统的软 件选择方法对于评估开放源代码软件来说，却并不适用。事实上，由于开放源代码的内容管理软件有丰富的选择，从大量的软件中筛选适合自 身需求的一款可能是一项非常乏味、让人迷惑的工作。

为了找到方向，你应该关注商业问题，并着手了解其他公司是用什么软件来解决类似问题的。缩小了选择范围之后，开放源代码世界的开放性 让你能够对于软件进行更深入的了解，这一点是你在商业软件世界里不能做到的。只要你能充分利用这些优势，开放源代码就能够降低项目的 风险，为你提供一种能够跟随你公司的成长而发展的解决方案。