基于多维特征的开源项目个性化推荐方法

随着软件协同开发技术与社交网络的深度融合,社交化开发范式已成为当前软件创作与生产的重要方式。这一软件开发模型的灵活性与开放性,吸引了大规模的外围贡献者加入到开源社区中,形成了巨大的软件生产力。在开源社区中,这些分布广泛、规模巨大的外围贡献者主要以一种无组织的松散方式进行协同。他们需要花费大量的时间和精力,在海量的开源项目中寻找到自己真正感兴趣的项目并进行长期贡献。为了提高大规模群体协同的效率,本文提出一种基于多维特征的开源项目个性化推荐方法（即RepoLike）。该方法从开源项目自身流行度、关联项目技术相关度以及大众贡献者之间的社交关联度等三个维度度量开发者和开源项目之间的关联关系,并利用线性组合和Learning To Rank方法构建推荐模型,从而为开发者提供个性化的项目推荐服务。通过大规模的实证实验表明,RepoLike在推荐20个候选项目时的推荐命中率超过25%,能够有效地为开发人员提供有价值的推荐服务。     

基于内部边的群体软件开发中的项目推荐方法

开源软件生态系统的快速发展,为软件开发提供了一种新的模式,对开源软件推荐系统的研究已经成为当前一个重要的研究领域。已有的软件工程推荐系统大都利用协同过滤、机器学习以及开发者-项目属性匹配的方法进行推荐,而利用网络结构和网络分析技术进行推荐的研究相对较少。以软件生态系统GNOME为研究对象,构建开发者-项目二分网络,利用二分网络链路预测技术,采用一种基于内部边的方法对开发者进行项目推荐,并与协同过滤方法进行了对比。实验结果表明基于内部边的推荐方法比协同过滤方法更好。     

使用开源软件进行软件开发的风险分析

开源软件是当前日渐流行、同时也是争议最多的软件开发模式。在我国,越来越多的软件开发商正加入到开源软件的开发中来。结合典型案例,探讨了在使用开源软件进行软件开发过程中可能遭遇到的来自著作权、专利、开源许可协议、商标法等法律风险问题,以及国产开源软件的知识产权归属和开放源代码质量问题。希望借此帮助我国开源厂商、开发者认清使用开源软件进行软件开发的各类风险。     

开源许可证检测系统的研究*

针对软件开发过程中许可证冲突的问题,对QualiPSo(quality platform for open source software)项目中提出的开源许可证检测管理过程进行研究分析,以此为支撑,改进现有的许可证检查控制工具OSLC(open source license checker),并与项目成熟度分析和软件开发质量评估检测软件Spago4Q(spagoBI for quality)集成,开发出自动检测开源许可证冲突的原型系统;阐述了将OSLC发布成Web service的类图设计,以及Spago4Q提取器的设计与实现,力求从法律角度提高开源软件的质量,并给基于开源组件的商业软件开发者一定的建议。     

考虑开发者兴趣迁移的开源项目推荐方法

社交化编码是当前软件开发生产的一个重要方式,其开发模式的灵活性与开放性吸引了大量的开发者.开发者通过参与开源项目能够提升自己的开发能力并在社区中形成自己的影响力.许多开源社区如GitHub上有大量的开源项目.开发者将花费大量的时间与精力去寻找自己感兴趣的项目.开源项目推荐引起了研究者的兴趣,然而,目前的方法中仅仅基于开发者过去参加过的项目的相似性进行项目推荐,没有对开发者的兴趣迁移进行考虑.针对这一问题,本文提出了一种基于项目主题迁移频繁模式挖掘的推荐算法.该方法结合了概率主题模型与顺序频繁模式挖掘,并考虑项目社交关联和流行度,从而为开发者提供个性化开源项目推荐.本文所提方法的召回率比传统的方法高出了10.9%,推荐效果显著提升.     

面向软件安全性缺陷的开发者推荐方法

