Search

GitHub Sponsors, launched in 2019, enables donations to individual open source software (OSS) developers. Financial support for OSS maintainers and developers is a major issue in terms of sustaining OSS projects, and the ability to donate to individuals is expected to support the sustainability of developers, projects, and community. In this work, we conducted a mixed-methods study of GitHub Sponsors, including quantitative and qualitative analyses, to understand the characteristics of developers who are likely to receive donations and what developers think about donations to individuals. We found that: (1) sponsored developers are more active than non-sponsored developers, (2) the possibility to receive donations is related to whether there is someone in their community who is donating, and (3) developers are sponsoring as a new way to contribute to OSS. Our findings are the first step towards data-informed guidance for using GitHub Sponsors, opening up avenues for future work on this new way of financially sustaining the OSS community., 44th International Conference on Software Engineering(ICSE ’22), May 21–29, 2022, Pittsburgh, PA, USA., conference paper

Third-party package usage has become a common practice in contemporary software development. Developers often face different challenges, including choosing the right libraries, installing errors, discrepancies, setting up the environment, and building failures during software development. The risks of maintaining a third-party package are well known, but it is unclear how information from Stack Overflow (SO) can be useful. This paper performed an empirical study to explore npm package co-usage examples from SO. From over 30,000 SO question posts, we extracted 2,100 posts with package usage information and matched them against the 217,934 npm library package. We find that, popular and highly used libraries are not discussed as often in SO. However, we can see that the accepted answers may prove useful, as we believe that the usage examples and executable commands could be reused for tool support., journal article

The ability of an Open Source Software (OSS) project to attract, onboard, and retain any newcomer is vital to its livelihood. Although, evidence suggests an upsurge in novice developers joining social coding platforms (such as GitHub), the extent to which their activities result in a OSS contribution is unknown. Henceforth, we execute the protocols of a registered report to study activities of a “Newcomer OSS-Candidate”, who is a novice developer that is new to that social coding platform, and has the intention to later onboard an OSS project. Using GitHub as a case platform, we analyze 171 identified Newcomer OSS-Candidates to characterize their contribution activities. Results show that Newcomer OSS-Candidates are likely to target software based repositories (i.e., 66%), and their first contributions are mainly associated with development (commits) and maintenance (PRs). Newcomer OSS-Candidates are less likely to practice social coding, but eventually end up onboarding (i.e., 30% quantitative, 70% follow-up survey) an OSS project. Furthermore, they cite finding a way to start as the most challenging barrier to contribute. Our work reveals insights on how newcomers to social coding platforms are potential sources of OSS contributions., journal article

The ability of an Open Source Software (OSS) project to attract, onboard, and retain any newcomer is vital to its livelihood. Although, evidence suggests an upsurge in novice developers joining social coding platforms (such as GitHub), the extent to which their activities result in a OSS contribution is unknown. Henceforth, we execute the protocols of a registered report to study activities of a “Newcomer OSS-Candidate”, who is a novice developer that is new to that social coding platform, and has the intention to later onboard an OSS project. Using GitHub as a case platform, we analyze 171 identified Newcomer OSS-Candidates to characterize their contribution activities. Results show that Newcomer OSS-Candidates are likely to target software based repositories (i.e., 66%), and their first contributions are mainly associated with development (commits) and maintenance (PRs). Newcomer OSS-Candidates are less likely to practice social coding, but eventually end up onboarding (i.e., 30% quantitative, 70% follow-up survey) an OSS project. Furthermore, they cite finding a way to start as the most challenging barrier to contribute. Our work reveals insights on how newcomers to social coding platforms are potential sources of OSS contributions.

Third-party package usage has become a common practice in contemporary software development. Developers often face different challenges, including choosing the right libraries, installing errors, discrepancies, setting up the environment, and building failures during software development. The risks of maintaining a third-party package are well known, but it is unclear how information from Stack Overflow (SO) can be useful. This paper performed an empirical study to explore npm package co-usage examples from SO. From over 30,000 SO question posts, we extracted 2,100 posts with package usage information and matched them against the 217,934 npm library package. We find that, popular and highly used libraries are not discussed as often in SO. However, we can see that the accepted answers may prove useful, as we believe that the usage examples and executable commands could be reused for tool support.

GitHub Sponsors, launched in 2019, enables donations to individual open source software (OSS) developers. Financial support for OSS maintainers and developers is a major issue in terms of sustaining OSS projects, and the ability to donate to individuals is expected to support the sustainability of developers, projects, and community. In this work, we conducted a mixed-methods study of GitHub Sponsors, including quantitative and qualitative analyses, to understand the characteristics of developers who are likely to receive donations and what developers think about donations to individuals. We found that: (1) sponsored developers are more active than non-sponsored developers, (2) the possibility to receive donations is related to whether there is someone in their community who is donating, and (3) developers are sponsoring as a new way to contribute to OSS. Our findings are the first step towards data-informed guidance for using GitHub Sponsors, opening up avenues for future work on this new way of financially sustaining the OSS community.

