195 lines
38 KiB
TeX
195 lines
38 KiB
TeX
|
||
\section{引言}
|
||
|
||
“人－机－物”三元融合的新型应用模式, 通过综合应用物联网、移动互联网、通信、大数据计算、人工智能等技术，使人类社会（人）、信息空间（机）、物理世界（物）之间实现互联，形成以人为中心的新社会形态[1]。其中，软件作为关键要素，围绕软件的各类元素之间也存在复杂的依赖关系，形成了软件生态。软件生态是指各类软件制品（包括开发态和运行态）及其软件涉众（包括开发者、使用者和维护者等）和软件设施（包括承载软件制品开发与运行的物理设施和其作用的物理设施），围绕软件相关的各种活动（包括开发、使用、服务、维护等），形成的相互依赖和相互作用的网络，如图\ref{fig:fig1}所示。随着互联网的发展和软件技术的发展，这些依赖关系使得软件制品越来越依赖于其所存在的软件生态，逐渐推动软件生态化，成为软件产业的未来发展趋势。
|
||
|
||
\begin{figure}[ht]
|
||
\centering
|
||
\includegraphics[scale=1]{fig2-9/fig1.png}
|
||
\caption{软件生态系统}
|
||
\label{fig:fig1}
|
||
\end{figure}
|
||
|
||
在软件作为基础设施、软件定义一切的背景下，软件学科的内涵呈现出四个新视角，包括以驾驭复杂性为目标的系统观、以泛在服务和持续演化为特征的形态观、以使用质量为核心的价值观、以及关注群体协作平衡的生态观。这四个视角对软件生态既提供了新的观察内容，又提出了新的挑战。从系统观来说，生态系统是复杂系统（各类软件及软件活动涉及到的社会角色彼此交互），适合采用系统论驱动的复杂软件系统的观察和度量方法，以及各种模型表示方法及其工具支持。从形态观来说，软件泛在化和软件应用的持续成长趋势不仅是软件生态的驱动力，也增进了其复杂性。从价值观来说，软件生态体现了从单个元素到复杂系统的价值的转变，并且因其所涉及的浓厚社会因素从传统的质量观发展到以人为中心的价值观。从生态观来说，软件开发、使用（工具观或客体观的表述）或服务（主体观的表述）的复杂性体现在参与到软件开发、维护、使用、应用及市场的各个环节的广大社会群体，还体现在软件活动所处环境的开放性及其彼此交互和依赖所带来的不确定性等。总的来说，软件制品、软件涉众以及软件设施日益复杂化，同时在经济力量不断将国家市场转变为国际市场的前提下，全球化软件活动已经发展成为一种不可逆转的趋势[2]。全球分工不断精益化，各种供应链关系形成和发展，软件生态化成为趋势，并可能形成常态。
|
||
|
||
在软件生态化这一背景下，催生出了许多软件学科的重要研究内容。例如，如何理解并利用大规模代码和项目的供应链行为；个体如何快速学习并加入复杂项目和生态；群体如何高效高质地协作完成各类软件活动相关的任务；涵盖公司、个体开发者及用户在内的广泛社会力量如何围绕软件构建可持续性演化的生态系统等。在本章中，我们将围绕这些问题从三个层次理解软件生态。
|
||
|
||
\section{重大挑战问题}
|
||
研究软件生态的挑战问题集中在如何刻画、抽象和分析复杂的软件生态网络。具体来说，如图\ref{fig:fig1}所示，分为三个层次的依赖关系网。首先，软件制品之间存在的相互依赖关系（无论是开发态还是运行态）构成了供应链网络。软件制品特别是大型商业软件之间的依赖关系非常复杂，其挑战表现在如何理解并利用大规模代码和项目的供应链行为（§9.1.1）。其次，在这个网络上叠加软件涉众（开发者、使用者和维护者），包括软件涉众与这些软件制品形成的相互关系，以及由此带来的软件涉众之间的关系网络，从而形成相互联系软件制品生态网络与其之上的软件涉众生态网络。由此带来的挑战例如：个体如何学习并加入复杂项目和生态（§9.1.2），复杂生态中群体如何协作，协作行为如何发展（§9.1.3）等。再者，我们可以在这个网络之下叠加软件设施，包括软件设施与这些软件制品形成的相互关系，以及由此带来的软件设施之间的关系网络（也就是物联网）。在理解了三层软件生态网络的基础上，带来的核心挑战问题是生态如何形成，如何可持续发展（§9.1.4）。
|
||
|
||
\subsection{供应链的复杂性}
|
||
|
||
\begin{figure}[ht]
|
||
\centering
|
||
\includegraphics[scale=1]{fig2-9/fig2.png}
|
||
\caption{CRAN 运行时的依赖关系}
|
||
\label{fig:fig2}
|
||
\end{figure}
|
||
|
||
\begin{figure}[ht]
|
||
\centering
|
||
\includegraphics[scale=1]{fig2-9/fig3.png}
|
||
\caption{软件供应链示意图}
|
||
\label{fig:fig3}
|
||
\end{figure}
|
||
|
||
随着软件技术的不断发展和软件应用领域不断深入，软件产品越来越多样化和复杂化。一些大型项目（例如Linux内核项目）的代码规模几乎呈现指数级增长，代码之间的依赖关系也不断复杂化。例如，一个软件可能同时依赖数千个其他软件项目。图\ref{fig:fig2}展示了CRAN (Comprehensive R Archive Network)运行时复杂庞大的依赖关系，节点是软件包(package)，连线是运行时依赖关系。不同于围绕同一软件形成的生态系统，这种由于软件或软件项目之间互相依赖（如软件的构建或运行时依赖；开发者同时参与多个软件项目；软件代码的复制粘贴等）形成的复杂关系网络被称为软件供应链[3]。图\ref{fig:fig3}以开源软件为例展示了软件供应链的可能组成成分（闭源软件或开源闭源软件一体的生态也是同理），涉及了底层硬件固件、系统软件、开发平台软件、以及与用户最为相关的应用软件。大型的软件供应链几乎囊括了开发、运行过程中涉及到的所有软硬件及其生态。数以万计互相依赖的软件或项目形成的供应链为软件开发和使用带来了前所未有的创新水平，同时，规模指数级增长的软件或项目及其之间庞杂的依赖关系使得供应链的复杂度激增，进而带来诸多挑战，也促进了这方面研究的繁荣。
|
||
|
||
|
||
|
||
\subsection{个体学习以及加入生态的困难性}
|
||
个体（包括开发者、维护者等）作为软件生态中的参与者，是影响软件开发质量和效率的关键因素，是软件生态中最核心的角色之一。近年涌现的一些软件开发现象，诸如全球化、越来越多的高层次认知任务外包、针对大规模复杂项目的高效参与需求，正在改变人们思考、学习、工作以及合作的方式。尤其是许多关键系统的复杂性不断增强，使得新人进入非常困难。因此，个体如何学习和掌握复杂系统成为了一个亟待解决的问题，另外，以互联网为媒介的各种应用蓬勃发展，各种新的技术和新的应用方式层出不穷，这也给开发者如何快速学习适应变化带来了很大的挑战。这方面问题都引起了工业界和学术界的广泛关注。
|
||
|
||
“个体学习”包含了两层含义。第一，学习什么？一些复杂的大型软件项目，除了要求个体掌握必要的编程技能，项目所涉及的领域知识也需要开发者理解。除此之外，他们还需要学习如何与社区沟通（根据Astromskis等人的研究[4]，开发者近乎一半的工作时间都花费在沟通上），需要熟悉使用各种开发支持工具——这些工具及其积累的数据也是分布式环境下传播知识和学习项目的重要媒介[5]。第二，如何学习？一个开发者如何从初学新手成长为专业行家，如何从初进社区的新手角色变为核心团队成员，他怎么获取各种知识和信息，又是以一种什么顺序掌握等，这些都是理解个体学习的关键挑战。在开源项目中，并无层级组织、训练计划、集中式的环境给予初学者必要的熏陶和培育，更多的是“边干边学”（learning by doing）。研究那些高产的开发者的学习轨迹，看他们如何获得技能、解决关键而复杂的任务，了解是什么激励了他们，也许能够将他们获得技能的方法具体化，并进一步地用于训练其他人；同时，高手和新手解决问题的心理模型不一样，因而在其指导新手时可能会出现失配问题（zone of proximal development，认知科学的一个重要发现[6]）。如何理解项目中失配问题的本质，并建立相应技术和工具来更好适配新手的需求和高手的指导不仅能帮助个体成长，也将帮助软件项目和社区的发展；另外，对于要处理各种复杂编程任务的程序员，如何应对人类本身的认知局限性，例如工作记忆系统容量有限，认知负荷等问题，也是软件工程领域要考虑的问题。总的来说，我们需要对个体如何学习一个软件项目、如何使项目更具可读性（self-documenting[7]）、如何创造革命性的资源和工具来提高新人的学习能力和生产力有更深入的理解。
|
||
|
||
\subsection{群体协作的不可控性}
|
||
在经济力量不断将国家市场转变为国际市场的前提下，全球化软件开发已经发展成为一种不可逆转的趋势[15]。分布在世界各地的软件涉众需要协同发布一个可用的高质量软件，这将面临大规模的通信、协调和合作。软件开发活动中涉及到的众多角色能否积极地参与、良好地协作这些社会性的问题同样影响到软件开发的效率以及产品的质量。
|
||
|
||
基于互联网的软件开发活动，以开源开发为代表，基本都在开放透明的分布式环境下合作实施，具有沟通媒介和形式多样化（例如版本控制系统、缺陷追踪系统等软件开发支撑工具和Twitter、StackOverflow等互联网新媒体）、协作内容和信息碎片化的特点，再加上软件项目上下文千差万别，使得找到通用的（可复现的）最佳实践非常困难，从而导致群体社会化开发的可知与可控难题有加剧的趋势。
|
||
|
||
\subsection{生态的可持续性}
|
||
软件生态由于汇聚了众多复杂的软件系统、软件涉众，以及软件设施，它们之间呈现出非常复杂紧密的依赖关系，具有极快的发展速度和极大的创新潜力。随着支持分布式软件开发的开放现代平台的出现和不断完善，如GitHub、Bitbucket、和GitLab，软件项目正在以前所未有的速度增长。然而，鉴于各种复杂因素的存在，软件生态的持续发展面临诸多潜在的风险和挑战，特别是开源软件在目前的全球软件生态中扮演了非常重要的角色，但因为参与的开放性以及集中意志/管理的缺乏，其可持续性在可见的未来存在很大挑战，主要表现在如下三个方面。
|
||
|
||
首先，广泛的社会参与使得开源生态的管理控制复杂性激增。越来越多的商业组织和非营利机构参与到开源生态系统，并扮演重要的角色。例如，175个公司在OpenStack最近发布的 Rocky版本中贡献了近90%的代码[21] 。来自各个行业、出于不同目标和动机的商业公司，对开源生态的参与方式也千差万别[22]。此外，参与到同一开源生态系统的商业组织之间又会存在（或者产生）合作或竞争等关系。总的来说，不断增加的各种组织、其差别迥异的参与方式以及相互间错综复杂的关联关系，都使得开源生态系统控制和管理的难度迅速且持续增加。
|
||
|
||
其次，商业参与具有很大的不稳定性。开源生态系统中的商业公司始终需要在“开放”与“盈利”之间权衡，一旦确定其目标无法完成或参与战略发生转变等，将有可能直接停止（撤走）对开源软件的所有投入。特别是那些在开源社区占据主导地位的公司的离开，将可能直接导致该开源生态走向失败[23]。例如，IBM取消了对开源项目Aperi的支持后，该项目被迫关闭[24]。
|
||
|
||
第三，商业文化与自由开源精神存在冲突。商业公司传统的软件开发经验习惯，如组织安排、任务分工等可能伤害那些崇尚“黑客文化”、“自由软件精神”的个体开发者。因为这类开源开发者更加倾向于自发参与、按照个人意愿选择任务，例如目前世界第一大开源JavaEE应用服务器JBossAS的创始人Marc Fleury在RedHat收购JBoss之后离开[25]。
|
||
|
||
\section{主要研究内容}
|
||
为了应对上述挑战，相关研究需从以下几个方面开展。首先，为了理解和度量复杂的生态网络，前提是需要建立一套数据驱动的软件度量和分析方法（§9.2.1）。其次，围绕软件生态的三个层次，还有以下三方面主要研究内容。第一，为了应对复杂软件供应链所带来的挑战，需要理解并度量大规模代码和项目的供应链模式，从中挖掘可借鉴的成功经验，同时及时识别潜在风险（§9.2.2）。第二，基于软件供应链，开发者之间也形成了相互协作的关系网，如何帮助他们顺利加入复杂项目，提高团队协作效率也是软件生态领域所关注的主要研究内容之一（§9.2.3）。第三，基于以上研究内容，我们期待能够深入理解生态系统的形成机理和可持续机理，从而帮助软件生态可持续发展（§9.2.4）。
|
||
|
||
\subsection{数据驱动的软件度量和分析方法}
|
||
随着开发支撑技术的成熟，近年来软件项目广泛使用版本控制系统、缺陷追踪系统、邮件列表和论坛等工具，大型软件工程的数字轨迹被普遍地保存起来。软件生命期的数据，包括代码的每一次变更，人们的每一个缺陷报告、每一个评论和每一个邮件等，都被完整保存在软件仓库中。这种大规模的多源异构数据为研究软件生态带来重大契机，为人们认识软件开发的本质，提高开发效率和保证软件质量开启了一扇新的大门。如何更好地利用这些数据，让数据发挥最大价值是进行相关研究的基础。首先，应该关注数据的收集，以及组织与存储。其次，由于软件开发活动数据被广泛应用于科学研究和开发实践，数据质量对相关的研究和实践有重大影响,因而需要得到足够的重视。
|
||
|
||
\subsubsection{数据的收集}
|
||
构建数据基础设施的第一步是数据的收集工作。研究者所面临的基本挑战是数据的可得性问题。随着开源运动的不断发展状态，网络上累积了越来越多的公共开放的软件项目的开发数据，这使得大规模的数据的收集成为可能。然而，长时间、高频率的数据访问将产生类似DoS攻击的不良影响，妨碍项目的正常运转，因此，很多开源项目的组织都对数据的访问频率做出了限制。因此，大量数据的收集通常需要消耗大量的时间才能完成。如果研究者各自地重复进行收集，这不仅会给项目带来成倍的数据访问负担，而且还造成了时间、人力、物力的浪费，这也是建立数据基础设施的必要性之一。目前，由于越来越多的研究兴趣投向一些组织所拥有的数据，这些组织也开始与学术界进行接触和合作，开放他们的数据。例如Stack Exchange公司已经若干次公开发布其问答网站的数据存档\footnote{https://archive.org/details/stackexchange}，Mozilla社区也在北京大学的软件工程研究所的数据分析小组的请求下发布了其Bugzilla的后台数据库的dump [14]。如今，数据可得性的问题已经得到了极大的缓解。
|
||
|
||
在数据可得的前提下，开发和采用对应于不同数据源的数据收集的技术是收集过程的核心研究问题，这其中包括数据源的定位和数据的处理及下载。在数据源的定位上，收集的范围决定其难度。对于单一项目，数据源的定位较为简单，通过项目的wiki提供的各种在线工具的URL链接人工定位即可；对于单一组织管理的项目集合，通常会有项目列表，其中包含了每个项目各类资源的URL链接；对于没有特定的目标，要进行普查式的收集，需要借助人的知识与经验，从一些经典及大型的组织入手，按照单一组织下项目的数据源的定位方式进行检索，其次利用检索工具进行更大范围的检索，例如Mockus在全面收集开源项目版本控制数据的工作中便先从SourceForge、GoogleCode、Savannah、Tigris等知名的软件项目门户，以及Linux kernel, FreeBSD, NetBSD等社区入手，之后借助文献、Google代码检索工具等进行补充[30]。对于数据的下载，不同类型的访问方式决定了不同的下载方式。对于问题追踪等来自web应用的数据，通常可以通过网络爬虫技术对页面进行检索和下载，如果该应用提供了数据访问的API，可以直接通过API来下载。这两种下载方式的缺陷包括两个方面，一方面是下载的伸缩性受到应用本身对数据访问频率的限制，对于大规模的数据，需要投入更多的IP地址及下载时间；另一方面是无论用户接口还是编程接口会发生版本的迭代，数据下载的逻辑可能需要变更，所下载的数据格式可能改变。对于版本控制等可以直接克隆或者镜像后台数据库的系统的数据，使用相应的工具或者命令进行下载。对于官方提供工具后台数据库dump的情况，研究者只要简单地进行下载即可，但数据的提供方需要做一定的处理工作，包括去除隐私、安全及其他敏感数据，才能对数据进行公开。未来研究的重点将是针对不同应用场景，如何高效高质量的定制数据集。
|
||
|
||
\subsubsection{数据的组织与存储}
|
||
数据的组织与存储主要服务于后续的数据访问与分享。数据组织通常包括两个方面，数据格式的转换和数据模型的建立。一方面，某些原始数据的格式，例如web页面，版本控制库等，需要较为复杂的解析程序来进行数据的解析从而提取相应的信息。可以先将此类特殊格式的数据转换为较为通用、解析容易的格式，如CSV，JSON，XML等，然后进行存储；另一方面，为了便于数据的检索和分析，有些数据基础设施会对数据进行建模，抽象出其中的实体与实体间的关系，按照定义的模型进行存储，例如Gousios[11]将通过GitHub API所收集到的非关系型的数据，按照其定义的关系模型存储在MySQL数据库中。根据数据组织方式的不同，数据一般会采用文件系统、数据库系统或者其他工具特定的方式，如版本控制系统，来进行存储。采用何种方式进行数据的存储取决于原始数据的类型和数据收集者所设计的应用场景。此外，多源异构数据的存在使得如何建立不同数据源间的联系成为了其中的重要研究问题之一。
|
||
|
||
\subsubsection{数据的质量}
|
||
高质量的数据是对软件开发实践进行分析、预测、推荐的基础。确保软件数据质量主要从两个角度出发。首先，取决于数据清洗。数据清洗的目的在于去除影响数据分析结果的“脏数据”，例如，在问题追踪系统中，某个问题报告的评论中可能含有广告等无关软件开发活动的数据，他们会影响基于评论数量、评论时间等度量的准确性从而威胁到分析得出的结论。一般而言，去除“脏数据”的过程更多地体现在具体的数据分析中，在目前大多数数据基础设施的建立过程中，由于没有针对特定的研究问题，数据清洗的工作涉及较少。其次，应该关注数据与上下文是否相匹配[33]。如果不匹配，这可能使得基于问题数据的方法、软件产生的结果存在偏差,甚至无效。例如,Kim 等人[31]在利用问题追踪数据智能化预测任务完成时间的工作中,将问题报告被标记为“已解决”的时间点视为该任务完成的时刻。然而Zheng 等人[32]发现：任务完成的时间存在问题——开发者在完成任务后可能并不会及时将问题报告标记为“已解决”,而是在之后清理问题追踪系统时,通过脚本进行批量处理,即“任务完成时间”并不能真正代表任务被解决的时刻。因此,Kim 等人的结果存在偏差。我们相信,随着人们对软件生态的认识逐渐深入,数据质量问题会得到越来越多的关注(鉴于软件生态相关研究对于数据的依赖)。同时希望有越来越多的努力构建出可靠的数据集,或者构建相应的方法来产生可靠的数据集。此外，用自动化的方法来检测和修正问题数据也应是未来研究应关注的重点内容之一。
|
||
|
||
\subsection{软件供应链的度量与分析}
|
||
在大数据时代，基于多源信息融合研究如何规避供应链风险对软件质量保证至关重要。软件供应链在为开发人员提供便利的同时，也引进了新的风险和不确定性。一方面供应链上任何一个节点的问题都可能波及到链条上的其它节点，使得损失被放大，例如月下载量千万的npm包就曾被黑客篡改，大批开发者的权益可能会被侵犯或已经被侵犯\footnote{https://github.com/dominictarr/event-stream/issues/116}；另一方面任何一个节点会需要承受链条上所有其他节点的问题，仍然是损失会放大。因此，对于“软件生态供应链”风险的评估就变得愈发重要，很多企业（尤其是大企业）在这方面的需求不断增加。研究上需要对形成软件供应链的软件之间的功能性、组织性依赖关系进行大规模的深入分析。值得一提的是，随着软件活动数据越来越丰富，研究软件供应链的理论基础开始从原来的数据少、基于定性的方法向数据丰富、基于量化的方法转变。这提供了更好的方法来量化供应链中的风险及其传递，进而为降低这些风险及其影响力提供了契机。但需要指出的是，由于软件供应链几乎囊括了开发、运行过程中涉及到的所有软硬件，涉及项目众多，项目间关系极其复杂，该方面的研究目前还处于初始阶段。
|
||
|
||
\subsection{个体学习与群体协作的研究}
|
||
作为软件涉众之一的开发者，他们在软件生态中扮演者非常重要的角色。如何帮助新开发者快速加入复杂生态以及提高群体协作效率是一大关键研究内容。
|
||
|
||
\subsubsection{个体学习}
|
||
随着软件生态变得越来越复杂，个体如何学习并加入生态存在诸多障碍。为了向他们提供有效帮助，相关研究应重点关注两个方面：研究如何利用数据来度量个体学习能力，以及如何借鉴社会学的研究方法和洞见来研究软件开发的社会性特征及相关问题。
|
||
|
||
软件开发最根本问题在于开发者个体的复杂性，主要挑战在于个体（学习）能力的度量和评估—无法度量也就无法揭示问题所在，进而难以控制其复杂性。海量的软件开发历史数据和先进的分析方法和工具使得探索并解决该问题成为可能。例如，通过对软件开发中的多源数据（包括版本控制、任务追踪、人力资源等数据）进行融合来度量开发者的开发任务随时间的变化，对任务的价值和难度、所体现的开发者人际关系进行多维度的刻画，建立程序员成熟度的度量框架，以此来评估开发者经验的成长轨迹[8][9] 。这些度量方法和结果为我们更好的探究软件项目个体开发者的学习和能力成长提供了坚实的基础和依据。未来还要很多研究工作需要深入，包括更好支持评估项目中程序员的技能与效率，支持对程序员成长轨迹的精确分析，为初学者选择合适的开发任务等。
|
||
|
||
社会科学领域的诸多学科，例如认知学、发展心理学、组织管理学，已经对人类学习有许多研究。更确切地说，意识和脑、思考和学习的方式、解决问题过程中神经的行为和能力的提升都被集中地研究。并且，多个分支学科发现的证据存在交集[10] ，使得多学科交叉发展以追求对人类学习的更全面的认识成为一个重要趋势。因此，如何借用这些学科的视角去理解开发者的学习是主要研究内容之一。这方面已有很多研究值得借鉴。例如Curtis论证认知学就是这样一个范例[11]，它提供了很好的方式去理解影响项目表现的最重要因素。此外，我们还能基于对开发者学习的研究结果普适性地理解人类学习。在过去的几十年里，人们花费了大量的努力试图解开工作绩效的决定因素。在一开始人们普遍认为导致异常表现的特征是天生的，并且是遗传的[12]。然而，Ericsson等人[13]的研究表明，许多曾经被认为反映天赋的特征实际上是经过了长达十年的紧张练习的结果。周等的一个工作借用管理科学的一个框架来表征开源贡献者进入社区的初始行为特征[14]，并利用其在社区的初始活动数据来度量该框架的三个维度，如图\ref{fig:fig4}所示。他们发现，新加入的贡献者成为长期贡献者（long term contributor，在社区中持续贡献三年以上）的可能性与他的能力（ability）、意愿（willingness）以及环境因素（environment）有关，例如，其参与社区的意愿（量化为其所报告的问题是否会得到解决，表征了该问题的质量，即报告者为报告该问题所倾入的精力）能够使其成为长期贡献者的概率加倍[8][12]。这个工作建立了一个开发者初始行为度量体系，支持对开发者长期贡献的分析预测。
|
||
|
||
\begin{figure}[ht]
|
||
\centering
|
||
\includegraphics[scale=1]{fig2-9/fig5.png}
|
||
\caption{开发者行为特征的理论框架与相关量度}
|
||
\label{fig:fig4}
|
||
\end{figure}
|
||
|
||
\subsubsection{群体协作}
|
||
从大规模数据挖掘细粒度的微过程[16]，是找到可复现群体协作活动的可能途径。微过程是项目在完成各项特定任务（例如解决bug，提交代码，沟通需求，指导新手等）时所采用的方式方法或活动流程，对微过程的度量是获取细粒度可复制最佳实践的关键。如图\ref{fig:fig5}所示，微过程研究可以从广度和深度两个方面来开展，分这两种选择主要是从时间和成本上来考虑。相关研究工作也是从这两方面展开的。
|
||
|
||
广度研究是指，从尽可能广阔的视角上（例如覆盖尽可能多的项目）去探索问题。例如，朱等以GitHub中海量软件项目为样本研究了项目中文件目录的使用模式及其对项目流行度的影响[17]，发现标准文件夹（例如文档，测试和示例）不仅是最常用的文件夹，而且其使用与项目流行度（即项目fork数量）密切相关。对文件夹使用的初步研究表明，可以借鉴频繁模式挖掘获得的文件夹使用模式，量化和改进文件的组织实践。Ohira等人[18]对拥有大量开发人员和项目的大型在线社区SourceForge.net进行分析，发现开发者群体协作关系呈现无标度网络（scale-free network）特征。即，只有少数开发者加入了许多项目并与其他开发者建立了丰富的链接，而大多数开发者加入的项目很少，并且与其他项目的社交关系非常有限。通过对开发者社交网络的构建，有助于帮助开发者定位沟通对象，识别有经验的开发者，从而提高群体协作的效率和质量。
|
||
|
||
深度研究是指以典型案例为研究对象进行深入探索。例如，针对软件项目缺陷追踪工作流中的一个微过程：产品定位，谢等发现了影响其质量的若干关键因子并提出了度量方法，进而设计了一个工具PAR（Product Assignment Recommender）用于预测缺陷报告是否被准确定位，然后应用到了Mozilla十年历史中的88,000 个缺陷报告[19]。结果表明，该工具的精度达到73.65%，比随机预测的精确度高3.4倍，有助于改进缺陷报告的质量。又例如，谭等研究了开源贡献者对同一代码文件进行修改的最佳合作模式。提出以集中度、复杂度和稳定性来刻画同一个文件的代码贡献组成，并以OpenStack的核心项目Nova为例归纳出3种贡献组成模式。这些模式可以用来对代码贡献提出推荐，例如，对于逻辑复杂、代码量大的文件（例如实现系统核心功能的文件等），一旦出现问题会直接导致系统不能正常工作，最好由两名以上核心开发者进行开发和维护，这样在某个开发者离开时，不会出现无监管状态[20]。以上研究都从多个维度对群体协作进行了度量，所得出的研究结果可以为复杂的群体社会化开发提供相关建议。
|
||
|
||
\begin{figure}[ht]
|
||
\centering
|
||
\includegraphics[scale=0.3]{fig2-9/fig4.png}
|
||
\caption{微过程研究模式图}
|
||
\label{fig:fig5}
|
||
\end{figure}
|
||
|
||
\subsection{软件生态机制机理的研究}
|
||
探究生态系统构建及其持续发展的理论、方法与技术是软件数字社会学的又一大关键研究内容。软件生态在近十多年的发展中得到了学术界和产业界的广泛关注。主要研究内容包含以下两个方面。
|
||
|
||
\subsubsection{软件生态系统的形成和演化}
|
||
此类研究的主要目的是通过分析生态系统的历史数据度量生态的健康状态并建立可持续发展理论等。例如，Gamalielsson等人基于邮件列表中回复者的质量，提出将响应能力作为软件生态系统健康度的评价指标[26]。Lehman等提出软件生态系统的成熟理论用来评估软件的进化，例如生存能力，增长潜力等[27]。我们有个工作是通过挖掘Linux内核的开发历史数据，从Maintainer工作量的角度来探究影响Linux kernel生态系统可持续演化的关键因素[28]。结果表明Linux kernel的任务规模和Maintainer数量都随时间持续增长，且尽管Maintainer的平均负载随时间有降低的趋势，但因为工作量分布的不均衡性，少数Maintainer仍然存在过劳现象。Linux kernel的部分模块如硬件驱动程序只有不足20%的Maintainer负责审查80%的代码提交。这种核心Maintainer负载过重的情况将直接影响软件生态的持续稳定发展。该工作还发现为一个文件指派多个Maintainer只能提高1/2的生产率。因此，寻找降低软件生态管理复杂度的解决方案将是未来工作的一个重点。
|
||
|
||
\subsubsection{软件生态系统中的商业参与}
|
||
此类研究重点关注开源软件生态系统，的目的是探究商业参与模式及其对开源生态的影响并寻找可能的有效实践。例如，我们面向三个技术同构的混合项目（JBossAS，JOnAS，Geronimo，均为实现JavaEE规范的应用服务器项目）进行了实证分析[23]，通过收集分析互联网上大量文本信息以及项目开发活动数据建立了三个商业参与模型，并量化了不同模型对贡献者参与的影响。该研究发现重度商业参与会减少新来者但同时提高贡献者的持续度。我们另一个研究OpenStack（开源云计算平台）的工作也发现，个别商业公司对开源项目的高强度控制会降低其他公司以及个体开发者的参与[29]。我们还探索了商业公司广泛参与OpenStack的现状[22]，研究表明，来自不同行业的公司会通过有选择地对OpenStack生态中某些子项目做贡献来实现它们的特定目标，例如IBM和Intel会向OpenStack贡献大量的驱动和插件来实现软硬件兼容。不同公司的贡献方式也有很大差别，例如有的公司会将贡献重心放在文档编写上。总的来说，现有工作尚未很好的解决众多商业组织和非营利机构的参与给开源生态带来的诸多挑战。相反很多研究案例折射出了目前开源生态系统在商业与开源混合时的困局。未来的挑战在于从各个角度探索以深入并全面地刻画开源生态系统中的商业参与。
|
||
|
||
\section{本章小结}
|
||
现如今全球化的软件开发面临复杂性不断扩张的问题：软件规模急剧增长、代码依赖错综复杂；开发者个体差异大、群体协作难以控制；广泛的社会参与形成复杂生态等。这些问题为研究软件生态带来了巨大挑战。在这一章中，我们从软件生态的三个层次出发，指出了软件生态面临的几大挑战问题。同时，我们也围绕这几大挑战问题，列出了一些重要研究内容，期待能帮助人们更好的理解和构建软件生态，也希望能为相关研究人员带来一些新观点和新视角。
|
||
|
||
\section{参考文献}
|
||
[1] 赵兰香等主编. 科技发展新态势与面向2020年的战略选择[J]. 中国科学院院刊, 2013(5).
|
||
|
||
[2] Herbsleb J D, Moitra D. Global software development[J]. IEEE Software, 2001, 18(2): 16-20.
|
||
|
||
[3] Mockus A. Keynote: Measuring Open Source Software Supply Chains. NASAC, 2017.
|
||
|
||
[4] Astromskis S, Bavota G, Janes A, et al. Patterns of developers behaviour: A 1000-hour industrial study[J]. Journal of Systems and Software, 2017, 132: 85-97.
|
||
|
||
[5] Manikas K, Hansen K M. Software ecosystems–A systematic literature review[J]. Journal of Systems and Software, 2013, 86(5): 1294-1306.
|
||
|
||
[6] Vygotsky, L. Interaction between learning and development. Readings on the Development of Children, 1978, 23.3: 34-41.
|
||
|
||
[7] Schach S R. Object-oriented and classical software engineering[M]. McGraw-Hill, 2002.
|
||
|
||
[8] Zhou M, Mockus A. What make long term contributors: Willingness and opportunity in OSS community[C]//International Conference on Software Engineering. IEEE, 2012:518-528.
|
||
|
||
[9] Tan, X., Qin, H., \& Zhou, M. Understanding the variation of software development tasks: A qualitative study. //Proceedings of the 9th Asia-Pacific Symposium on Internetware. ACM, 2017.
|
||
|
||
[10] National Research Council. How people learn: Brain, mind, experience, and school: Expanded edition[M]. National Academies Press, 2000.
|
||
|
||
[11] Curtis B. Fifteen years of psychology in software engineering: Individual differences and cognitive science[C]//Proceedings of the 7th International Conference on Software Engineering. IEEE Press, 1984: 97-106.
|
||
|
||
[12] Neisser U, Boodoo G, Bouchard Jr T J, et al. Intelligence: knowns and unknowns[J]. American Psychologist, 1996, 51(2): 77.
|
||
|
||
[13] Ericsson K A, Krampe R T, Tesch-Römer C. The role of deliberate practice in the acquisition of expert performance[J]. Psychological Review, 1993, 100(3): 363.
|
||
|
||
[14] Zhou, M., \& Mockus, A. Who will stay in the floss community? Modeling participant’s initial behavior. IEEE Transactions on Software Engineering, 41(1), 82-99, 2015
|
||
|
||
[15] Herbsleb J D, Moitra D. Global software development[J]. IEEE Software, 2001, 18(2): 16-20.
|
||
|
||
[16] Zhou M, Mockus A. Mining micro-practices from operational data[C]
|
||
//Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering. ACM, 2014: 845-848.
|
||
|
||
[17] Zhu J, Zhou M, Mockus A. Patterns of folder use and project popularity: a case study of github repositories[C]// Acm/IEEE International Symposium on Empirical Software Engineering \& Measurement. ACM, 2014:1-4.
|
||
|
||
[18] Ohira M, Ohoka T, Kakimoto T, et al. Supporting knowledge collaboration using social networks in a large-scale online community of software development projects[C]//12th Asia-Pacific Software Engineering Conference (APSEC'05). IEEE, 2005: 6 pp.
|
||
|
||
[19] Xie J, Zheng Q, Zhou M, et al. Product assignment recommender[C]
|
||
//Companion Proceedings of the 36th International Conference on Software Engineering. ACM, 2014: 556-559.
|
||
|
||
[20] 谭鑫,林泽燕,张宇霞,周明辉.代码文件贡献组成模式的分析[J].软件学报,2018,29(8):2283−2293.
|
||
|
||
[21] OpenStack Foundation, http://stackalytics.com/?
|
||
project\_type
|
||
=all\&metric=commits, 2018
|
||
|
||
[22] 张宇霞,周明辉,张伟,等. OpenStack开源社区中商业组织的参与模式[J]. 软件学报, 2017, 28(6): 1343-1356.
|
||
|
||
[23] Zhou M, Mockus A, Ma X, et al. Inflow and retention in oss communities with commercial involvement: A case study of three hybrid projects[J]. ACM Transactions on Software Engineering and Methodology (TOSEM), 2016, 25(2): 13.
|
||
|
||
[24] Chris Mellor. Aperi dies on its arse. The Register, https://
|
||
www.theregister.co.uk/2009/01/30/aperi\_is\_dead/ (2009).
|
||
|
||
[25] CIO Staff, https://www.cio.com/article/2442437/open-source-tools/
|
||
jboss-head-marc-fleury-leaves-red-hat.html , 2018
|
||
|
||
[26] Gamalielsson J, Lundell B, Lings B. Responsiveness as a measure for assessing the health of OSS ecosystems[C]//Proceedings of the 2nd International Workshop on Building Sustainable Open Source Communities (OSCOMM 2010). Tampere: Tampere University of Technology, 2010: 1-8.
|
||
|
||
[27] Lehman M M, Ramil J F, Wernick P D, et al. Metrics and laws of software evolution-the nineties view[C]//Proceedings Fourth International Software Metrics Symposium. IEEE, 1997: 20-32.
|
||
|
||
[28] Zhou M, Chen Q, Mockus A, et al. On the scalability of Linux kernel maintainers' work[C]//Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering. ACM, 2017: 27-37.
|
||
|
||
[29] Zhang Y, Tan X, Zhou M, et al. Companies' domination in FLOSS development: an empirical study of OpenStack[C]//Proceedings of the 40th International Conference on Software Engineering: Companion Proceeedings. ACM, 2018: 440-441.
|
||
|
||
[30] Mockus A. Amassing and indexing a large sample of version control systems: Towards the census of public source code history[C]// Mining Software Repositories, 2009. MSR '09. 6th IEEE International Working Conference on. IEEE, 2009:11-20.
|
||
|
||
[31] Kim S, Jr. Whitehead EJ. How long did it take to fix bugs? In: Proc. of the 2006 Int’l Workshop on Mining Software Repositories.ACM Press, 2006. 173−174.
|
||
|
||
[32] Zheng Q, Mockus A, Zhou M. A method to identify and correct problematic software activity data: Exploiting capacity constraints and data redundancies. In: Proc. of the 2015 9th Joint Meeting on Foundations of Software Engineering. ACM Press, 2015.637−648.
|
||
|
||
[33] 涂菲菲,周明辉.软件开发活动数据的数据质量问题.软件学报,
|
||
2019,30(5):1522−1531. http://www.jos.org.cn/1000-9825/5727.htm
|