软件开发与维护过程中常会出现一些安全性缺陷,这些安全性缺陷会给软件和用户带来很大的风险.安全性缺陷在修复过程中,其修复级别和质量要求往往高于一般性的缺陷,因此,推荐出富有安全性经验的开发者及时有效地修复这些安全性缺陷非常重要.现有的开发者推荐技术在推荐开发者时仅仅考虑了开发者的历史开发内容,很少考虑到开发人员的安全性缺陷修复经验和修复质量等因素,所以这些技术不适用于安全性缺陷的开发者推荐.本文针对安全性缺陷的修复提出了一种有效的软件开发者推荐方法SecDR.SecDR在推荐开发者时不仅考虑了开发者的历史开发内容（与安全性相关）,还分析了开发者的修复质量和历史修复缺陷的复杂度等因素.此外,SecDR还实现了开发者的多经验级别推荐：推荐初级开发者修复简单的安全性缺陷,高级开发者修复复杂的安全性缺陷.本文在三个开源项目（Mozilla,Libgdx,ElasticSearch）上分别对SecDR推荐开发者进行有效性验证.通过对比实验证明,SecDR针对安全性缺陷推荐开发者相比于其他方法（如：DR_PSF）的推荐精度平均高出19%~42%.另外,实验对比了SecDR与实际开发人员的分配情况,结果显示SecDR可以更好地规避不合理的软件开发者的推荐.     

开源环境下开发人员行为特征挖掘与分析

软件项目开发人员行为特征是软件工程领域所关注的重要问题之一,获取个体行为特征可用于评估项目发展的进度、认识项目的发展特征、发现制约项目发展的瓶颈以及发觉项目开发过程中的异常现象.文中基于Alitheia平台设计并实现了两个测度插件,并结合一些著名开源软件项目的版本控制系统SVN库中的相关数据,对参与项目的开发人员的多种贡献行为和协同行为进行度量和深入分析,发现了一些具有重要理论和实践价值的现象与结论,揭示了开源模式下开发人员的部分行为特征.     

群智贡献标记行为研究

基于群智的开源协同模式已成为软件创新的重要模式,越来越多的开发者开始积极参与开源贡献。为有效支持开源项目管理团队对海量群智贡献的审查工作,开源协同平台设计了种类多样的工具与机制,标签是其中一种典型的任务跟踪与管理工具。为了更好地理解标签在群体实践中的应用情况,基于GitHub平台中代码合并请求（Pull-request,PR）的标记数据展开了实证研究,重点从标记时间、标签数量、标记执行者三个方面进行了分析。研究结果表明,标签在开发者中得到了广泛的使用：大部分标记时间与PR时间相同,平均每个PR带有6个以上的标记,每个标签被35人使用。     

一种基于LDA和静态分析的代码功能识别方法

近年来,随着代码复用技术不断成熟和Internet上开源项目不断丰富,软件开发人员的开发行为也逐渐发生了变化。如今,软件开发人员在编程过程中越来越多地依赖于开源软件项目提供的功能。然而,在软件复用活动中,由于开源项目文档的不全面以及代码结构的复杂性,软件开发人员往往只能片面地了解项目的某些功能点,使得复用效率不高。针对开源项目代码丰富而文档较少这一现状,提出了一种基于LDA（Latent Dirichlet Allocation）和静态分析的代码功能识别方法,对传统LDA方法进行了扩展,帮助软件开发人员更全面地了解项目的功能点,从而更好地支持代码复用活动。     

基于开源软件的项目成功度量概念模型及验证

研究了对开源社区软件间进行开发的各项数据,采用挖掘存储库数据的方式获得一种可以客观量化开源软件成功度的简易方法,确保开源软件开发团队能够全面掌握开发软件的成功程度及整个开发团队的情况,找到开源软件取得成功的各项因素.本方法利用开源社区存储库数据,实现了对开源软件质量、团队活性、用户参与度、软件规模各项要素的客观、准确描述,确保开源软件团队可以深入掌握开发软件的成功情况.     

Developer Role Evolution in Open Source Software Ecosystem: An Explanatory Study on GNOME

An open source software (OSS) ecosystem refers to an OSS development community composed of many software projects and developers contributing to these projects. The projects and developers co-evolve in an ecosystem. To keep healthy evolution of such OSS ecosystems, there is a need of attracting and retaining developers, particularly project leaders and core developers who have major impact on the project and the whole team. Therefore, it is important to figure out the factors that influence developers’ chance to evolve into project leaders and core developers. To identify such factors, we conducted a case study on the GNOME ecosystem. First, we collected indicators reflecting developers’ subjective willingness to contribute to the project and the project environment that they stay in. Second, we calculated such indicators based on the GNOME dataset. Then, we fitted logistic regression models by taking as independent variables the resulting indicators after eliminating the most collinear ones, and taking as a dependent variable the future developer role (the core developer or project leader). The results showed that part of such indicators (e.g., the total number of projects that a developer joined) of subjective willingness and project environment significantly influenced the developers’ chance to evolve into core developers and project leaders. With different validation methods, our obtained model performs well on predicting developmental core developers, resulting in stable prediction performance (0.770, F-value).     

