随着协同技术发展以及基于Web2.0的虚拟群体交互技术的出现, 以开源软件、维基百科、社会化标签为代表的协同内容创建成为重要的信息资源创建模式^[1]。开源软件开发由群体协同完成, 具有节约成本、发挥集体智慧等优势, 也有团队开发所没有的自组织、社会化等特点, 传统管理方法已经不能有效应用于群体开发过程管理。同时, 由于开源软件项目的绩效贡献是社会化协同模式下群体贡献汇集的结果, 影响因素很多, 目前还未取得成熟的理论成果。因此, 探索开发人员协同开发行为特征对开源项目成功的影响, 无论对开源开发的绩效理论还是对开源开发过程管理实践, 都具有重要意义。

开源软件开发是建立在基于互联网的特定开发平台上的复杂社会技术活动。目前流行的面向开源及私有软件项目的托管平台GitHub, 是使用Git分布式版本控制系统, 提供Bug跟踪器、Wiki及社会网络等及时沟通工具的开发环境^[2]。GitHub在Git的基础上, 开创了一种围绕Pull-Request(合并请求)的分布式协同开发模式, GitHub社群通过社会编码、社会评价、审阅人推荐等机制影响协同轨迹和效率。

目前还没有被广泛接受的衡量开源开发绩效的指标。有学者提出利用项目成果的技术质量指标衡量开发业绩, 如: 代码缺陷密度(每千行代码中的缺陷数)、对用户问题报告的响应时间^[3]、错误解决率^[4]等; 也有学者用项目协同开发的过程指标衡量开发绩效, 如: 项目生存时间、活动水平、分工^[5], 贡献者的增长、社区的参与和可见的活动等^[6]。但是过程与结果是相互影响的, 这种相互作用关系给绩效测度指标的选择带来了困难。

(1) 开发人员个人对最终项目成果的直接贡献行为。代码提交和文件修改是开发人员对软件的直接贡献行为。开源平台能获取到的开发人员直接贡献行为数据主要有代码提交数据、邮件列表数据、漏洞追踪数据, 这些数据成为研究开发者协同开发行为特征的基础^[7,8]。

(2) 开发人员个人对最终项目成果的间接贡献行为。在社群协同开发中, 点赞、复刻、追踪、提交、评价等是对最终成果有间接影响的行为, 这些行为间具有相互影响的作用^[9]。

(3) 集体层面的协同活动。Kalliamvakou等的研究发现, 基于GitHub平台的项目利用分支工作流来增强工作独立性, 利用活动可见性来减少通信和协调, 通过自组织来分配任务和解决冲突^[10]。Dabbish等将项目管理、互动学习和声誉管理等高层次的协作活动归因于GitHub中基于开放软件存储库的透明性和社会化编码^[9]。开源软件的评审也是集体层面的协同活动, 体现在所有开发人员的成果都必须让至少两个审阅者检查更改才能提交, 虚拟社区也参与评审^[11]。

Kane认为, 协同内容创建的多人协同模式有助于提升成果质量, 参与者越多, 效果越好^[12]。有学者研究发现少数核心开发人员贡献了大部分代码, 而其余的人则只通过报告Bug偶尔做出贡献^[13]。Dinh-Trong等在对FreeBSD的研究中曾提出假设“拥有一个强大的由开发人员构成的核心、却没有在此基础上拥有大量贡献者的开源软件开发, 虽然可以创建新的功能, 但却会因为缺失发现和修复缺陷的资源而失败。”, 因为研究中的FreeBSD项目确实有很多贡献者, 该假设没有被评估^[14]。余跃从项目构建程度、技术特点、社交属性、项目管理以及持续集成这5个集体行为方面, 量化分析了贡献汇聚的处理结果与效率^[15]。可见, 目前开源软件开发绩效贡献的研究还有很多需要检验的假设, 也少见到研究开发者协同提交、修改行为特征对绩效的贡献的文献。

综上所述, 开源软件协同开发是建立在特定群体交互技术基础上的复杂社会技术活动, 协同开发环境提供的社会化协同模式、社群及个人行为都可能对项目绩效有贡献, 这给从理论层面上研究协同开发绩效影响因素机理带来很大困难。因此, 本文采取数据驱动的方法探测对项目成功有影响的协同开发行为特征。