Technical Debt is a metaphor used to describe the situation in which long-term software artifact quality is traded for short-term goals in software projects. In recent years, the concept of self-admitted technical debt (SATD) was proposed, which focuses on debt that is intentionally introduced and described by developers. Although prior work has made important observations about admitted technical debt in source code, little is known about SATD in build systems. In this paper, we set out to better understand the characteristics of SATD in build systems. To do so, through a qualitative analysis of 500 SATD comments in the Maven build system of 291 projects, we characterize SATD by location and rationale (reason and purpose). Our results show that limitations in tools and libraries, and complexities of dependency management are the most frequent causes, accounting for 50% and 24% of the comments. We also find that developers often document SATD as issues to be fixed later. As a first step towards the automatic detection of SATD rationale, we train classifiers to detect the two most frequently occurring reasons and the four most frequently occurring purposes of SATD in the content of comments in Maven build systems. The classifier performance is promising, achieving an F1-score of 0.71–0.79. Finally, within 16 identified ‘ready-to-be-addressed’ SATD instances, the three SATD submitted by pull requests and the five SATD submitted by issue reports were resolved after developers were made aware. Our work presents the first step towards understanding technical debt in build systems and opens up avenues for future work, such as tool support to track and manage SATD backlogs., journal article

Security vulnerability in third-party dependencies is a growing concern not only for developers of the affected software, but for the risks it poses to an entire software ecosystem, e.g., Heartbleed vulnerability. Recent studies show that developers are slow to respond to the threat of vulnerability, sometimes taking four to eleven months to act. To ensure quick adoption and propagation of a release that contains the fix (fixing release), we conduct an empirical investigation to identify lags that may occur between the vulnerable release and its fixing release (package-side fixing release). Through a preliminary study of 231 package-side fixing release of npm projects on GitHub, we observe that a fixing release is rarely released on its own, with up to 85.72% of the bundled commits being unrelated to a fix. We then compare the package-side fixing release with changes on a client-side (client-side fixing release). Through an empirical study of the adoption and propagation tendencies of 1,290 package-side fixing releases that impact throughout a network of 1,553,325 releases of npm packages, we find that stale clients require additional migration effort, even if the package-side fixing release was quick (i.e., package-side fixing releasetypeSpatch). Furthermore, we show the influence of factors such as the branch that the package-side fixing release lands on and the severity of vulnerability on its propagation. In addition to these lags we identify and characterize, this paper lays the groundwork for future research on how to mitigate propagation lags in an ecosystem., journal article

Although many software development projects have moved their developer discussion forums to generic platforms such as Stack Overflow, Eclipse has been steadfast in hosting their self-supported community forums. While recent studies show forums share similarities to generic communication channels, it is unknown how project-specific forums are utilized. In this paper, we analyze 832,058 forum threads and their linkages to four systems with 2,170 connected contributors to understand the participation, content and sentiment. Results show that Seniors are the most active participants to respond bug and non-bug-related threads in the forums (i.e., 66.1% and 45.5%), and sentiment among developers are inconsistent while knowledge sharing within Eclipse. We recommend the users to identify appropriate topics and ask in a positive procedural way when joining forums. For developers, preparing project-specific forums could be an option to bridge the communication between members. Irrespective of the popularity of Stack Overflow, we argue the benefits of using project-specific forum initiatives, such as GitHub Discussions, are needed to cultivate a community and its ecosystem., journal article

Code reviews serve as a quality assurance activity for software teams. Especially for Modern Code Review, sharing a link during a review discussion serves as an effective awareness mechanism where “Code reviews are good FYIs [for your information].”. Although prior work has explored link sharing and the information needs of a code review, the extent to which links are used to properly conduct a review is unknown. In this study, we performed a mixed-method approach to investigate the practice of link sharing and their intentions. First, through a quantitative study of the OpenStack and Qt projects, we identify 19,268 reviews that have 39,686 links to explore the extent to which the links are shared, and analyze a correlation between link sharing and review time. Then in a qualitative study, we manually analyze 1,378 links to understand the role and usefulness of link sharing. Results indicate that internal links are more widely referred to (93% and 80% for the two projects). Importantly, although the majority of the internal links are referencing to reviews, bug reports and source code are also shared in review discussions. The statistical models show that the number of internal links as an explanatory factor does have an increasing relationship with the review time. Finally, we present seven intentions of link sharing, with providing context being the most common intention for sharing links. Based on the findings and a developer survey, we encourage the patch author to provide clear context and explore both internal and external resources, while the review team should continue link sharing activities. Future research directions include the investigation of causality between sharing links and the review process, as well as the potential for tool support., journal article

Traceability between published scientific breakthroughs and their implementation is essential, especially in the case of open-source scientific software which implements bleeding-edge science in its code. However, aligning the link between GitHub repositories and academic papers can prove difficult, and the current practice of establishing and maintaining such links remains unknown. This paper investigates the role of academic paper references contained in these repositories. We conduct a large-scale study of 20 thousand GitHub repositories that make references to academic papers. We use a mixed-methods approach to identify public access, traceability and evolutionary aspects of the links. Although referencing a paper is not typical, we find that a vast majority of referenced academic papers are public access. These repositories tend to be affiliated with academic communities. More than half of the papers do not link back to any repository. We find that academic papers from top-tier SE venues are not likely to reference a repository, but when they do, they usually link to a GitHub software repository. In a network of arXiv papers and referenced repositories, we find that the most referenced papers are (i) highly-cited in academia and (ii) are referenced by repositories written in different programming languages., journal article

