数字图书馆开源软件评价模型比较研究

[摘要]　对数字图书馆开源软件评价模型进行分析，选取两种较为典型的数字图书馆开源软件评价模型的通用部分进行比较，并分析其优缺点，最后结合国情及数字图书馆建设需要提出一些具有建设性的对策。

[关键词]　数字图书馆开源软件评价模型

[分类号]　G250.76

1　前言

开源运动在国内正在逐渐兴起，开源软件(opensource software，OSS)在数字图书馆领域已被广泛应用，其中DSpace、CDSware、Fedora、Eprints、Mylibrary等开源软件更是深入人心。中国科学院国家科学图书馆兰州分馆采用Dspace构建了甘肃青海特有少数民族数字资源保存与服务系统，其他使用Dspace系统进行二次开发的图书馆及相关机构还包括：北京航空航天大学、中国西部环境及生态数据中心、中国国家图书馆、厦门大学、浙江大学、香港城市大学、香港科技大学图书馆、香港大学等。清华大学利用Fedora进行了数学数字图书馆、机械史数字图书馆系统平台的构建。总之，开源软件在国内的实践应用日益广泛。

开源运动在图书馆领域的不断深入促使业界人士不断思考，如何才能更好地推动开源运动在图书馆领域的健康发展?如何才能使开源软件更好地为数字图书馆建设服务?虽然，开源软件与传统商业专有软件的运作模式完全不同，但回溯商业专有软件的发展历程，亦能获得规范开源软件发展的重要经验。如今，各种商业软件标准琳琅满目，各种功能指南各显其能，相关评价模型和机构更是遍地开花。这种百家争鸣的激流，激荡出的是矫健而蓬勃的商业专有软件群。事实证明，软件的评价与规范化不但不会阻碍软件发展的步伐，反而会更好地促进软件的进步。随着信息时代的到来，软件的评价工作已经成为人类活动的重要组成部分。

2　开源软件评价模型及优劣势分析

近年来，开源软件质量分析逐渐成为热点，其主要原因是大型代码库的广泛使用。在学界更是出现了大量的关于(半)自动代码分析、邮件列表、Bug跟踪、版本系统等相关方面的研究文献。

作者发现，当今数字图书馆开源软件的评价研究不仅仅拘泥于源代码的分析，更多的是致力于开源项目评价模型的创建与应用，其主要目的在于支持开源软件的潜在用户。其中最突出的例子就是Qsos(qual.ification and selection of open source software)、OMM(opensource maturity model)、0penBRR(Open busi―ness readiness rating)以及OSMM(Open source maturi.ty model)。OpenBRR是基于OSMM创建的，因此在文中笔者不会深入介绍OSMM，而只对OpenBRR和QSOS进行比较研究。OpenBRR和QSOS都定义了一个多层次的评价类别，并规定了对子类别进行评价的步骤。其最后的结果通过各子类别加权后所得分数的平均数累加而成。

2.1　QSOS

Osos的评价模型主要由两部分组成：通用部分(可以对所有软件进行评估)和特殊部分(根据软件产品系列的不同而制定的预期功能列表，诸如：群发邮件系统、内容管理系统、数据库、领域专业等)。由于图书馆可用的开源软件较多，因此在本文中作者将讨论的重点集中在通用部分，致力于通用质量性能研究，以确保研究具有更宽广的借鉴意义。QsOs评价模型通用部分的简要树层结构，如图1所示：

2.2　OpenBRR

OpenBRR的层次结构元素被定义为度量级，例如，在质量类别下笔者发现“在过去12个月内进行了多次较小的修正”。然而，OpenBRR所使用的度量可以被概括为质量属性。OpenBRR通用部分一如QSOs，可移植性及重用性获得了最大程度支持，因此对于图书馆开源软件评价者而言，适当的本地化是必须的，见图2。OpenBRR评价程序样例见表2。

2.3　QSOS与OpenBRR的比较