作为主流开源服务器, Apache有独立的门户社区, 积累了海量的优质代码、精品项目和子项目。截至2018年3月29日, Apache软件基金会(Apache Software Foundation, ASF)官网显示, ASF管理和孵化了涵盖广泛技术的350个开源软件项目, 包括大数据、网络服务器、XML、Web框架、网络客户端、数据库等领域。因此, 选择GitHub上的Apache软件基金会项目作为研究对象具有很好的代表性。本文采集Apache软件基金会项目数据, 探测协同提交、修改等行为特征对项目成功的影响, 为进一步的理论研究和管理实践提供参考。

在云服务器上运行Shell Script脚本调用GitHub接口/repos/:owner/:repo/commits, 获取213个Apache软件基金会项目(截至2018年2月24日)的1 109 050条代码提交基础数据。用Java代码对获取到的数据进行处理, 得到提交基础数据如表1所示, 每条记录对应一次提交, 由散列值唯一标记, 其他字段分别对应修改者信息、提交者信息、修改提交时间等信息。

通过SQL语句以及中间统计表, 从提交基础数据表中取出每个项目的核心成员占比(提交者占修改提交者总人数的比例)、核心成员提交次数占比(提交者修改代码次数占总代码修改次数的比例)、代码提交频率(平均每日提交代码次数)、平均提交修改时间差(提交时间与修改时间间隔的平均值)等特征指标。

需要通过接口获取1 109 050条代码提交基础数据的详情信息, 因此使用云服务器多线程不间断采集。通过代码提交基础数据中每次提交记录的唯一散列值, 调用GitHub接口/repos/:owner/:repo/commits/: sha获取特定组织(owner)下特定项目(repository)的具体一次(sha)代码提交的详情JSON数据。

单次提交详情数据中除了包含代码修改者和提交者等基础信息外, 还包含该次提交修改的所有文件信息, 如每个被修改文件的散列值、文件名、增加删除行数等。通过Java代码, 将获取到的原始单次提交详情JSON数据中每次提交的每个文件被修改的信息抽取出来, 存放到MySQL文件修改详情表中, 得到213个项目共7 373 543条记录的文件修改详情表, 每个记录包含的字段如表2所示。文件改动状态共有4种: 新增、修改、删除、重命名, 而文件散列值唯一标记一个文件。

通过SQL语句以及中间统计表, 从文件修改详情表中计算得到每个项目的平均修改文件数(每次代码提交平均改动文件的数量)、文件平均修改行数(每次代码提交被修改的文件中平均改动的行数)、文件平均修改次数(代码提交中改动的文件平均被修改的次数)、修改文件占比(修改状态的文件占所有4种改动状态文件的比例)、删除文件占比(删除状态的文件占所有4种改动状态文件的比例)等特征指标。

Crowston等认为成功具有多维度, 需要从多角度评估^[16]。Grewal等亦指出单独衡量开源项目在技术或市场哪一个方面的成就都是不完整的^[17]。这与Rai等^[18]有关软件成功和Mansfield等^[19]新产品开发成功的文献观点一致, 后续的许多研究者^[20,21,22]都采用技术成功与商业成功衡量开源项目的成功。

Apache内部通过认证机制将项目分为“顶级项目”和“孵化器项目”, 可以视为技术质量等级的划分。孵化器是开源项目成为完全成熟的顶级项目的途径, 在孵化期间的项目将采用Apache流程和框架来发展和培养项目的社区并规范代码风格(标签与空间)等, 这些都会影响到项目能否毕业成为顶级项目或者顶级项目的子项目。

因此, 本文也采纳从技术和市场两方面衡量项目成功的观点。一方面根据Apache软件基金会内部的认证, 看目标项目属于孵化器项目还是顶级项目, 判断其技术成功; 另一方面通过GitHub社群用户对目标项目喜爱程度的有关数据测度项目的商业成功。

GitHub平台上能获取到的用户对项目喜爱程度的有关数据包含订阅数、点赞数、复刻数等。通过GitHub接口/repos/:owner/:repo得到项目基本信息JSON数据, 从中提取出各项目订阅数、点赞数和复刻数。将213个项目的订阅、点赞和复刻总数按升序排列之后生成散点图, 如图1所示。可以发现研究项目的订阅、点赞、复刻总数, 从小到大排序后并不呈现线性增长, 而是类似于指数增长的趋势。将订阅、点赞和复刻之和按0-99, 100-999, 1000-9999, 10000以上划分为4个级别, 分别对应1-4级商业成功。213个 项目属于这4个级别的个数为60、97、51、5, 除了 5个遥遥领先的明星项目外, 其余项目在商业成功各区间的分布比较均匀。