Severe acute respiratory syndrome coronavirus 2 (SARS-CoV-2) infection has emerged as a pandemic. Paucity of information concerning the virus and therapeutic interventions have made SARS-CoV-2 infection a genuine threat to global public health. Therefore, there is a growing need for understanding the molecular mechanism of SARS-CoV-2 infection at cellular level. To address this, we undertook a systems biology approach by analyzing publicly available RNA-seq datasets of SARS-CoV-2 infection of different cells and compared with other lung pathogenic infections. Our study identified several key genes and pathways uniquely associated with SARS-CoV-2 infection. Genes such as interleukin (IL)-6, CXCL8, CCL20, CXCL1 and CXCL3 were upregulated, which in particular regulate the cytokine storm and IL-17 signaling pathway. Of note, SARS-CoV-2 infection strongly activated IL-17 signaling pathway compared with other respiratory viruses. Additionally, this transcriptomic signature was also analyzed to predict potential drug repurposing and small molecule inhibitors. In conclusion, our comprehensive data analysis identifies key molecular pathways to reveal underlying pathological etiology and potential therapeutic targets in SARS-CoV-2 infection., journal article

Severe acute respiratory syndrome coronavirus 2 (SARS-CoV-2) infection has resulted in the global coronavirus disease 2019 (COVID-19) pandemic. Despite several single-cell RNA sequencing (RNA-seq) studies, conclusions cannot be reached owing to the small number of available samples and the differences in technology and tissue types used in the studies. To better understand the cellular landscape and disease severity in COVID-19, we performed a meta-analysis of publicly available single-cell RNA-seq data from peripheral blood and lung samples of COVID-19 patients with varying degrees of severity. Patients with severe disease showed increased numbers of M1 macrophages in lung tissue, while the number of M2 macrophages was depleted. Cellular profiling of the peripheral blood showed a marked increase of CD14+, CD16+ monocytes and a concomitant depletion of overall B cells and CD4+, CD8+ T cells in severe patients when compared with moderate patients. Our analysis indicates the presence of faulty innate-to-adaptive switching, marked by a prolonged innate immune response and a dysregulated adaptive immune response in severe COVID-19 patients. Furthermore, we identified cell types with a transcriptome signature that can be used as a prognostic biomarker for disease state prediction and the effective therapeutic management of COVID-19 patients., journal article

Code reviews serve as a quality assurance activity for software teams. Especially for Modern Code Review, sharing a link during a review discussion serves as an effective awareness mechanism where “Code reviews are good FYIs [for your information].”. Although prior work has explored link sharing and the information needs of a code review, the extent to which links are used to properly conduct a review is unknown. In this study, we performed a mixed-method approach to investigate the practice of link sharing and their intentions. First, through a quantitative study of the OpenStack and Qt projects, we identify 19,268 reviews that have 39,686 links to explore the extent to which the links are shared, and analyze a correlation between link sharing and review time. Then in a qualitative study, we manually analyze 1,378 links to understand the role and usefulness of link sharing. Results indicate that internal links are more widely referred to (93% and 80% for the two projects). Importantly, although the majority of the internal links are referencing to reviews, bug reports and source code are also shared in review discussions. The statistical models show that the number of internal links as an explanatory factor does have an increasing relationship with the review time. Finally, we present seven intentions of link sharing, with providing context being the most common intention for sharing links. Based on the findings and a developer survey, we encourage the patch author to provide clear context and explore both internal and external resources, while the review team should continue link sharing activities. Future research directions include the investigation of causality between sharing links and the review process, as well as the potential for tool support.

Traceability between published scientific breakthroughs and their implementation is essential, especially in the case of open-source scientific software which implements bleeding-edge science in its code. However, aligning the link between GitHub repositories and academic papers can prove difficult, and the current practice of establishing and maintaining such links remains unknown. This paper investigates the role of academic paper references contained in these repositories. We conduct a large-scale study of 20 thousand GitHub repositories that make references to academic papers. We use a mixed-methods approach to identify public access, traceability and evolutionary aspects of the links. Although referencing a paper is not typical, we find that a vast majority of referenced academic papers are public access. These repositories tend to be affiliated with academic communities. More than half of the papers do not link back to any repository. We find that academic papers from top-tier SE venues are not likely to reference a repository, but when they do, they usually link to a GitHub software repository. In a network of arXiv papers and referenced repositories, we find that the most referenced papers are (i) highly-cited in academia and (ii) are referenced by repositories written in different programming languages.

Security vulnerability in third-party dependencies is a growing concern not only for developers of the affected software, but for the risks it poses to an entire software ecosystem, e.g., Heartbleed vulnerability. Recent studies show that developers are slow to respond to the threat of vulnerability, sometimes taking four to eleven months to act. To ensure quick adoption and propagation of a release that contains the fix (fixing release), we conduct an empirical investigation to identify lags that may occur between the vulnerable release and its fixing release (package-side fixing release). Through a preliminary study of 231 package-side fixing release of npm projects on GitHub, we observe that a fixing release is rarely released on its own, with up to 85.72% of the bundled commits being unrelated to a fix. We then compare the package-side fixing release with changes on a client-side (client-side fixing release). Through an empirical study of the adoption and propagation tendencies of 1,290 package-side fixing releases that impact throughout a network of 1,553,325 releases of npm packages, we find that stale clients require additional migration effort, even if the package-side fixing release was quick (i.e., package-side fixing releasetypeSpatch). Furthermore, we show the influence of factors such as the branch that the package-side fixing release lands on and the severity of vulnerability on its propagation. In addition to these lags we identify and characterize, this paper lays the groundwork for future research on how to mitigate propagation lags in an ecosystem.