2.3.1　整体比较　两个评价模型的相似之处：①每个模型都提出了一个评价开源项目的预定义标准，并对评价进行了分级设置，OpenBRR为二级评价树层结构，Qsos为三级评价树层结构。②两种评价方法都是基于标准的评分程序。在对开源项目进行评价过程中，正是通过该程序将分数分配于每个类别。③用户可根据评价内容不同对每个评价项目的评分权重进行设定。特别是在评价中，许多绝对分数的衡量是基于当前评价内容的重要性，这里所指的绝对分数为加权得分。④可以通过最后产生的相对分数支持决策。⑤每个模型都是基于通用性考量进行设计的，因此较为适合进行数字图书馆开源软件的评价。

Qsos认为在实施评分程序时必然会获取绝对分数。因此，对特定版本的开源项目的评分程序只能进行一次，如果感觉评分并不客观，评价者可以对结果进行讨论，只有达成合议时开源项目被给予的绝对分数才能被取信。因此，调整最终评价结果的唯一方法是修改评价标准的权重分配。

QSOS与OpenBRR在应用程序与重用策略上有所不同，Qsos具有不断完善的开源产品评价库，而OpenBRR则没有。但其中更重要的问题是QsOs中的评分类别是否能普遍化，至少是部分普遍化，藉此中间分数(如QsOs的绝对分数)可以被重复使用和分享。

首先，QSOS可以采用这种策略，因为QSOS的评分程序只允许三个评分等级0、1和2。因此，不同评价者所获得的差异性分数降低了。其次，作者认为提供一个适合所有要求的评分程序并不现实。虽然，QsOs允许对评分程序进行编辑，但是在实践中未有尝试。最后，QSOS认为对基于特定版本的开源产品的评价范围进行定义并不值当，而OpenBRR却恰恰相反。笔者赞同OpenBRR的规范，因为OpenBRR暂时保留了这一接口，当被评价项目为特定版本的特殊开源产品或全产品时再行使用。保留的这一接口可为用户实现以下功能：当实施评分程序时需要清晰的定义数据设置范围，该范围不可包括其他版本及相关数据，在某些案例中，达到这一效果并不容易。例如，论坛帖子的数量或出版图书的数量类别并不适合特定版本软件的评价。

2.3.2　评分程序的比较

两个模型都通过评分程序将原始数据转换为分数并分配给各个评价类别。下面笔者将比较两个模型的评分程序，特别是评分范围、评分程序的清晰度及歧义以及数据的可用性。

评分范围。QSOS评分程序的分值分配为3个级别(O一2)。但是，这种分配方式过于严格，而无法全面获取信息。笔者认为，评分范围分为4个级别较为合适。QSOS的三级评分范围，其中间分数有可能带有积极或消极的倾向。

OpenBRR评分程序分值范围为1―5。其中1和2级为消极分数，而4和5为积极分数，3为中立分数。笔

者发现，在28个类别中的14个类别并没有使用到全部的5个评分级别。在13个案例中，5个级别中的3个级别被使用，特别是级别1、3和5使用频度高于级别2和4，在其余的案例中：级别1、3、4和5使用最为广泛。在超过一半的评价项目中，OpenBRR评价程序并没有QSOS的三级评价标准效果好。

评分程序的清晰度及歧义。两个评分程序都缺乏准确的评分规则。笔者认为，这两个模型的评分规则措辞含糊不清，其中言辞不同人亦有不同的理解。即使确定了评分程序中相关描述与实际的差异，但仍然有许多情况会导致难以获得符合实际情况的分数。笔者分析后获得如下结果：

Qsos包含41个评价类别，其中22个评价类别存在措辞含糊不清的情况。这22个评价类别如下：稳定性、叉概率、普及率、参考文献、贡献社区、管理风格、纠错活动、功能、、培训、支持、咨询、文档提供、质保工具、人机工程、管理与监控、模块化、代码修改、专业级源代码修改、源代码质量、内在的复杂性、技术文档。

