来自：计算机世界
开源解决方案在免去了昂贵的软件采购成本的同时，也缺少了提供商的技术保障，这时的用户该依靠谁来确保开源软件顺畅运行呢？
从多个方面来看，商用软件都价格不菲。而今，似乎嫌高昂的许可费还不够吓人，开发商只对它答应卖给你的产品提供服务支持，而且支持费用很难有讨价还价的余地。除非你能获得源代码，否则你永远无法自己修正软件错误----但软件开发商通常不会提供这些源代码。
那么，我们该如何摆脱依赖于开发商的窘境呢？一种流行的选择就是使用开源方案。这种非专有软件具有诸多重大优点。比如，它是免费的，或者至少不需要什么许可费。此外，谁都能获得其源代码。结果出现了一批新的支持服务提供商，数量还在稳步增长。
虽然企业仍处在采用开源的早期阶段，但这类软件越来越为人们所接受。据Forrester研究公司在2005年对北美100多位IT决策者进行的调查表明，2005年采用开源的公司多达56%，2004年只有46%。调查进一步发现，另外近20%的公司打算在当年使用开源软件，而前一年只有14%。另外据Gartner公司的一份独立研究报告表明，全球2000家组织当中有95%将在2008年前实施开源软件购置及管理策略。
诚然，有些公司开放软件的源代码，只不过借机营造声势，但不可否认，有关开放源代码的经营模式在日趋成熟，早期的几位开拓者已经发展壮大，为软件行业的发展真正带来了革命。虽然如今对开放源代码保持合理的怀疑是合乎常情的、甚至是明智的，但在几年后，开放源代码经营模式也许会真正成为标准而不是例外。
尽管开源软件非常流行，但不是每项开源计划都是从管理层开始施行的。在许多组织，软件开发队伍是在独立于CIO及其他IT领导人的情况下采用开源计划的，而且往往后者并不知情。有鉴于此，CIO们最好不要逆开源潮流而行。恰恰相反，他们应当肩负开源计划的责任，并且确保本公司已经落实了合理的支持结构。
没有免费的午餐
为什么软件提供商会开发源代码，像IBM或者Oracle这些公司到底有没有能力免费赠送软件？回答很简单: 它们其实没有这能力----至少从一个比较高的层次上看是这样。
由于许多原因，传统的套装软件拆封许可模式并不适合企业软件: IT基础设施变得更庞大、更复杂，按用户数量或者按CPU数量计费的许可模式变得越来越难以管理，深奥、复杂的定价公式导致费用结构无法准确体现软件的实际功用，更不用说会促使感到困惑的财务总监们挖空心思，想出种种新颖的记账手法。
由于这些原因，Sun等一些公司已经做出了新的选择: 弃用套装软件的拆封许可模式，改用纯粹的订购定价模式: 软件本身是免费的，客户需要花钱购买日常支持、维护及集成帮助等服务。
怀疑者可能会说，这只是另一种好莱坞式的记账方法，装模作样而已。确实如此，从长远来看，免去特定的许可费用未必意味着客户会节省任何费用。
值得一提的是，已决定采用基于订购的定价模式的公司离按服务收费只有一步之遥了。订购－支持软件模式就是开放源代码软件模式，剩下的就是开放代码---- 这正是Sun等公司正在做的事情。包括MySQL、AB和Red Hat在内的公司通过对免费软件的企业级支持来收取费用，在生意上大获成功。随着这类新兴公司不断发展、壮大，专有软件开发商们肯定会问自己: 控制源代码带来的商业利益是不是果真大于这种新的软件生存模式（即开放源代码软件）所带来的其他利益。
社区很重要
与决定购买某一个商业软件的决策时主要关注这家开发商信誉如何不同，在评估开放源代码项目时，相关因素却要复杂得多。对于软件开发商和客户而言，社区是开源软件的重要组成部分，围绕开放源代码项目而建的社区是开源项目能否成功的关键所在。如果缺乏活跃的开发社区的支持，再好的代码也会慢慢老化、逐步消亡。
对于用户而言，评估这些社区可能是软件采购过程中面临的比较困难的挑战之一。在公司决定部署任何开放源代码项目之前，经验丰富的IT人员对项目进行全面调查很重要。开发社区是如何组织的？采用了什么管理模式？哪些是最活跃的参与者？谁可以改动代码？改动频率如何？内部争议是如何解决的？代码的许可方式如何？
得到主要软件开发商的支持，这可以为开放源代码项目向企业用户进一步证明可靠性，不过这也会带来另外的问题。譬如说，商业软件开发商对待社区组建的态度各不相同。有的认为组建社区纯粹是自由放任的，而有的可能怀着这种希望: 利用自己的社区作为服务部门的销售渠道。作为客户，最好选择这样的公司: 不但宣传开放源代码，还明确划分了开放源代码项目和商业软件项目的界限。
最终，每个IT决策都始于业务问题。解决这些问题仍是每个IT组织的首要任务。正因为如此，在评估开放源代码软件时应当着眼于以下几方面: 特性、稳定性、扩展性、安全性以及专有软件遵守的所有其他标准。
不过，开放源代码数量激增自然的结果就是选择更多了。最有能力权衡这些选择的人就是最熟悉项目的人----他们知道社区的所有详情，而且对项目的发展了如指掌。正因为如此，对最成功的公司而言，深入了解技术、技能娴熟的IT人员无疑是重要资产。
开源软件成熟吗?
人们发现，开源软件项目越成熟，用户获得的支持方案也就越成熟。譬如说，许多组织可以获得JBoss的支持服务----JBoss是JBoss公司的一款开源应用服务器; Covalent Technologies公司为流行的开源Web服务器Apache提供支持。另外，成功的开源项目背后有庞大、活跃的用户社区可提供技术帮助。
不过，并非所有的开源项目都拥有充足的支持----这对CIO们来说是个不足。在开源托管站点SourceForge.net上所列的10多万项目当中，只有一小部分既有成熟的支持方案，又有活跃的用户社区，实际上，这些项目当中只有1.7%被认为是成熟的。
确定哪些开源支持方案是最佳方案，这取决于诸多因素，其中包括组织在使用哪种开源软件、使用方式以及组织本身具有哪些软件支持能力。为了帮助CIO们做出明智的决策，不妨考虑以下六个技术支持方案:
1. 产品支持。一些成熟的项目得到了JBoss和Laszlo等开源开发商的支持，这些开发商通过提供服务来赚钱。开发商支持的这类项目仍被认为是开源产品。
根据JBoss的这种“专业开源”模式，用户组织与众多开发商签订不同协议。协议在所需的具体软件、可用服务级别以及支持成本等方面各不相同。因而，开源产品组合越复杂，支持服务组合也会变得越复杂。用户组织负责集成不同组件，并负责解决可能会出现的兼容问题。
开源开发商提供的支持往往好于商用软件开发商。与传统的开发商不同，它们通常为客户提供可以直接联系其开发队伍的便利，而开发队伍通常包括原始开发项目的成员。这些队伍可以按需要改动项目的源代码。
2. 开源中间件支持。如今已出现了统称为开源中间件提供商（stack provider）的一批新公司，它们旨在解决: 集成及支持一家组织里面的多个开源软件组件。开源中间件提供商把通常使用的一套套开源软件组件组合起来，并为这些组件提供服务，包括支持和集成测试。
几个知名的商用软件开发商包括惠普和Novell正在开发类似的开源产品。如果公司计划使用一套常用的开源软件组件，与开源中间件提供商合作也许能满足需要。不过要注意: 大多数开源中间件提供商只支持最流行的组件。
此外，开源中间件提供商本身对软件的了解程度通常不如开源开发商。正因为如此，一些组织选择与能为客户提供更高技能的开发商合作。这是个很好的折衷办法。
开源中间件提供商的另一个不足就是，它们没法雇用所有开源项目队伍的成员。因而，一旦发现问题，它们只好与众多队伍协调可能改动代码的事宜，而不是直接改动代码。诸如此类的考虑因素可能会让一些CIO不敢选择“只有一个责任对象”的开源支持方案。
3. 社区支持。成功的开源计划带来了活跃的网上社区，这类社区可提供多种支持方式，包括邮件列表、讨论论坛、甚至直接通过电子邮件与开源项目开发人员通信。不过社区支持想获得成效，组织要有强烈的主人翁感觉。
CIO千万不要把社区支持与免费支持混为一谈。完全依赖社区支持的任何一家公司实际上都是把支持问题交给自己来处理。比较明智的公司也会有内部专家: 一旦出现问题，他们就负责系统维护和寻求其他帮助。这些内部专家应当成为加入相应软件的庞大网上社区的用户。
与商用软件开发商不同，开源社区不会根据企业的规模大小来优先对待用户。也就是说，一家《财富》100强公司的CIO得到的支持级别与一家小型非营利性组织的CIO所得到的支持级别相同。同样，一家大公司的开发队伍所发的帖子不会自动得到优先处理权，哪怕这帖子是有关生产过程中的重大故障。要提醒的是，如果你向开源社区寻求支持，就要有一定的耐心。
4. 培训现有技术人员。虽然开源软件要求企业在很大程度上依靠自己，但未必需要新招技术人员。相反，企业可以对现有技术人员进行培训，以便熟悉使用相关软件。由于IT预算缩减、培训机会渐少，这种举措有望通过发掘新的增长点来提升员工们的士气。可以从越来越多的公司获得培训，其中包括Covalent、 JBoss和LearningPatterns。
5. 雇用项目开发人员。依赖开源软件的一些组织雇用专职的开源项目开发顾问作为开发队伍成员。增加专业人员帮助组织自身提升了技术实力，并且增强了自我支持能力。另外，拥有这些项目开发人员让组织可以直接改动源代码。
不过这种方案也有其局限性。首先，必须慎重处理好客户对开源项目会产生影响的这个问题，因为社区可能会觉得参与者是在为自己谋利，而不是有益于整个项目。其次，雇用开源项目开发人员需要财力资源，而拥有这笔资源的公司比较少。最后，一旦开源计划规模迅速增加，这种模式不具备良好的扩展性，对项目开发人员的需求会超过现有人才的数量。
6. 借助顾问。如果组织无力雇用开源专家、没有时间进行内部培训，或者不需要专业支持协议，那么借助顾问不失为一种切实可行的选择。很容易通过开源项目邮件列表和开发队伍名册物色到专家。一些网上资源也有所帮助，譬如著名的FindOpenSourceSupport.com网站。2004年设立的这个网站列出了500多个开源顾问和提供商。
但借助顾问最好是过渡性地，因为从长远来看，他们的费用比较高，而且不如固定员工忠诚。他们可以逐渐对内部队伍进行培训，然后需要时仍可以随叫随到。
开源支持要讲究搭配
获得出众的开源支持服务并不在于单单选择其中一个方案，而是找到适合组织的最佳组合。没有哪个解决方案能满足所有组织的所有开源需要。CIO们应当先调查一下所有方案，然后在谨记自身需求的情况下，对诸多机会进行评估。
企业使用的开源软件用于非关键系统还是生产环境这很有关系。从开发阶段进入到生产阶段，支持需求也会随之变化。
尽管这道理听上去很显然，但许多组织常会犯这个错误: 对所有的支持需求一视同仁，不管涉及的风险有多大。这是因为CIO们习惯于同商用软件开发商合作，这些开发商提供从开发到部署，甚至部署以后的支持。不过如果用的是开源软件，可以获得代码和网上用户社区，假如组织内部的技术能力足以胜任的话，在评估或者开发过程中就不需要开发商的支持。这些早期阶段的开源支持往往更加注重于学习曲线，这可能会让一些公司受益。
一旦开源软件从部署阶段进入到实际使用阶段，其支持需求就会酷似商用软件。组织希望24×7的全面支持、服务级别协议、问题上报路径以及明确责任。
如果系统涉及风险越大，围绕软件构建可靠的支持结构就越重要。虽然没必要为非生产系统购买支持方面的“保险单”，不过对面向生产环境的系统来说提供可靠保障可能是基本要求。
随着开源开发商竭力满足企业用户的需求，支持模式会继续随之发展。与此同时，用户会逐渐接受软件开发方面新的社区模式。
培养开源方面的专长和技能需要藉以时日，同时，还需要CIO们愿意尝试新模式来开展业务、管理资源。不过只要方法得当，开源软件带来的好处会远远超过风险。
链接:三个月部署开源项目
不同组织对开源支持的需求各不相同，这取决于组织所用软件的类别和用途。你在着手拟订支持策略时，还要把将来的需求考虑进来。下面教你如何开始着手:
第一个月: 审查当前及将来使用开源的情况。
● 详细列出当前正在使用或者考虑使用的所有开源软件。连员工一直未经批准但在使用的软件也要考虑起来。
● 为每个开源组件确定内部负责人，并确定目前的服务如何提供。指定某个人负责确认的每个组件。
● 根据软件对企业的重要性，确定每个开源组件所需的理想的支持级别。譬如说，生产环境中的开源软件需要的支持级别要高于开发队伍所使用的开源工具。
第二个月: 拟订开源支持计划。
● 与组织的法律和采购部门商谈开源软件事宜。开源软件的使用不仅仅是IT开发部门的事，开发队伍应当与业务队伍密切合作。
● 拟订开源支持计划，包括明确定义预期目标。调查分析每个开源组件的所有支持方案。
● 检查资助新计划的预算。针对现有开源软件的补充支持需要额外成本。确保新成本已考虑在内，提议把新成本列为下一个预算周期的新添加项目。
● 即使你在评估商用软件，也要评估新的开源组件，并确定了选择支持服务的标准。
第三个月: 开始推广计划。
● 记下哪些社区支持所有开源组件。
● 对现有IT供应商的开源技能级别及支持机会进行调查，评估另外的开源软件服务商。
● 根据审查和支持计划，为开源支持拟订需求建议书（RFP）。把建议书发给提供商，包括现有的IT供应商以及产品和组件支持专家。让你的内部开发和业务队伍也要回复建议书，即把他们当成是外部供应商。
● 关注培训和雇用能力，以增强内部支持水平。
