Hideaki Hata

A dataset of high impact bugs: manually-classified issue reports

The importance of supporting test and maintenance activities in software development has been increasing, since recent software systems have become large and complex. Although in the field of Mining Software Repositories (MSR) there are many promising approaches to predicting, localizing, and triaging bugs, most of them do not consider impacts of each bug on users and developers but rather treat all bugs with equal weighting, excepting a few studies on high impact bugs including security, performance, blocking, and so forth. To make MSR techniques more actionable and effective in practice, we need deeper understandings of high impact bugs. In this paper we introduced our dataset of high impact bugs which was created by manually reviewing four thousand issue reports in four open source projects (Ambari, Camel, Derby and Wicket).

Characteristics of sustainable OSS projects: a theoretical and empirical study

How can we attract developers? What can we do to incentivize developers to write code? We started the study by introducing the population pyramid visualization to software development communities, called software population pyramids, and found a typical pattern in shapes. This pattern comes from the differences in attracting coding contributors and discussion contributors. To understand the causes of the differences, we then build game-theoretical models of the contribution situation. Based on these results, we again analyzed the projects empirically to support the outcome of the models, and found empirical evidence. The answers to the initial questions are clear. To incentivize developers to code, the projects should prepare documents, or the projects or third parties should hire developers, and these are what sustainable projects in Git Hub did in reality. In addition, making innovations to reduce the writing costs can also have an impact in attracting coding contributors.

Software population pyramids: the current and the future of OSS development communities

Context: Since human power is an essential resource, the number of contributors in a software development community is one of the health indicators of an open source software (OSS) project. For maintaining and increasing the populations in software development communities, both attracting new contributors and retaining existing contributors are important. Goal: Our goal is understanding the current status of projects population, especially the different experienced contributors composition of the projects. Method: We propose software population pyramids, a graphical illustration of the distribution of various experience groups in a software development community. Results: From the study with OSS projects in GitHub, we found that the shapes of software population pyramids varies depending on the current status of OSS development communities. Conclusions: This paper present a software population pyramid of the distribution of various experience groups in a software community population. Our results can be considered as predictors of the near future of a project.

Revenue Maximizing Markets for Zero-Day Exploits

Markets for zero-day exploits (software vulnerabilities unknown to the vendor) have a long history and a growing popularity. We study these markets from a revenue-maximizing mechanism design perspective. We first propose a theoretical model for zero-day exploits markets. In our model, one exploit is being sold to multiple buyers. There are two kinds of buyers, which we call the defenders and the offenders. The defenders are buyers who buy vulnerabilities in order to fix them (e.g., software vendors). The offenders, on the other hand, are buyers who intend to utilize the exploits (e.g., national security agencies and police). Our model is more than a single-item auction. First, an exploit is a piece of information, so one exploit can be sold to multiple buyers. Second, buyers have externalities. If one defender wins, then the exploit becomes worthless to the offenders. Third, if we disclose the details of the exploit to the buyers before the auction, then they may leave with the information without paying. On the other hand, if we do not disclose the details, then it is difficult for the buyers to come up with their private valuations. Considering the above, our proposed mechanism discloses the details of the exploit to all offenders before the auction. The offenders then pay to delay the exploit being disclosed to the defenders.

Towards Building API Usage Example Metrics

It is not unreasonable to say that examples are one of the most commonly used knowledge sources when learning the usage and best practices of a new API. That being said, in many cases the examples provided on the APIs Web site are lacking in quantity or quality, so developers have to resort to other information sources, namely blogs and coding forums. Moreover, there is no good way for API developers to measure anything concerning the examples they are creating. In order to resolve the problem of lacking examples information and feedback in their creation, our goal is to develop metrics for empirical measurement of examples and to offer support during the APIs example creation steps, and this paper represents the starting point towards that aim. We have analyzed the source code examples provided on the APIs Web site or GitHub directory for seven popular API libraries written in Java and measured certain metrics, such as example coverage, example code to source code ratio, class coverage percentage, and problems that occur with the compilation and execution of existing examples. The purpose of this paper is to investigate the current situation of examples and provide a starting knowledge base for building an automatic tool for source code example metrics analysis.