Technical Debt is a metaphor used to describe the situation in which long-term software artifact quality is traded for short-term goals in software projects. In recent years, the concept of self-admitted technical debt (SATD) was proposed, which focuses on debt that is intentionally introduced and described by developers. Although prior work has made important observations about admitted technical debt in source code, little is known about SATD in build systems. In this paper, we set out to better understand the characteristics of SATD in build systems. To do so, through a qualitative analysis of 500 SATD comments in the Maven build system of 291 projects, we characterize SATD by location and rationale (reason and purpose). Our results show that limitations in tools and libraries, and complexities of dependency management are the most frequent causes, accounting for 50% and 24% of the comments. We also find that developers often document SATD as issues to be fixed later. As a first step towards the automatic detection of SATD rationale, we train classifiers to detect the two most frequently occurring reasons and the four most frequently occurring purposes of SATD in the content of comments in Maven build systems. The classifier performance is promising, achieving an F1-score of 0.71?0.79. Finally, within 16 identified ‘ready-to-be-addressed’ SATD instances, the three SATD submitted by pull requests and the five SATD submitted by issue reports were resolved after developers were made aware. Our work presents the first step towards understanding technical debt in build systems and opens up avenues for future work, such as tool support to track and manage SATD backlogs.

Although many software development projects have moved their developer discussion forums to generic platforms such as Stack Overflow, Eclipse has been steadfast in hosting their self-supported community forums. While recent studies show forums share similarities to generic communication channels, it is unknown how project-specific forums are utilized. In this paper, we analyze 832,058 forum threads and their linkages to four systems with 2,170 connected contributors to understand the participation, content and sentiment. Results show that Seniors are the most active participants to respond bug and non-bug-related threads in the forums (i.e., 66.1% and 45.5%), and sentiment among developers are inconsistent while knowledge sharing within Eclipse. We recommend the users to identify appropriate topics and ask in a positive procedural way when joining forums. For developers, preparing project-specific forums could be an option to bridge the communication between members. Irrespective of the popularity of Stack Overflow, we argue the benefits of using project-specific forum initiatives, such as GitHub Discussions, are needed to cultivate a community and its ecosystem.

Severe acute respiratory syndrome coronavirus 2 (SARS-CoV-2) infection has emerged as a pandemic. Paucity of information concerning the virus and therapeutic interventions have made SARS-CoV-2 infection a genuine threat to global public health. Therefore, there is a growing need for understanding the molecular mechanism of SARS-CoV-2 infection at cellular level. To address this, we undertook a systems biology approach by analyzing publicly available RNA-seq datasets of SARS-CoV-2 infection of different cells and compared with other lung pathogenic infections. Our study identified several key genes and pathways uniquely associated with SARS-CoV-2 infection. Genes such as interleukin (IL)-6, CXCL8, CCL20, CXCL1 and CXCL3 were upregulated, which in particular regulate the cytokine storm and IL-17 signaling pathway. Of note, SARS-CoV-2 infection strongly activated IL-17 signaling pathway compared with other respiratory viruses. Additionally, this transcriptomic signature was also analyzed to predict potential drug repurposing and small molecule inhibitors. In conclusion, our comprehensive data analysis identifies key molecular pathways to reveal underlying pathological etiology and potential therapeutic targets in SARS-CoV-2 infection.

Severe acute respiratory syndrome coronavirus 2 (SARS-CoV-2) infection has resulted in the global coronavirus disease 2019 (COVID-19) pandemic. Despite several single-cell RNA sequencing (RNA-seq) studies, conclusions cannot be reached owing to the small number of available samples and the differences in technology and tissue types used in the studies. To better understand the cellular landscape and disease severity in COVID-19, we performed a meta-analysis of publicly available single-cell RNA-seq data from peripheral blood and lung samples of COVID-19 patients with varying degrees of severity. Patients with severe disease showed increased numbers of M1 macrophages in lung tissue, while the number of M2 macrophages was depleted. Cellular profiling of the peripheral blood showed a marked increase of CD14+, CD16+ monocytes and a concomitant depletion of overall B cells and CD4+, CD8+ T cells in severe patients when compared with moderate patients. Our analysis indicates the presence of faulty innate-to-adaptive switching, marked by a prolonged innate immune response and a dysregulated adaptive immune response in severe COVID-19 patients. Furthermore, we identified cell types with a transcriptome signature that can be used as a prognostic biomarker for disease state prediction and the effective therapeutic management of COVID-19 patients.

Expertise enables humans to achieve outstanding performance on domain-specific tasks, and programming is no exception. Many studies have shown that expert programmers exhibit remarkable differences from novices in behavioral performance, knowledge structure, and selective attention. However, the underlying differences in the brain of programmers are still unclear. We here address this issue by associating the cortical representation of source code with individual programming expertise using a data-driven decoding approach. This approach enabled us to identify seven brain regions, widely distributed in the frontal, parietal, and temporal cortices, that have a tight relationship with programming expertise. In these brain regions, functional categories of source code could be decoded from brain activity and the decoding accuracies were significantly correlated with individual behavioral performances on a source-code categorization task. Our results suggest that programming expertise is built on fine-tuned cortical representations specialized for the domain of programming., journal article

