近日,一项名为BRR(Business Readiness Rating,商业就绪分级)的新开放标准模型计划备受关注,该计划由卡内基·梅隆大学西部的开放源代码研究中心、O'Reilly CodeZoo、SpikeSource及Intel公司联合发起,其意图是使整个开源社区(包括企业用户和开发者)以标准和开放的方式来对开放源代码软件进行评级,以方便对开源软件的评估并促进其应用……
评估软件对于IT管理者来说是一项非常重要的任务,但是开源软件的潜在用户却一直没有一种简单、有效、可信的方法来帮助它们做决定。没有广泛使用的模型来评估,这就使开源软件的采用复杂化,因为各个公司之间评估开源软件的时候很少能够从相互的实践中获得有用信息。
由一些公司和研究中心联合发起创建的BRR模型,就是要帮助IT管理者快速对开源软件做出有信息来源和根据的决定,该模型也允许使用者把他们的评估结果反馈到开源社区。据悉,BRR模型主要是权衡一些公认为是在开源软件部署中最重要的因素,包括功能(functionality)、品质(quality)、性能(performance)、支持(support)、社区规模(community size)、安全(security)等。BRR模型具有开放性和灵活性,也是标准化的,无论对开源软件还是商业软件,都将能够更广泛地实现系统的和透明的评估。
选择软件面临的挑战
决定在一个组织内部采用哪一种软件包是一项具有挑战性的任务。往往在享受软件所承诺的好处的同时风险也会出现,如兼容性、可用性、可扩展性甚至合法性等问题。
一般来说,企业会依赖于商业或专有软件,尽管有如下的限制:成本通常很高;封闭的源代码,软件真正的安全性和品质是未知的;被锁定并缺乏对未来路线的影响,供货商选择来对软件做什么样的改进, 如果客户请求不符合供货商的未来路线计划便很有可能不予以理睬。这些因素几乎抵消了使用商业软件带来的主要好处,但是重要的一点,商业软件供应商有专门的支持人员帮助客户解决产品问题。
不过,开源软件也正在越来越多地被商业应用所考虑,分析其中原因主要有以下几方面:
成本:通常是免费的;
有权使用源代码:由于源代码是开放的,被参与的程度大,因此成熟的开放源码项目甚至比同类的商业软件要更加安全;
开放架构:开源软件通常是通过一个虚拟社区开发出来,因为开发社区在地理上是分散的,开源软件通常设计为模块化的,模块化代码是可扩展的,并易于调试;
品质:源代码和架构的透明使得管理良好的项目能够开发出成熟、高品质的产品。
尽管有这么多好处,但仍有一些因素会妨碍开源软件的采用。最突出的是,开源项目数量巨大,范围从低品质个人产品到高品质的企业解决方案。据悉仅SourceForge一家,就列出了超过10万个开源项目,再加上诸如CodeHaus、Tigris、Java.net、ObjectWeb、OpenSymphony等一些开源社区,就更难以计数了。
开源软件的使用者及潜在用户面临以下挑战:
选择:对于一些软件类别,选择几乎是无限的;
支持:大多开源软件包没有得到专业支持;
寿命:由于大多开源项目没有得到商业公司的支持,未来的产品版本跟进就取决于社区的努力;
速度:很多开源项目是以“早发布、频繁发布”这样的原则来牵引社区,这就造成了在开源世界中惟一持续的就是变化,很多开源软件的潜在用户根本来不及追随开源世界普遍存在的软件包快速更新的步伐;
不成熟项目的低质代码:在概念阶段,开源项目通常是由一些特殊癖好者或经济窘迫的IT人员开发,他们往往是对开发出一些东西充满激情,但是这些早期开发者缺乏完成一个完整产品所需的资源或必需的经验,一旦他们已经得到解决他们问题的那部分东西,项目就有可能被很快遗弃,一些新的项目通常都没有经过正式的软件工程或测试。
结果,开源软件的品质问题就走了两个极端,广泛被采用的开源项目常常演进为高品质的软件产品,它们甚至比同类商业软件更出色;然而,一些不成熟的开源软件给使用者带来的可能是比好处更多的风险。因此,确实需要一种能够广泛被采用的、标准化的方法来评估开源软件的成熟度。
为开源软件评级—商业就绪分级(BRR)模型_职场
当今的软件评估实践
IT管理者要决定部署哪一种软件,通常需要先列出很多可供选择的名单,然后做一遍快速评估,把这个冗长的名单精简为一个满足基本需求的、供最后挑选用的侯选名单(shortlist)。创建一个侯选名单有时也是令人胆颤心惊的,因为可选的开源项目过多,并且未来版本不确定。然而没有候选名单的话,很多时间和精力又会浪费在评估不合适的项目上。
在排除不合适选项的时候,一份好的候选名单应该尽可能多地包含可行的软件选项。对于特定的应用范畴,软件特性或规格就是很有用的“过滤器”,诸如应用的基本工具语言或它支持的数据库类型等。然而,对许多应用范畴来说,这样的过滤器还是很难起到明显的作用。例如,即使经过“编程语言”这个过滤器筛选之后,[url]http://www[/url]. cmsmatrix.org这个网站上还是列出了375个可能的内容管理软件包,名单仍然很长。
创建好候选名单后,IT人员必须对名单上剩下的软件包进行更全面彻底的评估。大多评估者都需要创建自己的评估方法,而不能使用其他人的评估数据或方法,即便该软件已经被其他人评估过,他们也必须自己重新评估每一个软件。
实际中,很多软件评估项目都是专项来做的,也并没有正规的评估方法。这种专项的做法在评估过程中也许不正确或不完整,要确保评估的正确性是相当困难的。但是可以肯定的是,不正确和不完整的评估机制会导致错误的决定和产品选择,这也就是专项评估的风险所在。
为开源软件评级—商业就绪分级(BRR)模型_职场_02
开放和标准的软件评估模型
怎么能够使得商业用户、开发者或IT工程师更容易决定使用哪一种开源软件呢?他们又如何能够确信所考虑的软件对于他们的目标来说是足够成熟或商业就绪了呢?
上述一些公司和研究中心建议,使用开放和标准模型来评估软件将会更容易进行,并增加评估的准确性,从而也能加速开源软件的采用。另外,一个广泛采用且没有争议的开放和标准模型也能够使得开源软件用户共享评估结果。
为开源软件评级—商业就绪分级(BRR)模型_休闲_03
为什么要标准化呢?标准化的模型能够带来对评估级别的普遍理解。为什么要开放呢?开放模型能够确保评估过程的可信,它也能确保评估模型对未来变化具有灵活性。开放模型对正确性的保证也是很容易理解的,因为模型的潜在使用者都可以查看、评论并改进它。
当然,这样的模型应该包含的关键要素就是一个好的软件分级模型,该软件分级模型必须具备CSAC(Complete、 Simple、Adaptable、Consistent)特性:
为开源软件评级—商业就绪分级(BRR)模型_休闲_04
完整——任何产品分级模型基本的要求是具备突出产品所有显著特征的能力,而不能因个人喜好而变化,这样才能保证对任何产品的分级都是没有偏差的;
简单——要获得广泛接受,模型必须易于理解,并相对易于使用,而且分级和术语都应该是客户友好的,当然模型的完整性更为重要;
可修改——由于软件产业的快速变化,今天所创建的任何软件分级模型未来都会部分过时或失效,在概念阶段,不可能捕捉到模型在未来的所有潜在应用,因此,创建的模型是否具有可修改性非常重要,也就是它必须是开放的,这样,当模型需要扩展时就可很容易对现有模型进行添加;
一致性——针对不同的目标应用,模型所产生的等级或级别必须是一致的,来自两种不同范畴的两种软件的可比级别应该表示同样的商业成熟度。
BRR模型介绍
SpikeSource、Intel等公司联手的目的就是要简化开源软件的评估,最终,他们共同提议创建一个标准和开放的模型——Business Readiness Rating (BRR)。
BRR旨在帮助IT管理者评估哪一种开源软件最适合他们的需求,开源用户可以与潜在用户共享他们的评估分级,从而维持开源软件的良性循环和“参与性架构”特色。
在这个模型中,建议对不同类型的评估数据做标准化,并分组为不同的范畴(category)。为了能够让该模型可以用于软件所能遇到的各种情况,特将评估过程分为四个阶段:首先,一个快速评估,把软件包选入或排除,创建一个可行软件组成的候选名单;其次,把category或metric按照重要程度排序;第三,处理数据;最后,把数据转变成BRR。一个软件的BRR分级是用数字1~5来标识的,其中1代表无法接受,5代表最佳。
下面介绍BRR概念及如何使用该模型。
最初过滤
在评估一个开源软件的商业成熟性时,用户会从查看该软件的几个定量及定性特性开始。在最初的快速评估阶段, 一个简单的“过滤器”可以让潜在用户自信地快速选择或删除软件。
在这个阶段使用“过滤器”有一些准则可参考:
该软件的许可/合法性如何?
它遵循标准吗?
有供参考的使用者或用户吗?
是否有与该软件有关的固定组织或支持?
它的工具语言是什么?
它是否支持国际化并对你希望的语言进行了本土化?
有针对该软件的第三方评论吗?
是不是有与该软件相关的书籍出版?
它是否被Gartner或IDC等分析机构所关注?
以上快速评估的过滤准则还谈不上详尽,用户应该根据特定的软件或评估环境来添加。
Metric和Category
完成快速评估过程后,重要的是要决定在后面的深入评估阶段需要哪些metric和category。 这里把开源软件的每一个可测量特性定义为一个metric,如:出版的关于该软件的书籍数量、交付的项目数量、测试行为的级别等。要创建一个标准化的BRR,把这些metric的原始数据规格化是很重要的,诸如软件包的下载数量这样的定量metric相对容易规格化,问题是定性的metric也需要规格化,这个过程会有一些主观性。
表1 软件评估的category划分(图)
按照不同兴趣来分组评估过程(即评估的category)也是很重要的,在表1中我们定义了评估软件的12种category。
这里把针对某一特定方面的软件评估定义为一个Category 等级。一个category等级是通过集合对同一方面测试的几个metric而得到的。在一个category中分级的计算方法可能与其他category的测量方法不同,但结果使用同样的标识数字(1~5)。
同样一个metric对几个category的贡献也不一样,例如,Fedora六个月的版本发布周期在“社区活跃性”方面象征一个很高的级别,但在稳定性方面却是一个较低的级别。
功能定位
在这个模型中,根据软件的使用需求,category 分级会赋予不同的重要性级别。使用需求可以从两方面获得:
1.组件类型
组件类型就是指完成相同功能的一组组件,如邮件传输代理(MTA)、web浏览器、办公套件等,用户可以相互交换一个类型中的组件而不会太影响功能。
2.设置的用途
不同的用途对软件有不同要求,以下是几种常见的软件组件用途。
关键任务用途:软件必须7×24运行,公司的商业依赖于它,或它是公司提供给客户的产品/系统的一部分,这些客户会依赖于它。
日常使用:软件在内部使用,对于软件升级等短暂的等待是可以接受的,不会对公司商业有主要的影响。
内部开发和/或ISV:开发团体经常评估开源软件是为了能够与内部系统集成供内部使用,或者是为了将其包含在为客户提供的一个产品或服务中,开发团体可能会修改系统代码,并期望对支持负责。
试验:研究软件并不是为了产品项目,这种例子包括企业对类似产品的研究、探测软件组成模块以学习其实现的细节等,当然这种研究的结果也可能导致该软件应用到上述领域。
一个软件包的组件类型(如作为一个Web浏览器或数据库)和用途设置(如开发和研究或关键任务架构)对其商业成熟度有非常重要的影响,这里把这些因素的综合定义的功能定位(functional orientation)。
尽管诸如文献、代码品质、接纳水平等领域的category等级可以给用户提供很容易理解的规格化和标准化数字,但这些数字针对不同的功能定位以及使用需求有不同的意义,一个开源软件组件对不同的应用也会有不同的商业就绪等级,也就是说,一个开源软件包可能对于公司内部的日常使用是商业就绪的,但它可能对于关键任务使用并没有商业就绪。
一个软件组件的BRR计算是根据其类型和用途,通过权衡一组category等级得到的,每一个功能定位也仅仅是关注有限数量的category 等级;软件功能定位的BRR也是基于选定的category等级计算出来的。
使用模型
快速评估阶段,以及根据软件功能定位的重要性排列metric和category,都是引导大家在模型的每一个评估阶段采取行动或步骤,来计算软件的BRR。BRR模型使用分四个阶段。
第一阶段:快速评估
——确定一个待评估的软件组件列表;
——根据快速评估标准权衡每一个组件;
——从列表上去除不符合用户需求的组件。
第二阶段:目标使用评估
Category权衡
——根据重要性把12个category排序(1代表重要性最高,12代表最低);
——针对某一软件组件,取前7项或更少的category,分别给每一项打一个百分数,总共为100%。
Metric权衡
——对于一个category中的每一个metric,按照对商业就绪的重要性排序;
——对于一个category中的每一个metric,给予一个表示重要性的百分数,一个category中的所有metric总分为100%。
第三阶段:数据收集和处理
——收集在各个category 等级中使用的每一个metric数据,计算每一个metric的应用权衡值。
第四阶段:数据转换
——使用category 等级和功能定位权衡值来计算BRR得分;
——发布该软件的BRR得分。
总 结
提议创建BRR模型的目的是为软件评估提供一个可信的、开放框架,这个模型旨在通过系统方法加速软件评估过程,方便IT管理者相互交换信息以达成更好的抉择,并增加高品质开源软件在应用中的信心。
BRR模型是开放的和可定制的,因此它可以用于任何商业情形,它甚至可以用于以标准化的方法评估专有软件(只需调整某些评估标准即可)。它也足够完整,允许不同企业或组织的IT人员设立他们自己的评估标准,并执行完整的评估。通过使模型开放,也是希望确保其未来的演化和改进,并增进其广泛采用。像其他开源系统一样,BRR模型也会随着用户基础的扩大而改进。
总之,所有的目标是通过为开源软件包的可计量数据提供中立的交换分享场所,促进它们的应用和发展,从而最终使开源社区受益。在[url]http://www.openbrr.org[/url]网站上,还提供了BRR的指南、论坛、示例、标准模板以及工作表等。