Code review participation: game theoretical modeling of reviewers in gerrit datasets

Code review is a common practice for improving the quality of source code changes and expediting knowledge transfer in a development community. In modern code review, source code changes or patches are considered to be assessed and approved for integration by multiple reviews. However, from our empirical study, we found that some patches are reviewed by only one reviewer, and some reviewers did not continue the review discussion, which can have negative effects on software quality. To understand these reviewers behaviors, we model the code review situation based on the snowdrift game, which is used to analyze social dilemmas. With this game-theoretical modeling, we found that it can explain reviewers behaviors well.

Analyzing the Decision Criteria of Software Developers Based on Prospect Theory

To enhance the quality of software, many software development support tools and software development methodologies have been proposed. However, not all proposed tools and methodologies are widely used in software development. We assume that the evaluation of tools and methodologies by developers is different from the evaluation by researchers, and that this is one of the reasons why the tools and methodologies are not widely used. We analyzed the decision criteria of software developers as applied to the tools and methodologies, to clarify whether the difference exists or not. In behavioral economics, there are theories which assume people have biases, and they do not always act reasonably. In the experiment, we made a questionnaire based on behavioral economics, and collected answers from open source software developers. The results suggest that developers do not always act to maximize expected profit because of the certainty effect and ambiguity aversion. Therefore, we should reconsider the evaluation criteria of tools such as the f-measure or AUC, which mainly focus on the expected profit.

Fu-Rin-Ka-Zan: Quantitative Analysis of Developers' Characteristics Based on Project Historical Data

In software development, multiple developers compose a team, and perform a development process. To succeed the development, understanding developers characteristics are needed. However, there is no way to measure the characteristics of the developer by quantitative analysis. Therefore, a project manager often assigns team members based on his/her own sense, considering experience year of them. This paper proposes a measurement framework for developers characteristics using quantitative historical data. The proposed framework is useful for measuring developers characteristics and building a team based on quantitative analysis. We collected historical data from a PBL project for graduate students, and applied our framework to the collected data. As a result, our framework measured developers characteristics suitability in our subjective view.

How we resolve conflict: an empirical study of method-level conflict resolution

Context: Branching and merging are common activities in large-scale software development projects. Isolated development with branching enables developers to focus their effort on their specific tasks without wasting time on the problems caused by other developers changes. After the completion of tasks in branches, such branches should be integrated into common branches by merging. When conflicts occur in merging, developers need to resolve the conflicts, which are troublesome. Goal: To support conflict resolution in merging, we aim to understand how conflicts are resolved in practice from large-scale study. Method: We present techniques for identifying conflicts and detecting conflict resolution in method level. Result: From the analysis of 10 OSS projects written in Java, we found that (1) 44% (339/779) of conflicts are caused by changing concurrently the same positions of methods, 48% (375/779) are by deleting methods, 8% (65/779) are by renaming methods, and that (2) 99% (771/779) of conflicts are resolved by adopting one method directly. Conclusions: Our results suggest that most of conflicts are resolved by simple way. One of our future works is developing methods for supporting conflict resolution.

Web search behaviors for software development

Software developers often use a web search engine to improve work efficiency. However, web search skill (i.e., efficiency to find an appropriate web site) is different for each developer. In this research, we try to clarify better web search behavior. To analyze web search behavior in programming, we made some questions about programming, and subjects solved the questions. The questions are based on Java language. Based on our experiment, to enhance the effectiveness of the web search, we suggest (1) do not read many search result pages without changing the key phrase, (2) read search result pages or the destination web pages linked to the search results carefully, before making new search, (3) Use new keywords which are not used before, when making a new key phrase.