OpenBRR具有28个评价类别。在大多数情况下，评价类别应该具有更为具体的含义以保证评分规则更为准确。然而，作者发现其中7个言辞歧义的例子：终端用户的uI体验、是否具有专门的安全信息、性能测试及基准测试、性能调整与配置、可扩展性设计、专业支持的质量以及是否难以进入核心开发团队。

在前文中笔者已经浅论软件产品及其组件评分范围的适用性问题，然而，在此问题上应该给予更多的重视。OpenBRR认为一个类别不可能适应所有的情况，应该允许评价者根据自己的情况作适当的调整。另一方面，QSOS旨在提供评分规则以便计算分数，因此，QSOS提出的通用规则更为实用。实际上含糊其辞的规则通用性更强，这也许就是QSOS近半数规则含糊其辞的原因。此外，Qsos能够通过其规则获得一定程度的通用性，而4或5级评分范围很难获得如此的通用性；同时也如同前文所论，三级评分规则很难有助于决策。

数据可用性。除了明确的规则，确保数据需求的可用性也是很重要的，否则数据的缺乏会威胁到模型的适用性。在确定某些数据不可用时，意味着数据真的很难获取，但也可能意味着没有现成的数据。也就是说，原始数据不可获取或使用，若要获取和使用需要在社区论坛上贴子征集，因此数据的获取情况将取决于社区成员的友好程度及成员是否知晓正确的数据答案。对Qsos进行分析后，笔者发现不可能从以下5个评分类别中获取数据：历史／已知问题、叉概率、管理风格、开发识别／turrnover、发展的独立性。

对OpenBRR进行分析后，笔者发现9个评价类别所需数据不可获取：时间设置的先决条件、vanilla安装／配置时间、过去6个月的安全漏洞数量、仍然开放的安全漏洞、性能测试及时间基准测试、性能调整及配置、参考部署、可扩展性设计、进入开放团队的难度。

2.3.3　评价标准的重合范围及措辞的质量本部分并不是对类别本身的言辞语义进行比较，而是对评分规则的语义进行比较。比较后发现QSOS中的16个评价类别OpenBRR中未见。以下7个评价类别Open―BRR有而QSOS中未见：终端用户uI体验、安装开源软件所需先决时间、安全相关的3个类别、参考部署、用户贡献框架。另外，在OpenBRR中快速评估步骤中的5个类别Qsos中未见：标准符合程度、可用的支持或稳定的组织、实现语言、第三方审查及行业分析。

除了重合范围分析，笔者还对两个模型树形评价类别更高节点中所涉及的言语进行了研究，发现Qsos使用的术语非常适宜树层结构中更高级别的节点。但是，其子类别往往使用非常不准确的言语进行概括，这使得关于评分类别的调研演变为对类别正确意思的理解。因此，笔者认为评分类别的描述语言应该简短而准确，这会使Qsos中很多类别简化为一个类别。

OpenBRR与Qsos的情况截然相反。虽然，有时0penBRR的评分类别描述相当冗长，但其措辞比较准确。因此，许多类别可以改写得更为简洁而不会降低措辞的准确性。然而，在评价类别树层结构的顶层节点中，其使用的属性往往非常宽泛且不准确。例如，质量(quality)比稳定性(stability)和可靠性(reliablity)更为宽泛而不准确。

