英国生态学家Tansley[1]于1935年首先提出有关“生态系统”的概念,任何自然环境中的生物有机体和非生物成分在一段时间内交互形成一个相对稳定的动态平衡状态,这就是一个生态系统[2].作为一个没有固定规模的开放系统,生态系统是生态学中的主要结构和功能单元.类似地,软件生态系统也可以被视为软件工程领域的主要结构和功能单元[3-4].软件生态系统是指在一个共同的技术平台上,众多的参与者协同合作,最终形成大量的软件解决方案或服务[5-6].经研究,软件生态系统目前是在软件平台上结合内部和外部参与者开发的组件来构建大型软件系统的有效方法[7].
随着开源软件开发平台的快速发展,可用的开源软件项目数量急剧增加,因此软件系统不再孤立存在,而是存在于托管平台上的不同软件生态系统中.因此,自2005年Messerschmitt等人的工作[8]以来,对软件生态系统的研究已成为一个热门的研究领域.不同的研究为软件生态系统提供了不同的定义.例如Bosch等人给出软件生态系统的定义,讨论其发展趋势,并概述采用软件生态系统方法的关键概念和意义[7].Lungu等人将软件生态系统视为在同一环境中共同开发和发展的软件项目的集合[9].目前,还有许多研究都聚焦于特定的生态系统,例如Arm软件生态系统[10]、Python软件生态系统[11]、JavaScript包生态系统[12]和R统计计算开源生态系统[13]等.
演化过程是包括软件生态系统在内的所有生态系统的基本过程.个体参与者的动机或他们之间的交互行为可以导致演化过程[14].软件生态系统的演化引起了研究人员的极大兴趣[15-16].然而,迄今为止,还没有大规模的关于软件生态系统演化的研究.此外,与不同演化事件有关的因素还未确定.因此,本文回答了3个研究问题:
1) 如何识别GitHub中不断演化的软件生态系统?
2) GitHub软件生态系统中主要存在哪几种演化事件类型?
3) 哪些因素与软件生态系统的长期存活密切相关?
本文选择GitHub中的软件生态系统进行研究是因为:GitHub是最流行的开源软件开发平台,提供了一种方便的代码托管服务,且其提供的API使得数据更加容易获取.
项目(存储库)是GitHub中的主要组件.因此,确定项目之间的技术依赖性是识别软件生态系统的有效方法[17].在一个通用的技术平台上,一组项目在连续的时间段内的动态交互最终形成了不断演化的软件生态系统[18].因此,为了检测生态系统的演化行为,主要的挑战是如何识别软件项目之间的动态交互,进而发现不断演化的软件生态系统.因此,本研究分为3个具体步骤:
1) 发现不断演化的生态系统
近年来不同研究提出了多种识别软件生态系统的方法.具体来说,项目之间的技术依赖可通过GitHub存储库之间的交叉引用关系来识别的[17].文中采用这种方法,根据项目之间的技术依赖关系来构建技术依赖网络,然后,使用社区发现算法来检测GitHub中的软件生态系统.
然而,发现不断演化的软件生态系统比发现静态的生态系统更具挑战性.首先,根据不同时期的数据发现的软件生态系统是不一致的,因为生态系统随着时间的推移而演化.其次,由于数据被分为不同的片段,数据稀疏性问题变得不可忽视,这将导致生态系统发生巨大的变化.因此,本文采用数据平滑方法来解决上述问题.
2) 识别演化事件
软件生态系统的演化过程可以表示为一系列演化事件的变化过程.一旦发现了不断演化的软件生态系统,每个生态系统上发生的特定演化事件就会被识别出来.文中将演化事件分为5类,并提出了识别算法.
3) 分析和演化行为相关的因素
我们试图分析与软件生态系统演化密切相关的因素.本文分别列举了生态系统的结构、生态系统的规模和生态系统的活跃度3个方面的特征.然后对不同因素进行多元线性回归分析,最终找出了与生态系统演化密切相关的重要因素.
生态学研究生物群体与其环境之间的相互关系[3],生态系统是生态学中的基本结构和功能单元.生物有机体和环境中的非生物成分相互作用,形成生态系统[1-3].扩展这一比喻,软件生态系统可以看成是一组项目之间不断协作,从而在一个共同的技术平台上形成大量的软件解决方案[6].关于软件生态系统的研究始于2005年并引起了很多研究者的兴趣[7],但它仍然处于起步阶段.软件生态系统具有广泛的研究领域,包括软件工程、社交网络和技术管理[4].Franco-Bedoya等人[2]详细介绍了开源软件和软件生态系统的关系,评估了开源软件生态系统研究的现有技术水平.
目前,软件生态系统研究在技术、业务和社会方面已经形成了大量工作[2].然而,许多工作只针对某一个特定的生态系统进行研究,例如Ma等人[11]对Python软件生态系统中的跨项目相关报错进行了实证研究,揭示了开发人员的常见做法以及修复跨项目错误的各种因素,这些发现为生态系统范围内的未来软件错误分析提供了启示;Plakidas等人[13]检查R统计计算开源生态系统的结构和演变来推进对软件生态系统研究的理解;Constantinou等人[15]对Ruby软件生态系统中,社会和技术部分的永久性修改程度所带来的影响进行了实证研究.然而,现有的工作都没有对GitHub中软件生态系统的演化过程进行大规模的研究.
许多复杂的系统可以表示为复杂的网络,系统的组件及其相互作用分别表示为节点和链接[19].软件项目及其关系也可以表示为一个复杂的网络[20],软件生态系统的结构由其技术依赖来定义[21].然而,基于源代码发现技术依赖是非常复杂的[22-23],因此,这种方法不适合于大规模平台项目.其他文章通过识别项目配置文件中的技术依赖,但这种方法并不总是可用或准确的[24-25].因此本文使用GitHub存储库之间的交叉引用关系[17]来表示项目间的技术依赖关系.
基于不同的网络模型,社区发现方法可用于识别软件生态系统并研究其内部结构和功能.根据不同的社区定义可以有不同的社区划分方法.Girvan和Newman等人[26]提出了一种社区发现算法,该算法测量正确识别的节点的比例.Shen等人[27-28]提出了一种基于模块化评估的社区发现算法.White等人[29]提出了2种频谱聚类的社区发现算法.Rosvall等人[30]提出了一种基于信息理论框架的复杂网络社区结构解析方法.但是,这些模型都不适合大规模的社区发现.本文使用一种流行的社区发现方法,Louvain社区发现方法,它可以有效地处理大规模网络[31].
社区演化的许多工作都是基于时间来研究网络模型的演化过程[32].Berger-Wolf等人将不断演化的网络转换为不同快照的静态图,以模拟动态网络中的结构变化[33],但是,他们只考虑在2个连续快照中进行匹配,并主要关注给定个体成员.Asur等人在2个连续快照中定义检测到的社区之间的重要演化事件[21],但是,这些事件并未涵盖特定社区可能发生的所有变化.Takaffoli等人提出了一个用于建模和检测社交网络中社区演化的框架,并将其应用于2个真实的数据集[34].在本文的研究中,生态系统首先在每个时间片段独立检测获得,然后进行多阶段比较以确定整个动态演化过程.为了使生态系统的演化行为更加平滑,实验中还应用了数据平滑方法[35].
基于回归的分析是最广泛使用的统计方法之一[36].多元线性回归中可以存在多个自变量或自变量函数,因此,文中通过多元线性回归分析,找出影响生态系统演化过程的相关因素.
与以往大量的社交网络工作不同,本研究主要关注GitHub中的软件生态系统演化.为了清楚地显示演化结果,我们将数据按照每半年进行划分,一共获得6个阶段的数据来挖掘不断演化的软件生态系统.此外,本文还通过多元线性回归分析方法,分析了在软件生态系统长期的演化过程中,与生态系统的生存和消亡密切相关的因素.
本文的目的是研究GitHub中软件生态系统的演化.为了实现该目标,任务分为3个步骤.
1) 获取GitHub中存储库之间的交叉引用关系.GitHub中存储库之间的交叉引用可用于表示项目之间的技术依赖关系[17].
GitHub提供一种代码托管服务,可以使软件开发变得更加高效.GitHub鼓励开发人员在项目内和项目之间与他人合作.当用户在一个项目的Pull Request操作、Issue操作或Commit Comment操作中提到另一个项目时,我们认为这2个项目之间存在一些技术依赖关系,并通过研究上述的交叉引用关系来发现软件生态系统.实验的数据来自GH Archive项目,该项目记录公开GitHub项目的操作,并且按小时存档.本文选择从GH Archive中的GitHub Events API记录的2015-01-01至2018-06-30的数据中获取交叉引用信息.
交叉引用关系主要分为2种模式:①“User/Project#Num”(例如tensorflow/tensorflow#61);②“User/Project@SHA”.文中对GH Archive数据集中的所有数据执行模式匹配,以查找符合规则的交叉引用.其次,我们使用有向加权图构建GitHub软件生态系统网络图,其中图的节点V表示在GitHub中具有交叉引用关系的项目,边E表示交叉引用关系,边的权重表示项目间技术依赖关系的强度.因此,GitHub软件生态系统网络可以由一系列图{G1,G2,…,Gn}表示,其中Gi=(Vi,Ei)表示由一组具有技术依赖关系的项目在阶段i时期构成的网络图.
图1显示了GitHub软件生态系统中具有交叉引用关系的项目所形成的网络.每个节点代表一个项目,2个节点之间的连边意味着它们有交叉引用关系.节点的颜色根据其度数从蓝色到紫色再到红色依次加深.同样的,边根据其权重不断加深.此外,还可以观察到,在GitHub生态系统内交织的网络非常复杂,而其外部被许多小型的网络包围,这表明许多项目仅与某些特定项目具有交叉引用关系,大规模的生态系统与小型生态系统共存.
Fig.1 The ecosystem network formed by GitHub repositories with cross-references
图1 GitHub中由交叉引用关系形成的软件生态系统网络
2) 数据平滑处理.为了展示软件生态系统的演进,本文将2015-01-01—2018-06-30的数据集按照每半年进行划分,最终获得7个阶段的数据来进行交叉引用关系的挖掘.然而,这一操作会带来数据稀疏问题,可能导致生态系统的急剧变化.这是因为在每6个月的时间内发现的交叉引用关系在数据分割之后是有限的.因此,文中使用数据平滑方法[37]来解决这个问题.数据平滑方法的核心思想是以不同的比例融合两个连续阶段的数据,本文首先将每个阶段的数据转换成一个矩阵,矩阵中的每个对应值表示2个对应项目之间的交叉引用数,假设来自上一阶段的交叉引用不会消失,因此我们尝试以特定比例融合来自上一阶段的数据.设B为某一阶段的关系矩阵,A为其前一阶段的关系矩阵,α为2个连续周期的平滑系数,则平滑矩阵可表示为
αA+(1-α)B,
(1)
平滑系数α可以根据2个函数计算:
(2)
(3)
其中,n0表示顶点数,wij是边的权重,σ1是方差.
最终,可以获得所有7个阶段的6个平滑系数,从而获得6个平滑矩阵,本文将平滑矩阵重新转换为项目之间的交叉引用关系来进行研究.
3) 发现不断演化的生态系统.在数据预处理之后,我们在每个时段运行生态系统发现算法.如上文所述,实验使用适用于大规模网络模型的Louvain社区发现算法[31].Louvain是一种贪婪的优化方法,旨在将网络划分为密集连接的节点社区,并不断优化网络的模块化.它首先通过寻找小型社区来优化本地模块化,然后聚合每个小社区中的节点并使用它们来构建新的网络.然后,不断迭代这两个步骤,直到模块化最大化.Louvain方法在模块化实现和计算时间方面优于所有其他社区发现方法.
一旦检测到7个阶段的软件生态系统,接下来的工作便是研究不同阶段之间生态系统的演化过程.与之前的方法不同,本文通过比较每2个连续时期之间社区的相似性来检测一个社区在7个阶段内可能经历的所有变化.
1) 相似度计算方法.实验发现在GitHub中检测到的软件生态系统大小不同,其中最大生态系统成员的数量可以达到600个,而最小生态系统成员的数量只有2个.在计算相似性时,如果将这些小生态同大生态一样对待,实验结果表明小生态都趋向于消亡,这不能反映实际情况,因为小生态也可能合并成大生态.因此,本文提出了一种依据条件判别相似度的计算方法.我们计算了7个阶段的数据,发现20%的生态系统规模大于或等于10,与此同时,80%的生态系统规模小于10,所以设立10为阈值.在计算生态系统的相似度之前,首先判断生态的规模.设ei,ej分别为i阶段和j阶段检测到的生态系统,其中(i≠j,i∈[1,7],j∈[1,7]),k为相似度阈值,k∈[0,1].如果生态的规模都大于或等于10,则其相似性计算:
sim(ei,ej)=
(4)
如果生态的规模存在小于10的,则其相似度计算:
(5)
相似度阈值k应该基于生态网络的特征来设置.具有许多活跃成员长期参与的稳定生态往往具有较高的相似度阈值.然而,在本文所研究的高度动态的软件生态网络中,生态系统的结构随时间而变化,导致生态系统变得不稳定.例如生态系统中的老成员逐渐离开,而新成员继续加入,这种生态系统也将存活很长时间.因此,为了识别生态系统的演化,本实验中的低相似度阈值将是优选,故设置阈值k=0.2.
2) 演化事件定义.在软件生态系统的动态演化过程中可能会发生不同的演化行为.本文主要定义了5种演化事件类型,即形成、生存、消亡、合并和分裂事件,其中合并事件可视为生存事件的特例,而分裂事件可视为消亡事件的特例.
这里分别给出了5种演化事件的定义.设i和j为两个连续的阶段(i<j),ei和ej为阶段i和阶段j的生态系统.设置一个阈值k并使用函数sim(ei,ej)来确定2个生态是否相互匹配,如果相似度值大于k,则认为它们相互匹配,否则它们不匹配.
定义1.形成事件.如果在之前的任何阶段没有生态系统相匹配,则该生态系统是新形成的:
∀i<j,ei⊂EI,sim(ej,EI)<k.
(6)
定义2.存活事件.如果在之后的阶段j(j>i)至少存在一个生态系统与之相匹配,则该生态系统是存活的:
∃j>i,ej⊂EJ,sim(ei,EJ)≥k.
(7)
定义3.消亡事件.如果在之后的任何阶段没有生态系统相匹配,则该生态系统是消亡的:
∀j>i,ej⊂EJ,sim(ei,EJ)<k.
(8)
定义4.合并事件.如果一组生态系统在后一阶段匹配到的生态系统相同,则称这组生态系统合并到另一个生态系统中.其中,每个生态系统的相似度值都应大于阈值k.阶段i中的社区在阶段j合并到生态系统ej时:
使得:
且n≥2.
(9)
定义5.分裂事件.如果一个生态系统的后一阶段有多个生态系统与之相匹配,则称这个生态系统发生了分裂.其中,后一阶段生态系统的成员占比都应大于阈值k.生态系统ei分裂为一组生态系统时:
使得:
且n≥2.
(10)
在获得7个阶段软件生态系统的演化事件后,我们尝试分析哪些因素与生态系统在GitHub中的长期存活密切相关.
本文从3个方面考虑可能的相关因素,包括生态系统的结构、生态系统的规模以及生态系统的活跃度.每个方面都包含多个相关的特征,可以在表1中看到.生态系统的大小由其节点数和连边数衡量.文中设定了5个特征来表征生态系统的结构,即平均度、簇系数、节点度中心系数、节点距离中心系数和节点介数中心系数.生态系统的活跃度可以通过Pull Request和Release的数量来确定.分别使用F1到F9来表示这些特征.
Table 1 Ecosystem Factors from Three Aspects
表1 生态系统3个方面的特征
AspectLabelFactorEcosystem SizeEcosystem StructureEcosystem LivenessF1VertexF2EdgeF3Average DegreeF4ClusteringF5Degree CentralityF6Closeness CentralityF7Betweenness CentralityF8Pull RequestF9Release
然后,进行多元线性回归分析以研究与生态系统演化相关的因素.本文在SPSS Statistics的帮助下进行实验,并获得第3节中讨论的结果.
本节展示了实验的结果并尝试回答引言中提出的3个研究问题.
为了回答引言中的研究问题1,我们将整个数据按照每半年划分为7个时段来发现不断演化的软件生态系统,数据的具体划分结果如表2所示,其中,Period1指的是2015年上半年,Period2指的是2015年下半年,依此类推,一共可以得到7个阶段.
文中应用数据平滑方法来解决数据稀疏性问题,通过式(1)~(3)计算所得的每2个阶段间的平滑系数α,如表3所示.
图2显示了数据平滑过程的具体细节,清晰展示了每个阶段的数据.例如2015年上半年包含1 689个节点和4 006条边,这意味着在此期间GitHub中有1 689个项目,它们之间有4 006条交叉引用关系.可以观察到交叉引用的数量随着时间的推移而急剧增加,因此研究其内部的动态变化过程具有实际意义.
Table 2 Data Partition Description
表2 数据划分描述
PeriodTimePeriod12015-01-01—2015-06-30Period22015-07-01—2015-12-31Period32016-01-01—2016-06-30Period42016-07-01—2016-12-31Period52017-01-01—2017-06-30Period62017-07-01—2017-12-31Period72018-01-01—2018-06-30
Table 3 Smoothing Coefficient Between Different Periods
表3 不同阶段间的平滑系数
αValueαValueα10.47α40.49α20.41α50.52α30.54α60.67
Fig.2 Data smoothing process procedure
图2 数据平滑处理过程
如第2节所述,本文使用Louvain社区发现算法来发现不断演化的生态系统.表4显示了每个阶段5个最大生态系统的结果.在表4中,列出了核心项目的名称,即每个生态系统中度数最高的项目,并以该项目来代表相应的生态系统.通过GitHub API对生态系统中每个项目的标签进行爬取,表3中还列出了频率最高的5个标签以更全面地描述生态系统.表格中提供了每个阶段中5个最大生态系统的详细信息,包括生态系统规模、生态系统标签和核心项目的度数.从每个阶段的标签可以看出,Go,Python和Javascript是GitHub生态系统中最受欢迎的3种语言.容器(Container)技术一直受欢迎,以至于它在所有时期都能存活下来;Microsoft/vscode生态系统是一种流行的开发工具;也可以看出与人工智能相关的生态系统正在快速增长.2015—2018年期间每个阶段的顶级生态系统规模急剧增加,这也表明许多生态系统在生态系统网络中的各个项目之间有良好的交互关系,此外,这也从另一个方面揭示了GitHub的快速发展.
根据对结果的统计分析,每个阶段的生态系统
Table 4 Results of Typical Ecosystem Detection during Seven Periods
表4 7个阶段的典型生态系统挖掘结果
PeriodNo.Key Repository NameSizeTopicsDegree1Homebrew∕homebrew141go,python,docker,containers,usegalaxy872nodejs∕io.js97nodejs,javascript,node,sass,scss86Period13ipython∕ipython97python,machine-learning,analysis,molecular-dynamics,data-science344elastic∕logstash84ruby,rails,jruby,google-cloud,activejob5156to5∕babel83javascript,eslint,ast,ecmascript,es6821docker∕docker132go,docker,containers,golang,python962nodejs∕io.js121javascript,nodejs,node,ember,css59Period23pugjs∕jade94javascript,react,nodejs,eslint,python244astropy∕astropy77python,data-analysis,molecular-dynamics,science,machine-learning235Polymer∕polymer71javascript,angular,typescript,web,pwa711docker∕docker228go,docker,kubernetes,containers,python1502SickRage∕SickRage197python,science,astronomy,data-analysis,machine-learning556Period33nodejs∕node144javascript,nodejs,node,aws,postgresql594facebook∕react-native135javascript,react,electron,nodejs,redux185Homebrew∕legacy-homebrew73java,homebrew,docker,macos,ruby791kubernetes∕kubernetes222go,docker,kubernetes,containers,golang3062Microsoft∕vscode198angular,javascript,typescript,react,vscode548Period43nodejs∕node177javascript,nodejs,react,webpack,node544conda-forge∕conda-forge-build-setup-feedstock88python,asyncio,ipython,jupyter,http415pytest-dev∕pytest86python,machine-learning,django,statistics,testing221golang∕dep274go,docker,kubernetes,containers,golang2502Microsoft∕vscode195typescript,angular,javascript,angular2,react393Period53ionic-team∕ionic193javascript,nodejs,react,typescript,node4274conda∕conda186python,machine-learning,science,astronomy,data-analysis1085Homebrew∕homebrew-core104ruby,javascript,bazel,java,jekyll721golang∕dep298go,kubernetes,docker,golang,containers9462semantic-release∕semantic-release239loopback,lb2,fullcube,mit,rheactor26Period63conda∕conda225python,python3,data-analysis,testing,jupyter334nodejs∕node208javascript,react,nodejs,typescript,babel715hashicorp∕terraform193terraform,java,terraform-provider,go,golang4861hashicorp∕terraform305kubernetes,go,docker,golang,terraform5652tc39∕ecma262259angular,javascript,typescript,react,angular49Period73conda∕conda210python,http,usegalaxy,machine-learning,c-plus-plus394angular∕angular-cli167javascript,angular,webpack,react,typescript815cms-sw∕cmssw145nodejs,javascript,bazel,typescript,bazel-rules281
数量分别为311,322,428,408,425,485和432.表4仅列出了每个阶段大型的生态系统,但是,有大量小型的生态系统是孤立的,并没有引起太多关注,如图1所示.
通过观察在不同时期检测到的上述生态系统,本文发现它们可以分为5个类别,即框架类、库类、包管理器类、开发工具类和编程语言类,大多数生态系统旨在支持软件开发,表5列出了每个类别的一些典型示例以方便解读.
Table 5 Ecosystem Type and Some Examples
表5 生态系统的类别以及一些例子
TypeEcosystem ExamplesFrameworkrails∕railsspring-projects∕spring-bootLibraryPolymer∕polymertensorflow∕tensorflowPackage Managerconda∕condaHomebrew∕homebrew-coreDevelopment ToolMicrosoft∕vscodeeclipse∕vert.xProgramming Languageapple∕swiftJuliaLang∕julia
为了回答引言中所述的研究问题2,GitHub中5种类型的生态系统演化事件被识别和发现.本文统计和分析这些事件,还提供了一些案例研究,以更好地证明生态系统演化分析的重要性.
生态系统演化事件的总体分布如图3所示,图3中横坐标是以每半年为划分形成的不同阶段,纵坐标是演化事件的比例,图3上的水平虚线用于记录每个事件的平均值.
在GitHub中,最常见的进化事件是形成和消亡,如图3所示,在每个演化阶段内,平均的形成和消亡事件百分比可达到80%.这种现象表明,每半年就会形成许多新的生态系统,相应地,许多旧的生态系统也会消亡.这暗示着GitHub中的生态系统发展非常迅速,并且每半年都会不断变化.这与当前的情况一致,近年来,IT技术发展非常迅速,导致GitHub生态系统的频繁出现或消失.
在这些不断发展的生态系统中,只有20%可以存活到下一个时期.每个时期的存活率如图3所示.这证实了GitHub中的生态系统不稳定.
在GitHub中,很少有生态系统与另一个生态系统合并,同样,很少有生态系统分裂成其他生态系统.如图3所示,只有5%是合并事件,而分裂事件的占比更低,只有约2%,这可能是由于不同生态系统之间有明确的界限.
图4显示了不同周期之间的演变过程,本文选择能够存活至少4个连续周期的生态系统进行观察.在此图中,每列代表从2015-01-01—2018-06-30的半年,其宽度表示生态系统的大小,列之间的波形表示动态变化过程,波的宽度表示生态系统的规模.生态系统的演化过程可以在图4中清楚地观测到,可以看出,生态系统演化的动态过程非常复杂,文中定义的所有演化事件都可以在图中找到,这表明依赖关系的快速变化.
Fig.3 Proportion of evolution events
图3 演化事件比例
可以观察到,很少有生态系统可以存活至少连续4个阶段,前2个时期的生态系统规模很小.随着时间的推移,一些生态系统会变大.大多数规模较大的生态系统具有较高的存活率,并且它们在下一个阶段内不断增长.相反,小型生态系统倾向于消亡或合并到其他生态系统中.因此,与小型生态系统相比,大型生态系统更加稳定.具体而言,分裂事件更可能发生在前几个阶段,然而,在最后几个阶段,合并事件更频繁地发生.这表明GitHub中的生态系统发生了巨大变化,但随着一些特定软件技术的发展,一些大型软件生态系统最终趋于稳定.
Fig.4 The evolution of ecosystem which survived for at least four consecutive periods
图4 至少存活4个阶段的生态系统演化过程图
为回答研究问题3),我们对收集的数据进行多元线性回归分析,并确定与生态系统存活相关的重要因素.
本文从3个不同方面考虑因素,如式(11)所示多元线性回归方程:
Y=α1F1+α2F2+…+α9F9+C,
(11)
其中,Y是因变量,表示生态系统的状态,0表示消亡,1表示存活.F1~F9是自变量,表示生态系统的不同特征,它们的系数是α1~α9,C是表示随机误差的常数.
本文使用NetworkX[37]这一Python包来分析复杂网络的结构和功能,并计算生态系统的特征.然后,将特征值输入SPSS统计分析软件,进行多元线性回归分析[36].
表6列出了自变量的显著性检验结果,该表显示了模型的偏回归系数B、标准误差(Std.Error)、常数(Constant)、归一化偏回归系数β、回归系数检验的统计观察t和相应的p值检验Sig..
因此,从标准化系数可以观察得到,因素F2,F3,F4,F5,F8和F9将促进生态系统的存活,而因素F1,F6,F7将使生态系统趋向于消亡.其中,生态系统的规模对生态系统的发展有较明显的影响,这种现象表明了不是节点的数量而是连边的数量决定了生态系统是否可以存活,连接越紧密的生态系统越可能存活.生态系统的结构对生态系统的发展也具有一定的影响,具体表现为:拥有较高平均度和簇系数的生态系统将倾向于存活;与围绕某些核心项目形成的生态系统相比,没有中心成员的生态系统更有可能存活.此外,生态系统的活跃度对其生存有轻微的积极影响,越活跃的生态系统越趋向于存活.
当显着性水平为α=0.05时,只有F1,F2,F3和F4通过显著性检验.虽然回归方程中的自变量非常重要,但在某些情况下,自变量F对Y并没有显著影响.因此,回归方程应该是替换为
Y=-0.539F1+0.716F2+0.366F3+0.133F4.
(12)
Table 6 Multiple Linear Regression Analysis Results
表6 多元线性回归分析结果图
VariablesUnstandardized CoefficientsBStd. ErrorStandardizedCoefficients βtSig.Constant9.750E-160.0200.0001.000Vertex-0.539 0.138-0.539-3.9020.000Edge0.716 0.1370.7165.2350.000Degree0.366 0.0400.3669.1720.000Clustering0.133 0.0270.1334.8790.000Degree Centrality0.331 0.3690.3310.8970.370Closeness Centrality-0.524 0.367-0.524-1.4270.154Betweenness Centrality-0.032 0.037-0.032-0.8600.390Pull Request0.010 0.0200.0100.5150.607Releases0.030 0.0200.0301.5000.134
GitHub生态系统的演化行为非常复杂.本部分讨论了3种典型生态系统的演化过程.
3.4.1 案例1:容器生态系统的演化
容器是目前最重要的IT技术之一.图5中的生态系统与容器技术密切相关,例如Kubernetes,容器相关的Go语言和Terraform.可以观察到,前3个阶段生态系统的数量迅速增加,然后生态系统逐渐发展成为一个更大的生态系统.这种现象表明这项技术仍在蓬勃发展,生态系统正在变得越来越大.
3.4.2 案例2:Minecraft生态系统的演化
自2015年以来,Minecraft一直是一款非常受欢迎的游戏,扩展游戏内容和优化游戏体验的生态系统至今仍然存在.Minecraft生态系统的演变可以在图6中看到.可以看出,生态系统在开始时发展得非常迅速,在第3阶段达到了最大规模,但随后开始缩小.这种现象表明游戏的普及程度有所降低.如果不采取改进措施,该生态系统可能会消亡.
3.4.3 案例3:机器人生态系统的演化
图7中的所有生态系统都与机器人相关联.值得注意的是:在第4阶段,RobotLocomotion生态系统分为2个子生态系统.根据统计分析,其中一个与机器人制造更相关,而另一个与机器人工智能更相关.这种情况可能归因于近年来人工智能技术的迅猛发展.
Fig.5 Evolution of Container Ecosystem
图5 容器生态系统的演化
Fig.6 Evolution of Minecraft Ecosystem
图6 Minecraft生态系统的演化
Fig.7 Evolution of Robotics Ecosystem
图7 机器人生态系统的演化
本文对GitHub中软件生态系统的演化进行了检测和分析.通过将数据分为7个阶段并在每个阶段中应用社区发现方法,从而发现了不断演化的生态系统.然后,文中定义并发现出5种演化事件:形成、存活、消亡、合并和分裂事件.在对GitHub的演化事件进行统计分析后,本文分析了与生态系统生存相关的因素.本文的结论是:项目间具有高技术依赖的生态系统更有可能存活下来,而只围绕某些核心项目形成的生态系统更趋向于消亡.本文最后描述了3个具体的研究案例,以更详细地展示GitHub中生态系统的演化过程.本研究发现了一些与生态系统存活密切相关的因素.在未来,我们将尝试开发一些模型来预测生态系统可能发生的演化行为,此外,还将把工作扩展到其他代码托管平台上.
[1]Tansley A G.The use and abuse of vegetational concepts and terms[J].Ecology, 1935, 16(3): 284-307
[2]Odum E P, Barrett G W.Fundamentals of ecology[M].Philadelphia: Saunders, 1971
[3]Franco-Bedoya O, Ameller D, Costal D, et al.Open source software ecosystems: A systematic mapping[J].Information and Software Technology, 2017, 91: 160-185
[4]Manikas K, Hansen K M.Software ecosystems—A systematic literature review[J].Journal of Systems and Software, 2013, 86(5): 1294-1306
[5]Lungu M F.Reverse engineering software ecosystems[D].Lugano: Università Della Svizzera Italiana, 2009
[6]Zhang Deguang, Li Bing, He Peng, et al.Characteristic Study of Open-Source Community Based on Software Ecosystem[J].Computer Engineering, 2015, 41(11): 106-113 (in Chinese)(张得光, 李兵, 何鹏, 等.基于软件生态系统的开源社区特性研究[J].计算机工程, 2015, 41(11): 106-113)
[7]Bosch J.From software product lines to software ecosystems[C] //Proc of the 13th Int Software Product Line Conf.Pittsburgh: Carnegie Mellon University, 2009: 111-119
[8]Messerschmitt D G, Szyperski C.Software ecosystems: understanding an indispensable technology and industry[M].Cambridge: MIT Press, 2003
[9]Lungu M, Lanza M, Girba T, et al.The small project observatory: Visualizing software ecosystems[J].Science of Computer Programming, 2010, 75(4): 264-275
[10]Rico A, Joao J A, Adeniyi-Jones C, et al.ARM HPC Ecosystem and the Reemergence of Vectors[C] //Proc of the Computing Frontiers Conf.New York: ACM, 2017: 329-334
[11]Ma Wan, Chen Lin, Zhang Xiangyu, et al.How do developers fix cross-project correlated bugs? A case study on the GitHub scientific Python ecosystem[C] //Proc of the 39th 2017 IEEE/ACM Int Conf on Software Engineering.Piscataway, NJ: IEEE, 2017: 381-392
[12]Wittern E, Suter P, Rajagopalan S.A look at the dynamics of the JavaScript package ecosystem[C] //Proc of the 13th 2016 IEEE/ACM Working Conf on Mining Software Repositories.Piscataway, NJ: IEEE, 2016: 351-361
[13]Plakidas K, Stevanetic S, et al.How do software ecosystems evolve? A quantitative assessment of the R ecosystem[C] //Proc of the 20th Int Systems and Software Product Line Conf.New York: ACM, 2016: 89-98
[14]Jansen S, Cusumano M A.Defining software ecosystems: A survey of software platforms and business network governance[C] //Proc of the 4th Int Workshop on Software Ecosystems.Cambridge, MA: CEUR-WS.org, 2012: 40-58
[15]Constantinou E, Mens T.Socio-technical evolution of the Ruby ecosystem in GitHub[C] //Proc of the 24th 2017 IEEE Int Conf on Software Analysis, Evolution and Reengineering.Piscataway, NJ: IEEE, 2017: 34-44
[16]Mens T.An ecosystemic and socio-technical view on software maintenance and evolution[C] //Proc of the 2016 IEEE Int Conf on Software Maintenance and Evolution.Piscataway, NJ: IEEE, 2016: 1-8
[17]Blincoe K, Harrison F, Damian D.Ecosystems in GitHub and a method for ecosystem identification using reference coupling[C] //Proc of the 12th 2015 IEEE/ACM Working Conf on Mining Software Repositories.Piscataway, NJ: IEEE, 2015: 202-211
[18]Lungu M, Robbes R, Lanza M.Recovering inter-project dependencies in software ecosystems[C] //Proc of the IEEE/ACM Int Conf on Automated Software Engineering.New York: ACM, 2010: 309-312
[19]Lancichinetti A, Fortunato S.Community detection algorithms: a comparative analysis[J].Physical Review E, 2009, 80(5): 056117
[20]Newman M E J.The structure and function of complex networks[J].SIAM Review, 2003, 45(2): 167-256
[21]Asur S, Parthasarathy S, Ucar D.An event-based framework for characterizing the evolutionary behavior of interaction graphs[C] // Proc of the 13th ACM SIGKDD Int Conf on Knowledge Discovery and Data Mining.New York: ACM, 2007: 913-921
[22]Mockus A.Amassing and indexing a large sample of version control systems: Towards the census of public source code history[C] //Proc of the 6th 2009 IEEE Int Working Conf on Mining Software Repositories.Piscataway, NJ: IEEE, 2009: 11-20
[23]Berger-Wolf T Y, Saia J.A framework for analysis of dynamic social networks[C] //Proc of the 12th ACM SIGKDD Int Conf on Knowledge Discovery and Data Mining.New York: ACM, 2006: 523-528
[24]Lungu M.Towards reverse engineering software ecosystems[C] //Proc of the 2008 IEEE Int Conf on Software Maintenance.Piscataway, NJ: IEEE, 2008: 428-431
[25]Bavota G, Canfora G, Di Penta M, et al.How the Apache community upgrades dependencies: An evolutionary study[J].Empirical Software Engineering, 2015, 20(5): 1275-1317
[26]Girvan M, Newman M E J.Community structure in social and biological networks[J].Proceedings of the National Academy of Sciences, 2002, 99(12): 7821-7826
[27]Shen Huawei, Cheng Xueqi, Cai Kai, et al.Detect overlapping and hierarchical community structure in networks[J].Physica A: Statistical Mechanics and its Applications, 2009, 388(8): 1706-1712
[28]Guimera R, Sales-Pardo M.Modularity from fluctuations in random graphs and complex networks[J].Physical Review E, 2004, 70(2): 025101
[29]White S, Smyth P.A spectral clustering approach to finding communities in graphs[C] //Proc of the 2005 SIAM Int Conf on Data Mining.Philadelphia: Society for Industrial and Applied Mathematics, 2005: 274-285
[30]Rosvall M, Bergstrom C T.An information-theoretic framework for resolving community structure in complex networks[J].Proceedings of the National Academy of Sciences, 2007, 104(18): 7327-7331
[31]Blondel V D, Guillaume J L, Lambiotte R, et al.Fast unfolding of communities in large networks[J].Journal of Statistical Mechanics: Theory and Experiment, 2008, 2008(10): P10008
[32]Sun Yizhou, Tang Jie, Han Jiawei, et al.Community evolution detection in dynamic heterogeneous information networks[C] //Proc of the 8th Workshop on Mining and Learning with Graphs.New York: ACM, 2010: 137-146
[33]Berger-Wolf T Y, Saia J.A framework for analysis of dynamic social networks[C] //Proc of the 12th ACM SIGKDD Int Conf on Knowledge Discovery and Data Mining.New York: ACM, 2006: 523-528
[34]Takaffoli M, Sangi F, Fagnan J, et al.Community evolution mining in dynamic social networks[J].Procedia-Social and Behavioral Sciences, 2011, 22: 49-58
[35]Xu K S, Kliger M, Hero A O.Tracking communities in dynamic social networks[C] //Proc of Int Conf on Social Computing, Behavioral-Cultural Modeling, and Prediction.Berlin: Springer, 2011: 219-226
[36]Uyank G K, Güler N.A study on multiple linear regression analysis[J].Procedia-Social and Behavioral Sciences, 2013, 106: 234-240
[37]NetworkX Document.Software for Complex Networks[EB/OL].[2019-12-13].https://networkx.github.io/