application/pdf, Defect prediction models are proposed to help a team prioritize source code areas files that need Software Quality Assurance (SQA) based on the likelihood of having defects. However, developers may waste their unnecessary effort on the whole file while only a small fraction of its source code lines are defective. Indeed, we find that as little as 1%-3% of lines of a file are defective. Hence, in this work, we propose a novel framework (called LINE-DP) to identify defective lines using a model-agnostic technique, i.e., an Explainable AI technique that provides information why the model makes such a prediction. Broadly speaking, our LINE-DP first builds a file-level defect model using code token features. Then, our LINE-DP uses a state-of-the-art model-agnostic technique (i.e., LIME) to identify risky tokens, i.e., code tokens that lead the file-level defect model to predict that the file will be defective. Then, the lines that contain risky tokens are predicted as defective lines. Through a case study of 32 releases of nine Java open source systems, our evaluation results show that our LINE-DP achieves an average recall of 0.61, a false alarm rate of 0.47, a top 20%LOC recall of 0.27, and an initial false alarm of 16, which are statistically better than six baseline approaches. Our evaluation shows that our LINE-DP requires an average computation time of 10 seconds including model construction and defective identification time. In addition, we find that 63% of defective lines that can be identified by our LINE-DP are related to common defects (e.g., argument change, condition change). These results suggest that our LINE-DP can effectively identify defective lines that contain common defects while requiring a smaller amount of inspection effort and a manageable computation cost. The contribution of this paper builds an important step towards line-level defect prediction by leveraging a model-agnostic technique., journal article

Expertise enables humans to achieve outstanding performance on domain-specific tasks, and programming is no exception. Many studies have shown that expert programmers exhibit remarkable differences from novices in behavioral performance, knowledge structure, and selective attention. However, the underlying differences in the brain of programmers are still unclear. We here address this issue by associating the cortical representation of source code with individual programming expertise using a data-driven decoding approach. This approach enabled us to identify seven brain regions, widely distributed in the frontal, parietal, and temporal cortices, that have a tight relationship with programming expertise. In these brain regions, functional categories of source code could be decoded from brain activity and the decoding accuracies were significantly correlated with individual behavioral performances on a source-code categorization task. Our results suggest that programming expertise is built on fine-tuned cortical representations specialized for the domain of programming.

application/pdf, Defect prediction models are proposed to help a team prioritize source code areas files that need Software Quality Assurance (SQA) based on the likelihood of having defects. However, developers may waste their unnecessary effort on the whole file while only a small fraction of its source code lines are defective. Indeed, we find that as little as 1%-3% of lines of a file are defective. Hence, in this work, we propose a novel framework (called LINE-DP) to identify defective lines using a model-agnostic technique, i.e., an Explainable AI technique that provides information why the model makes such a prediction. Broadly speaking, our LINE-DP first builds a file-level defect model using code token features. Then, our LINE-DP uses a state-of-the-art model-agnostic technique (i.e., LIME) to identify risky tokens, i.e., code tokens that lead the file-level defect model to predict that the file will be defective. Then, the lines that contain risky tokens are predicted as defective lines. Through a case study of 32 releases of nine Java open source systems, our evaluation results show that our LINE-DP achieves an average recall of 0.61, a false alarm rate of 0.47, a top 20%LOC recall of 0.27, and an initial false alarm of 16, which are statistically better than six baseline approaches. Our evaluation shows that our LINE-DP requires an average computation time of 10 seconds including model construction and defective identification time. In addition, we find that 63% of defective lines that can be identified by our LINE-DP are related to common defects (e.g., argument change, condition change). These results suggest that our LINE-DP can effectively identify defective lines that contain common defects while requiring a smaller amount of inspection effort and a manageable computation cost. The contribution of this paper builds an important step towards line-level defect prediction by leveraging a model-agnostic technique.

application/pdf, Code review is key to ensuring the absence of potential issues in source code. Code reviewers spend a large amount of time to manually check submitted patches based on their knowledge. Since a number of patches sometimes have similar potential issues, code reviewers need to suggest similar source code changes to patch authors. If patch authors notice similar code improvement patterns by themselves before submitting to code review, reviewers’ cost would be reduced. In order to detect similar code changes patterns, this study employs a sequential pattern mining to detect source code improvement patterns that frequently appear in code review history. In a case study using a code review dataset of the OpenStack project, we found that the detected patterns by our proposed approach included effective examples to improve patches without reviewers’ manual check. We also found that the patterns have been changed in time series; our pattern mining approach timely achieves to track the effective code improvement patterns., IWSC 2019 : 2019 IEEE 13th International Workshop on Software Clones, 24-24 Feb. 2019, Hangzhou, China, conference paper

application/pdf, We consider Free/libre and open source software(FLOSS) as a common pool resource (CPR). In economics, CPRsare frequently associated with markets, and it is reported thatwithout appropriate agreement, monitoring and sanction, theresource will be overused. Toward building sustainable communitiesin FLOSS development, we first study our car-sharingexperiment at NAIST, as a common pool resource management.We report the details of the car uses in our experiment, anddescribe the design of our new system to make better CPRmanagement., 2019 20th IEEE/ACIS International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing (SNPD),2019-07-0810～,Toyama, Japan, IEEE Computer Society and International Association for Computer and Information Science (ACIS), conference paper

application/pdf, We propose a sentiment classification method with a general machine-learning framework. In comparison to publicly available data sets, our method achieved the highest F1 values in positive and negative sentences on all data sets., journal article