分别统计孵化器与顶级项目的以下协同开发行为特征指标: 核心成员占比、核心成员修改次数占比、代码提交频率(次/日)、平均提交修改时间差(小时)、提交平均修改文件数、文件平均修改行数、文件平均修改次数、修改文件占比, 并进行对比分析, 如图2所示。

顶级项目的“核心成员占比”、“核心成员修改次数占比”、“修改文件占比”和“代码提交频率”的平均值、中位数、最大值均大于等于孵化器项目; 而“平均提交修改时间差”和“文件平均修改次数”的平均值、中位数、最大值均小于等于孵化器项目。可以初步推测, 这些协同开发行为特征很可能对项目的成功产生影响。

在开源软件协同开发行为特征对成功的影响回归分析前需要考虑其他影响因素。Midha等提出开源软件成功影响因素综合模型^[21]如表3所示, 该研究涵盖了当前大部分开源软件成功影响因素研究中的控制变量。

除了Midha等的模型中对开源软件技术成功和商业成功产生影响的因素, 众多研究者也将“项目年龄”作为开源软件成功影响因素研究中的控制变量, Yang等认为一个开源软件的平均投入时间是衡量一个其知识工作者(即开发人员)资本的重要指标^[22]。

综上所述, 选择“开发者总数”、“总代码行数”、“项目年龄”作为项目技术成功影响研究的控制变量; 选择“开发者总数”、“项目年龄”作为项目商业成功影响研究的控制变量, 其中“项目年龄”采用从项目第一次提交代码的时间到本文研究数据获取的截止时间2018年2月24日, 以此表示项目中开发人员投入时间。

对孵化器与顶级项目的协同开发行为特征进行对比分析发现: “核心成员占比”、“核心成员修改次数占比”、“代码提交频率”、“修改文件占比”、“平均提交修改时间差”、“文件平均修改次数”可能对项目的成功产生影响, 因此, 本文将这些特征值与项目技术、商业成功的测度值做相关性分析(因篇幅限制, 计算结果省略)。

根据相关研究经验, 如果各自变量之间相关系数小于0.65, 说明自变量之间不存在显著相关性, 各自变量之间就不存在共线性问题。双侧相关检验结果中, 除了“核心成员占比”与“核心成员修改次数占比”的相关系数为0.751, 其余自变量之间的相关系数都远小于0.65。说明“核心成员修改次数占比”会受到“核心成员占比”的影响。所以, 在这两者中选择“核心成员占比”作为对项目成功回归分析的自变量, 以消除自变量共线性问题。

因变量——项目技术成功只有两种情况: 孵化器项目对应技术不成功, 顶级项目对应技术成功, 所以采用二元逻辑回归进行分析。设孵化器项目为类别0, 顶级项目为类别1。二元逻辑回归分析的变量如表4所示。在变量筛选的方法中选择前向的最大似然法并将控制变量作为第一批解释变量加入回归分析, 分析结果表明拟合程度较好。

最终拟合结果如表5所示, 最终方程的变量中除了控制变量“开发者总数”、“总代码行数”、“项目年龄”之外, 协同开发行为特征变量中“核心成员占比”的Sig.值<0.01, “代码提交频率”和“文件平均修改次数”的Sig.值<0.05, 说明这三个自变量具有统计学意义。

EXP(B)(优势比)结果显示:

(1) “核心成员占比”每增加一个单位, 项目是顶级的发生比是之前的0.037倍;

(2) “代码提交频率”每提高一个单位, 项目是顶级的发生比是之前的1.427倍;

(3) “文件平均修改次数”每提高一个单位, 项目是顶级的发生比是之前的0.327倍。

这说明“代码提交频率”正向影响项目技术成功, “核心成员占比”、“文件平均修改次数”负向影响项目技术成功, 且“核心成员占比”对项目技术成功影响最大。

因为衡量项目商业成功的指标是连续型的数值(1-4级商业成功), 所以通过线性回归分析项目的开发者协同行为特征指标对商业成功的影响, 线性回归分析的变量如表6所示。