2.3.4　Qsos与OpenBRR的优缺点　Qsos和0pen―BRR皆着重考量了产品本身(比如：代码、文档)的效率，并且特别重视社区的作用；然而，从整体角度分析，这两个模型只具备了初步的过程结构。例如，Qsos包含了两个过程标准：QA过程(与评估级别无关、非正式的、由工具支持)、错误／功能需求工具(与评估级别无关、标准工具、积极利用的工具)。换句话说，现有的开源评价模型没有考虑到软件的成熟过程。此外，两个模型都定义了各自的类别和量度，但是并没有指定相应的目的或基本测量的目标，而且它们并没有将社区与产品分为两个部分进行评价。因此，这些模型难以说明使用这些类别和量度的依据以及定义软件完整性的根据。除了上述内容外，这两个模型都不需要评价人员获取原始数据的来源，因此，使用这些模型进行评估的可再用性较低。虽然，两个模型都提供了非通用性的可扩展接口，但是通用部分过于泛泛，因此其可移植性较差，图书馆开源软件评价者在使用之前依然需要结合实际的需求进行评价类别及权重的重置，从而获得更可靠的结果。Qsos与OpenBRR的优缺点如表3所示：

3　如何建立适合中国图书馆现状的评价模型

中国图书馆界在该领域还未有深入研究，国内相关研究文献不多，且多停留在评价方法的探讨、宏观策略的分析、关键因素的分析、较小范围的讨论等方面，整体来说缺乏全面、细致的深入研究。由此可见相关研究仍处于初级阶段，但是开源之大趋势不可逆转，况且评价标准的形成与规范化定然会促进开源软件在图书馆界的健康成长。在对Qsos和OpenBRR这两种评价模型进行比较后笔者认为，评价模型设计目的必须着重强调对开源软件项目的质量进行评价，整个模型必须非常注重项目进化性和健壮性的评价。评价者必须先人为主地定性软件产品的质量不仅与产品本身有关(代码、文档)，而且与产品的开发、运作及推广的方式息息相关。基于上述原因，加之开源产品的开发又属于开源社区的责任，因此评价模型应将产品和社区相关的问题视为同等重要的评价内容，并着力于使之平衡。

评价模型应该由三类相互联系的元素组成：质量类别、量度和指标。质量类别需要对应于具体的产品和社区，这两项内容也是评价工作中的重点。量度应与能够具体化的部分密切联系，通过多部分的协同工作才可以对一个产品或社区的相关情况进行评价，该部分与质量类别评价目标必须是一致的。最后，通过制定的指标来确定如何汇总和评估评价后获得的结果。通过上述方法，决策者就可以很容易地获得一个

综合性的结果。除此之外，针对图书馆开源软件的评价模型必须具备相应的评价类别与考量。具体来说，应该着重从5个部分进行评价模型的建设：

3.1　产品

开源软件是基于开放理念及社区进行构建的，与传统商业专有软件的开发方式、运行模式都有很大的区别。这种新型的开源软件开发模式可以确保开源软件持久及连续的健壮性，开源产品与类似功能的商业专有软件本身也存在很大的差别。因此，应该采用更为规范的标准(例如：Is09126)制定评价模型对开源软件产品进行评价。在进行评价的时候应该尽量使用开源软件的源代码，因为源代码开放是开源软件优于传统商业专有软件的最大特点，代码的评价同时也会推动开源软件代码测评技术在开源软件评价领域的进一步发展。但是，在实际的评价模型制定过程中，一定要注重代码的选择，有效代码能够更好地为评价者呈现软件的性能，但无效代码只会混淆视听，让评价者制定错误的类别与指标。虽然从概况上分析，QSOS和OpenBRR这两种评价模型的通用性比较适合对图书馆开源软件进行评价，但是图书馆领域内对于开源软件的需求仍然具有一定的独特性，因此在评价模型中应该更多地考虑到图书馆因素。笔者认为与产品相关的类别应包括：可维护性、可靠性、可转换性、可操作性、界面友好性、功能稳定性、安全性、兼容性等。

3.2　社区