Automatic identification of the differences between two versions of a file is a common and basic task in several applications of mining code repositories. Git, a version control system, has a diff utility and users can select algorithms of diff from the default algorithm Myers to the advanced Histogram algorithm. From our systematic mapping, we identified three popular applications of diff in recent studies. On the impact on code churn metrics in 14 Java projects, we obtained different values in 1.7% to 8.2% commits based on the different diff algorithms. Regarding bug-introducing change identification, we found 6.0% and 13.3% in the identified bug-fix commits had different results of bug-introducing changes from 10 Java projects. For patch application, we found that the Histogram is more suitable than Myers for providing the changes of code, from our manual analysis. Thus, we strongly recommend using the Histogram algorithm when mining Git repositories to consider differences in source code., journal article

We propose a sentiment classification method with a general machine-learning framework. In comparison to publicly available data sets, our method achieved the highest F1 values in positive and negative sentences on all data sets.

Code review is key to ensuring the absence of potential issues in source code. Code reviewers spend a large amount of time to manually check submitted patches based on their knowledge. Since a number of patches sometimes have similar potential issues, code reviewers need to suggest similar source code changes to patch authors. If patch authors notice similar code improvement patterns by themselves before submitting to code review, reviewers’ cost would be reduced. In order to detect similar code changes patterns, this study employs a sequential pattern mining to detect source code improvement patterns that frequently appear in code review history. In a case study using a code review dataset of the OpenStack project, we found that the detected patterns by our proposed approach included effective examples to improve patches without reviewers’ manual check. We also found that the patterns have been changed in time series; our pattern mining approach timely achieves to track the effective code improvement patterns.

Automatic identification of the differences between two versions of a file is a common and basic task in several applications of mining code repositories. Git, a version control system, has a diff utility and users can select algorithms of diff from the default algorithm Myers to the advanced Histogram algorithm. From our systematic mapping, we identified three popular applications of diff in recent studies. On the impact on code churn metrics in 14 Java projects, we obtained different values in 1.7% to 8.2% commits based on the different diff algorithms. Regarding bug-introducing change identification, we found 6.0% and 13.3% in the identified bug-fix commits had different results of bug-introducing changes from 10 Java projects. For patch application, we found that the Histogram is more suitable than Myers for providing the changes of code, from our manual analysis. Thus, we strongly recommend using the Histogram algorithm when mining Git repositories to consider differences in source code.

We consider Free/libre and open source software(FLOSS) as a common pool resource (CPR). In economics, CPRsare frequently associated with markets, and it is reported thatwithout appropriate agreement, monitoring and sanction, theresource will be overused. Toward building sustainable communitiesin FLOSS development, we first study our car-sharingexperiment at NAIST, as a common pool resource management.We report the details of the car uses in our experiment, anddescribe the design of our new system to make better CPRmanagement., IEEE Computer Society and International Association for Computer and Information Science (ACIS)

application/pdf, Code review is key to ensuring the absence of potential issues in source code. Code review is changing from a costly manual check by reviewer to a cost-efficient automatic check by coding style checkers. So that patch authors can verify the changed code before submitting their patches. Although cost-efficiency, the checkers do not detect all potential issues, requiring reviewers to verify the submitted patches based on their knowledge. It would be most efficient if patch authors will learn potential issues and remove the same type of issues from patches prior to code review. This study investigates potential issues that patch authors have repeatedly introduced in their patch submissions despite receiving feedback. To understand the impact of adopting checkers to patch authors' coding style improvement, this study compares two types of potential issues: Automatically Detected Issues by checkers (ADIs) and Manually Detected Issues by reviewers (MDIs). In a case study using an OpenStack code review dataset, we found that the patch authors have repeatedly introduced the same type of MDIs, while they do not repeat ADIs. This result suggests that the introduction of code style checkers might promote the patch authors' effective potential issues learning., IWESEP 2018 : 9th International Workshop on Empirical Software Engineering in Practice, 4-4 Dec. 2018, Nara, Japan, conference paper

application/pdf, Eclipse, an open source software project, acknowledges its donors by presenting donation badges. However, the effect of this strategy is unknown. We found that donation badges are appealing for donors and organizers because of their practical, rewarding, and inexpensive effects., journal article

Eclipse, an open source software project, acknowledges its donors by presenting donation badges. However, the effect of this strategy is unknown. We found that donation badges are appealing for donors and organizers because of their practical, rewarding, and inexpensive effects.

Code review is key to ensuring the absence of potential issues in source code. Code review is changing from a costly manual check by reviewer to a cost-efficient automatic check by coding style checkers. So that patch authors can verify the changed code before submitting their patches. Although cost-efficiency, the checkers do not detect all potential issues, requiring reviewers to verify the submitted patches based on their knowledge. It would be most efficient if patch authors will learn potential issues and remove the same type of issues from patches prior to code review. This study investigates potential issues that patch authors have repeatedly introduced in their patch submissions despite receiving feedback. To understand the impact of adopting checkers to patch authors' coding style improvement, this study compares two types of potential issues: Automatically Detected Issues by checkers (ADIs) and Manually Detected Issues by reviewers (MDIs). In a case study using an OpenStack code review dataset, we found that the patch authors have repeatedly introduced the same type of MDIs, while they do not repeat ADIs. This result suggests that the introduction of code style checkers might promote the patch authors' effective potential issues learning.