回归方程自变量筛选方法有进入法和逐步法。影响开源项目商业成功的因素很多, 本文的目的不是构建影响开源项目商业成功的模型来验证模型和预测开源项目的商业成功, 而是从开发者协同开发行为特征角度找出可能对项目成功产生影响的因素, 因此选择逐步法进行线性回归分析并将控制变量作为第一批解释变量加入回归分析, 分析结果表明拟合优度较好。

参数检验如表7所示, 列出了自变量的显著性检验结果(使用单样本T检验), 其中, Sig.列为T检验的Sig, 值均小于0.01, 说明除了控制变量外, 自变量“核心成员占比”、“修改文件占比”和“文件平均修改次数”对因变量商业成功具有显著影响。

共线性统计结果显示核心成员比例和总删除代码行数的容差均大于0.1, VIF值均小于10, 所以三个变量之间不存在共线性的问题。

B表示各个自变量在回归方程中的系数, 但是由于每个自变量的量纲和取值范围不同, 基于B并不能反映各个自变量对因变量影响程度的大小, 需要借助标准系数。表格中的“试用版”代表Beta, 此时数值越大表示对自变量的影响更大, 负值表示对因变量有显著的负向影响。

“核心成员占比”的标准系数为-0.426, 说明“核心成员占比”对项目商业成功产生负向影响; “修改文件占比”的标准系数为0.221, “文件平均修改次数”的标准系数为0.195, “修改文件占比”和“文件平均修改次数”都对项目商业成功产生正向影响, “核心成员占比”对项目商业成功的影响更大。

对开发者协同开发行为特征与项目技术成功、商业成功分别进行二元逻辑回归分析和线性回归分析, 在屏蔽“开发者总数”、“总代码行数”和“项目年龄”对项目成功的影响下, 得到具体特征对项目的影响如图3所示(+表示正向影响, -表示负向影响)。

(1) “核心成员占比”对项目技术成功和商业成功均产生负向影响, 且影响强度最大。说明项目技术成功和商业成功都要求高水平的核心人员数量少, 外围参与人员基数大。开源软件项目可以增强社区建设, 利用GitHub的开放性和低门槛, 吸引更多的普通开发人员参与项目协同开发, 严格审核核心开发者资质, 控制核心开发人员的规模, 求精不求多。

(2) “代码提交频率”正向影响项目技术成功。符合已有文献的研究结论, 代码提交频率快, 版本更新快, 解决问题的速度快, 项目活跃度高, 会有更多的用户下载软件, 就可能会有更多的开发者加入项目并做出贡献, 更容易达到高的技术质量标准。应鼓励社群积极参与并持续提交代码。

(3) “文件平均修改次数”负向影响项目技术成功, 正向影响项目商业成功。说明文件修改频次对开发成功的影响具有双面性, 一方面, 表明项目中代码问题多, 开发者不能一次性解决代码文件的问题, 是技术水平不高的体现; 另一方面表明项目的用户关注度高、参与度高, 是商业成功的反映。管理者应对导致这种行 为特征的原因进行深入调查, 提高文件单次修改的质量。

(4) “修改文件占比”正向影响项目的商业成功。修改文件数量大也是用户关注和参与度高的表示, 因此正向影响商业成功。

本文基于Git版本控制系统代码的提交数据, 对GitHub代码托管平台上的213个Apache软件基金会项目的开发人员协同开发行为特征进行研究, 发现开发人员协同开发行为特征“代码提交频率”、“核心成员占比”、“文件平均修次数”、“修改文件占比”对项目的成功有影响。

本文还存在以下不足: 研究的孵化器项目只有46个, 少于顶级项目数(167个), 所以技术不成功的项目样本数量偏少; 没有对5个订阅、点赞、复刻总数超过一万的明星项目进行深入研究; 只考虑开发者总数、总代码行数、项目年龄这几个控制变量, 但是项目所在领域、版本发布等因素也可能对项目的成功产生影响。未来研究需要在增加项目样本数量的同时, 对典型的成功、失败项目进行深入研究并考虑更多控制变量的影响。

(致谢: 图书情报国家级实验教学示范中心(武汉大学)为本次研究提供了场地的支持, 在此表示衷心的感谢!)