社区的开发与建设是另一个可用来区分开源软件与商业专有软件的重要特点。社区中的开发者往往是无偿自愿加入社区的，因此社区并不具备严格的组织与管理结构。邮件列表、论坛、版本管理库、Bug溯源系统等多种形式的辅助支援机制是开源软件健康发展的关键。图书馆与开源软件在理念上具有一定的共通性，Jeremy Fmmkin曾经说过“图书馆与OSS的在本质上是相融(naura]fit)的。两者都要通过信息的传播来促进知识的学习和理解”，因此社区的评价不但应该视为开源软件的重要特性，同时应该作为图书馆发展的重要支撑。而开源软件对于社区的高度依赖使得评价者在进行评价模型制定时必须考虑社区的因素，在评价类别中要详细地制定对应的条目，准确地定义评测的等级及等级描述。否则，缺乏严谨社区评价类别的模型所呈现的开源软件的准确性与真实性必将大大折扣。与社区相关的评价类别应包括：维护能力、持续发展力、成熟度过程、社区的稳定性(基于图书馆馆员)等。

3.3　成熟度过程评测

对开源社区进行评价，不但可以判断哪些实践有利于开源软件的建设，同时也可以为未来的实践工作奠定坚实的基础。现有的评价模型(如：SMMI－DEVL和SPICE)并不能直接对开源软件进行评价，因为其中包含了众多与公司或其他组织相关的类别，进而忽视了社区的重要性。除此之外，绝大多数的评价模型并没有关于程序约束方面的内容，作为开源软件而言，评价者一定要了解社区管理与约束的重要性，而且要特别考虑到数字图书馆的因素。笔者认为，与成熟度相关的类别应包括：版本的配置与管理、与推广管理、需求分析等。

3.4　聚合与释义

开源软件评价模型创建的一个主要目的是为潜在的图书馆开源用户提供开源软件选择建议，同时也可以为软件开发者提供指导及反馈。因此，在进行软件和项目的评价过程中，当面对原始数据时，评价者需要将评价模型框架的质量类别和度量标准结构层次化。从而，评价者可以获得更准确的质量评价结果，但这一切都需要从底层原始数据的分析、解释和搜集开始，其工作的主要内容就是将纷繁的数据明确化、简约化，让普通的用户更易于理解，针对图书馆的领域特点使其更加贴合专业特征。为了达到目标，评价者应该通过多领域专家评估的方式对释义和聚合规则进行定义，如果数据充分，专家应该通过分析这些数据定义聚合的规则。在对众多的模型的制定过程进行分析后笔者发现，在一般的情况下，原始数据的数量和质量是能够满足专家分析需求的。

3.5　本地化

不论是OpenBRR还是QSOS，其开发的起点一般都是基于通用性的考量，植根于国外发达国家的商业模式、开发习惯、用户需求及图书馆现状，因此当在国内进行应用时必须进行一定的本地化。虽然本文只对两种模型的通用部分进行了讨论、比较与分析，但笔者在对其扩展部分的分析中发现，该两种模型欠缺符合国内数字图书馆开源软件特性的评价类别与相关因素的构建。当国内评价者应用此类模型进行开源软件的评价时，必须根据本地特有的情况进行改良。

4　结论

软件虽然不是图书馆中最为重要的研究内容，但是在当今数字信息环境下缺少了软件的数字图书馆根本无法运作。因此，随着时代的变迁，数字图书馆相关软件的作用越来越重要。数字图书馆开源软件的评价工作是非常复杂的，其中所涉及的领域也是广泛的，因此在评价模型的制定过程中，评价者必须考虑多方面的内容，完善评价的类别与量度，特别是在国内数字图书馆专业性开源软件的评价模型研究尚未完全开展的前提下，更需要借鉴国外及其他领域的经验，结合国内数字图书馆建设的实际情况，促进数字图书馆开源软件评价研究的进一步深入。开源软件在图书馆领域的迅速推广要求更多、更好的评价方法和模型的出现，性能优良的评价模型也必将促进开源软件在数字图书馆建设中发挥更大的作用。

参考文献：

[1]Hebert E. How open source software can improve our library. [2010―06―221. lattp://www, degreetutor, com/library/managing-ex-penses/open-source-library.