application/pdf, Peer code review is key to ensuring the absence of software defects. To improve the review process, many code review tools provide OSS(Open Source Software) project CI(Continuous Integration) tests that automatically verify code quality issues such as a code convention issues. However, these tests do not cover project policy issues and a code readability issues. In this study, our main goal is to understand how a code owner fixes conditional statement issues based on reviewers feedback. We conduct an empirical study to understand if statement changes after review. Using 69,325 review requests in the Qt project, we analyze changes of the if conditional statements that (1) are requested to be reviewed, and (2) that are implemented after review. As a result, we find the most common symbolic changes are ( and ) (35%), ! operator (20%) and -> operator (12%). Also, ! operator is frequently replaced with ( and )., ISSREW 2017 : 2017 IEEE International Symposium on Software Reliability Engineering Workshops, 23-26 Oct. 2017, Toulouse, France, conference paper

application/pdf, Previous studies have found that a significant number of bug reports are misclassified between bugs and nonbugs, and that manually classifying bug reports is a time-consuming task. To address this problem, we propose a bug reports classification model with N-gram IDF, a theoretical extension of Inverse Document Frequency (IDF) for handling words and phrases of any length. N-gram IDF enables us to extract key terms of any length from texts, these key terms can be used as the features to classify bug reports. We build classification models with logistic regression and random forest using features from N-gram IDF and topic modeling, which is widely used in various software engineering tasks.With a publicly available dataset, our results show that our N-gram IDF-based models have a superior performance than the topic-based models on all of the evaluated cases. Our models show promising results and have a potential to be extended to other software engineering tasks., ICSME 2017 : 2017 IEEE International Conference on Software Maintenance and Evolution, 17-22 Sept. 2017, Shanghai, China, conference paper

application/pdf, For developers concerned with a performance drop or improvement in their software, a profiler allows a developer to quickly search and identify bottlenecks and leaks that consume much execution time. Non real-time profilers analyze the history of already executed stack traces, while a real-time profiler outputs the results concurrently with the execution of software, so users can know the results instantaneously. However, a real-time profiler risks providing overly large and complex outputs, which is difficult for developers to quickly analyze. In this paper, we visualize the performance data from a real-time profiler. We visualize program execution as a three-dimensional (3D) city, representing the structure of the program as artifacts in a city (i.e., classes and packages expressed as buildings and districts) and their program executions expressed as the fluctuating height of artifacts. Through two case studies and using a prototype of our proposed visualization, we demonstrate how our visualization can easily identify performance issues such as a memory leak and compare performance changes between versions of a program. A demonstration of the interactive features of our prototype is available at https://youtu.be/eleVo19Hp4k., VISSOFT 2017 : 2017 IEEE Working Conference on Software Visualization, 18-19 Sept. 2017, Shanghai, China, conference paper

application/pdf, Software libraries are widely used by both industrial and open source client projects. Ideally, a client user of a library should adopt the latest version that the library project releases. However, sometimes the latest version is not better than a previous version. This is because the latest version may include additional developer effort to test and integrate all changed features. In this study, our main goal is to better understand the relationship between adoption of library versions and its release cycle. Specifically, we conducted an empirical study of release cycles for 23 libraries and how they were adopted by 415 Apache Software Foundation (ASF) client projects. Our findings show that software projects are quicker to update earlier rapid-release libraries compared to library projects with a longer release cycle. Moreover, results suggest that software projects are more likely to adopt the latest version of a rapid-release library compared to libraries with a longer release cycles., OSS 2017 : Open Source Systems: Towards Robust Practices, May 22-23, 2017, Buenos Aires, Argentina, conference paper

application/pdf, Although development activities, such as submitting patches and working with bug reports, are common contributions in open source software (OSS) projects, making donations is also an important contribution. Some OSS development projects actively collect donations by preparing benefits for donors who promote donations. In this research, we study the Eclipse project to analyze donations. We analyzed donor lists and release dates, and found the following: (1) benefits can be motivations for donations, (2) although the number of developers is small in all donors, they donated more than others, and (3) new releases are triggers of donations, but bugs negatively affect the amount of donations., IWESEP 2017 : 2017 8th International Workshop on Empirical Software Engineering in Practice, 13 March 2017, Tokyo, Japan, conference paper

Peer code review is key to ensuring the absence of software defects. To improve the review process, many code review tools provide OSS(Open Source Software) project CI(Continuous Integration) tests that automatically verify code quality issues such as a code convention issues. However, these tests do not cover project policy issues and a code readability issues. In this study, our main goal is to understand how a code owner fixes conditional statement issues based on reviewers feedback. We conduct an empirical study to understand if statement changes after review. Using 69,325 review requests in the Qt project, we analyze changes of the if conditional statements that (1) are requested to be reviewed, and (2) that are implemented after review. As a result, we find the most common symbolic changes are ( and ) (35%), ! operator (20%) and -> operator (12%). Also, ! operator is frequently replaced with ( and ).

For developers concerned with a performance drop or improvement in their software, a profiler allows a developer to quickly search and identify bottlenecks and leaks that consume much execution time. Non real-time profilers analyze the history of already executed stack traces, while a real-time profiler outputs the results concurrently with the execution of software, so users can know the results instantaneously. However, a real-time profiler risks providing overly large and complex outputs, which is difficult for developers to quickly analyze. In this paper, we visualize the performance data from a real-time profiler. We visualize program execution as a three-dimensional (3D) city, representing the structure of the program as artifacts in a city (i.e., classes and packages expressed as buildings and districts) and their program executions expressed as the fluctuating height of artifacts. Through two case studies and using a prototype of our proposed visualization, we demonstrate how our visualization can easily identify performance issues such as a memory leak and compare performance changes between versions of a program. A demonstration of the interactive features of our prototype is available at https://youtu.be/eleVo19Hp4k.