Identifying knowledge brokers that yield software engineering knowledge in OSS projects

Much research on open source software development concentrates on developer lists and other software repositories to investigate what motivates professional software developers to participate in open source software projects. Little attention has been paid to individuals who spend valuable time in lists helping participants on some mundane yet vital project activities. Using three Debian lists as a case study we investigate the impact of knowledge brokers and their associated activities in open source projects. Social network analysis was used to visualize how participants are affiliated with the lists. The network topology reveals substantial community participation. The consequence of collaborating in mundane activities for the success of open source software projects is discussed. The direct beneficiaries of this research are in the identification of knowledge experts in open source software projects.     

The FreeBSD project: a replication case study of open source development

Case studies can help to validate claims that open source software development produces higher quality software at lower cost than traditional commercial development. One problem inherent in case studies are external validity - we do not know whether or not results from one case study apply to another development project. We gain or lose confidence in case study results when similar case studies are conducted on other projects. This case study of the FreeBSD project, a long-lived open source project, provides further understanding of open source development. The paper details a method for mining repositories and querying project participants to retrieve key process information. The FreeBSD development process is fairly well-defined with proscribed methods for determining developer responsibilities, dealing with enhancements and defects, and managing releases. Compared to the Apache project, FreeBSD uses 1) a smaller set of core developers - developers who control the code base - that implement a smaller percentage of the system, 2) a larger set of top developers to implement 80 percent of the system, and 3) a more well-defined testing process. FreeBSD and Apache have a similar ratio of core developers to people involved in adapting and debugging the system and people who report problems. Both systems have similar defect densities and the developers are also users in both systems.     

Assessing the health of open source communities

Before contributing to a free or open source software project, understand the developers, leaders, and active users behind it. The computing world lauds many Free/Libre and open source software offerings for both their reliability and features. Successful projects such as the Apache httpd Web server and Linux operating system kernel have made FLOSS a viable option for many commercial organizations. While FLOSS code is easy to access, understanding the communities that build and support the software can be difficult. Despite accusations from threatened proprietary vendors, few continue to believe that open source programmers are all amateur teenaged hackers working alone in their bedrooms. But neither are they all part of robust, well-known communities like those behind Apache and Linux.     

Bugzilla, ITracker, and other bug trackers

Bug-tracking helps the software developers in knowing what the error is, resolving it, and learning from it. Working on a software project includes managing the bugs we find. At first, we might list them on a spreadsheet. But when the number of bugs becomes too large and a lot of people must access and input data on them, we have to give up the spreadsheet and instead use a bug- or issue-tracking system. Many software projects reach this point, especially during testing and deployment when users tend to find an application's bugs. Nowadays we can choose among dozens of bug-tracking systems. This paper looks at two specific open source products and provides useful hints for working with any bug-tracking tool.     

开源许可证的选择:挑战和影响因素

开发者通常会为其开源代码选择不同的开源许可证来约束其使用条件,以期能有效地保护知识产权和维持软件的长远发展.然而,现有的开源许可证种类繁杂,开发者难以了解不同开源许可证间的差异,并且难以通过现有的开源许可证选择工具做出合适的选择——其使用要求开发者了解开源许可证相关条款并明确自己的业务需求.学术界虽然对开源许可证已有研...     

On the challenges of open-sourcing proprietary software projects

The open source software (OSS) movement has become widely recognized as an effective way to deliver software. Even big software companies, well-known for being restrictive when it comes to publishing their source code artifacts, have recently adopted open source initiatives and released for general use the source code of some of their most notable products. We conducted an exploratory study on merits of the widespread belief that open-sourcing a proprietary software project will attract external developers, like casual contributors, and therefore improve software quality (e.g., “given enough eyeballs, all bugs are shallow”). By examining the pre- and post-migration software history of eight active, popular, non-trivial proprietary projects that became open source, we characterize the phenomenon and identify some challenges. Contrary to what many believe, we found that only a few projects experienced a growth in newcomers, contributions, and popularity; furthermore, this growth does not last long. The results from the study can be useful for helping software companies to better understand the hidden challenges of open-sourcing their software projects to attract external developers.