Although development activities, such as submitting patches and working with bug reports, are common contributions in open source software (OSS) projects, making donations is also an important contribution. Some OSS development projects actively collect donations by preparing benefits for donors who promote donations. In this research, we study the Eclipse project to analyze donations. We analyzed donor lists and release dates, and found the following: (1) benefits can be motivations for donations, (2) although the number of developers is small in all donors, they donated more than others, and (3) new releases are triggers of donations, but bugs negatively affect the amount of donations.

Software libraries are widely used by both industrial and open source client projects. Ideally, a client user of a library should adopt the latest version that the library project releases. However, sometimes the latest version is not better than a previous version. This is because the latest version may include additional developer effort to test and integrate all changed features. In this study, our main goal is to better understand the relationship between adoption of library versions and its release cycle. Specifically, we conducted an empirical study of release cycles for 23 libraries and how they were adopted by 415 Apache Software Foundation (ASF) client projects. Our findings show that software projects are quicker to update earlier rapid-release libraries compared to library projects with a longer release cycle. Moreover, results suggest that software projects are more likely to adopt the latest version of a rapid-release library compared to libraries with a longer release cycles.

Previous studies have found that a significant number of bug reports are misclassified between bugs and nonbugs, and that manually classifying bug reports is a time-consuming task. To address this problem, we propose a bug reports classification model with N-gram IDF, a theoretical extension of Inverse Document Frequency (IDF) for handling words and phrases of any length. N-gram IDF enables us to extract key terms of any length from texts, these key terms can be used as the features to classify bug reports. We build classification models with logistic regression and random forest using features from N-gram IDF and topic modeling, which is widely used in various software engineering tasks.With a publicly available dataset, our results show that our N-gram IDF-based models have a superior performance than the topic-based models on all of the evaluated cases. Our models show promising results and have a potential to be extended to other software engineering tasks.

application/pdf, As globally distributed software development has become generalized, social coding platforms like Github are becoming increasing needed for team collaboration. To share and help understand the overview of projects among teams, source code visualization is useful. In this paper, we present a new visual software development tool, Rocat, a city-like software code visualization in virtual reality. In addition, we integrate Rocat with a GitLabbased code hosting service, Kataribe. By integrating Rocat into Kataribe, fine-grained code information can be visualized, and city visualization can be easily shared. We present our tool and provide the features of Rocat on Kataribe. A Screencast for demonstration is available at the following URL. https://www.youtube.com/watch?v=ZQTTO91v4No., ACIT-CSII-BCD 2016 : 2016 4th Intl Conf on Applied Computing and Information Technology/3rd Intl Conf on Computational Science/Intelligence and Applied Informatics/1st Intl Conf on Big Data, Cloud Computing, Data Science & Engineering, 12-14 Dec. 2016, Las Vegas, NV, USA, conference paper

application/pdf, In a software development project, project management is indispensable, and effort estimation is one of the important factors on the management. To improve estimation accuracy, outliers are often removed from dataset used for estimation. However, the influence of the outliers to the estimation accuracy is not clear. In this study, we added outliers to dataset experimentally, to analyze the influence. In the analysis, we changed the percentage of outliers, the extent of outliers, variable including outliers, and location of outliers on the dataset. After that, effort was estimated using the dataset. In the experiment, the influence of outliers was not very large, when they were included in the software size metric, the percentage of outliers was 10%, and the extent of outliers was 100%., ICIS 2016 : 2016 IEEE/ACIS 15th International Conference on Computer and Information Science, 26-29 June 2016, Okayama, Japan, conference paper

application/pdf, In the research of Mining Software Repositories, source code repositories are one of the core sources since it contains the product and the process of software development. A source code repository stores the versions of files and makes it possible to browse the histories of files, such as modification dates, authors, messages, so on. Although such rich information of file histories is easily available, extracting the histories of methods/functions, which are elements of source code files, is not easy from general code repositories. To tackle this difficulty, we have developed Historage, a fine-grained version control system. Historage repository is a Git repository, which is built upon an original Git repository. Therefore, similar mining techniques for general Git repositories are applicable to Historage repositories. We also have developed Kataribe, a hosting service of Historage repositories, which contains hundreds of Historage repositories constructed from repositories in GitHub, which are written in C#, Java, Python and Ruby. The list of all Historage and original repositories are available at http://kataribe.naist.jp/public. With this dataset, we will promote in-depth and fine-grained software evolution research with diversity of programming languages., ICIS 2016 : 2016 IEEE/ACIS 15th International Conference on Computer and Information Science, 26-29 June 2016, Okayama, Japan, conference paper

application/pdf, Recently, information system operation becomes more important because of increasing size of information system and outsourcing the system operation. However, it is not easy for customers to judge the validity of the system operation cost. To provide information which helps the judgment, we analyzed factors which affect system operation cost. Working time of system operation service provider has the strong relationship to the cost. So, if customers know the working time, they estimate the cost properly. However, it is difficult for customers to know the working time generally. So, we assumed that customers estimate unit cost and working time, to speculate total operation cost roughly. To help the estimation, we analyzed factors affected working time and unit cost. The analysis results show that working time is settled based on the software size and the number of users, and the unit cost of the engineers increases when network range of the system is wide., ICIS 2016 : 2016 IEEE/ACIS 15th International Conference on Computer and Information Science, 26-29 June 2016, Okayama, Japan, conference paper