Background: In recent years, the use of container virtualization technology has been rapidly spreading to speed up software release and operation. In general, a containerized application image (e.g., Docker image) consists of multiple reused OSS packages. To reuse OSS, it is necessary to comply with the OSS licenses. Although there have been many studies on OSS license detection and license compatibility among OSS packages, but to the best of our knowledge, there is no study tackled with incompatible license problems among OSS packages in a container image. Aims: In this paper, we conduct a preliminary analysis to clarify the extent to which Docker images contain OSS license incompatibility problems. Method: We analyze 776 Docker images published on GitHub to determine whether license incompatibilities among OSS packages exist. Results: The analysis showed that a total of 2,167 software packages were used in the 776 Docker images. The majority of the software packages (71.3%) are compatible with the GPL family, but a non-negligible number of software packages (28.7%) are not compatible. The analysis also showed that 457 (58.9%) of the 776 images had GPL-related incompatibility problems. Conclusions: Unlike traditional software development, in which software packages to be reused are explicitly combined, Dockerfile creators who build and distribute Docker images might be less aware of the risks related to compatibility between OSS licenses. Our results are useful as information to improve the awareness of Dockerfile creators, and also indicates the necessity of future studies to detect and prevent the inclusion of license-incompatible OSS packages to container images.

While open source software (OSS) development projects always seek contributions from newcomers to make the projects sustainable, newcomers often face with a challenge of onboarding. For developers with little experience, it is difficult to decide which of the many OSS projects to contribute to and which issues to tackle. To mitigate the barrier against onboarding, some OSS projects start using a label so called good first issue (GFI) which indicates the issue is easy to resolve and suitable for newcomers to tackle. The final goal of this study is to construct a model for recommending good first issues to help reduce maintainers' manual effort of selecting and labeling issues as GFIs and at the same time to help find GFIs suitable for each newcomer. Toward the final goal, we analyze GFIs in GitHub to deeply understand the current state of the GFI mechanism and its impact on new members' onboarding. This paper reports a result of our preliminary analysis of GFIs, based on 9,475 GFIs collected from 11 famous OSS projects in GitHub. We find that (1) developers who have resolved GFIs have 92 fewer median PR (pull request) posts than developers who have resolved regular issues (i.e., developers tackling GFIs have less experience, compared to other developers), (2) on average, GFIs are resolved 32.5% more than regular issues (i.e., GFIs are easier to resolve. The dataset of GFIs might be able to be used as a training set for recommending GFIs to developers with less experience), and however (3) the percentage of developers who keep contributing to the same project even after resolving GFIs varies greatly from project to project (24.9% to 83.9%) (i.e, GFIs guide newcomers' onboarding only in particular projects). Based on the analysis result, we discuss the contents of GFIs which tend to keep newcomers on OSS projects.

Stack Overflow has been already recognized as an indispensable CQA (Community Question and Answering) service for developers. However developers as questioners sometimes cannot get any answers or they only can get incomplete answers to resolve their questions, since over several thousands of questions and answers are posted on a daily basis and expert developers are currently facing with a difficulty in finding questions which can be better or best answered by them. In order address the issue, our study aims at developing a bot that helps expert developers find questions matching each developer's expertise. The existing study [8] proposed a promising approach to the expert recommendation for CQA services, based on PMF (Probabilistic Matrix Factorization) algorithm. In order to improve the accuracy of the expert recommendation, in this paper we present our approach which combines the PMF (Probabilistic Matrix Factorization) approach and a term expansion techniques using word embeddings. As a result of an experiment comparing our approach with the existing approach only based on PMF, we show that our approach based on PMF and the term expansion with Word2vec and fastText slightly outperforms the existing approach only based on PMF.

This paper introduces a tool called CCT (Code Clone Tracer) which is designed to help practitioners and researchers analyze the impacts of human/social factors on software quality in creating and reusing code clones. CCT tracks a history of created and reused code clones for all the revisions in a distributed version control system such as Git. The tool also has features to analyze the relationship between bug-inducing changes and developers, working together with a bug tracking system such as Bugzilla and JIRA. This paper reports our pilot case study where CCT is applied to three open source projects (RxJava, c:geo, and Jackson databind). The results of the case study indicated that a small number of particular developers were involved in many of clone changes to resolve issues.

In this study we focus on the misclassification of issue reports regarding software performance in OSS development. IEEE Std 610 [1] defines performance as “The degree to which a system or component accomplishes its designated functions within given constraints, such as speed, accuracy, or memory usage.” The definition implies that there is no rigorous criteria nor quantitative measure to detect a software performance problem, but rather it relies on a subjective judgement. OSS users sometimes mistakenly report a performance bug as a request for improving software performance and sometimes mistakenly report an improvement request for fixing a performance bug. The misclassification of report types can impedes the efficient bug-fix process in OSS development, since OSS developers preferentially spend time fixing bugs which might be improvement requests (i.e., not bugs) in reality. In this paper we strengthen our previous study for the Apache Wicket project by manually inspecting 1,000 bugs and 1,000 improvement requests respectively to more precisely understand the impacts of the misclassification on the bug-fix process in OSS development.

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).

Since increasing complexity and scale of modern software products imposes tight scheduling and resource allocations on software development projects, a project manager must carefully triage bugs to determine which bug should be necessarily fixed before shipping. 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 report our pilot study on high impact bugs, which classifies bugs reported to four open source projects into six types of high impact bugs.

An efficient bug management process is critical for the success of software projects. Prior work has focused on improving this process, for example, by automating bug triaging, detecting duplicate bugs, and understanding the rationale for re-opening bugs. This paper continues this line of work by exploring the people who are involved in the bug management process. In particular we develop four patterns that distill the different relations between the people involved in the process: the reporter, triager, and fixer of a bug. Through a case study on the Eclipse Platform and JDT projects, we demonstrate that these patterns have an impact on the efficiency of the bug management process. For example, we find that using our patterns project personnel can improve their efficiency through better communication about bugs before assigning them.

Time zone, different work schedule, limited real-time information sharing, steep learning curve and different personal specialties, these are common limitations in the collaborative studies, especially when a researcher has just been introduced to the research field or working in a different environment (i.e. Internship programs). This paper introduces you with the experiences, challenges, difficulties, lessons learned, common fallacies and pitfalls in the collaborative software engineering research through the experience of 2-months collaborative research program between Kasetsart University in Thailand and Nara Institute of Science and Technology in Japan. Good mentoring and flat-style communication between professors and students are good indicators of the high quality result in the internship program. These information can be useful to professors, young researchers and internship students who will be conducting researches in such manner.

There are many roles to play in the bug fixing process in open source software development. A developer called ``Committer'', who has a permission to submit a patch into software repository, plays a major role in this process and hold a key to the successfulness of the project. In this work, we have observed each committer activities from the Eclipse-Platform bug tracking system and version archives. Despite the importance of committer's activities, we suspected that sometimes committers can make mistakes, which have negative consequences to the bug fixing process. Our research focus on studying the consequences of each committer's activities to this process. We collected each committer's historical data and evaluated each of them by comparing the more cautiousness to less cautiousness committers. Then we looked deeper into each committer's characteristics to see the reasons why some committers tend to make mistakes more than the others. From our results, we would like to make a humbly suggestion to the OSS's committers to be aware of their importance to the projects and be cautious before doing their jobs.

Patch submission has been known as one of the most important activities to sustain the open source software (OSS). The patch archive can be analyzed to procure many benefit cognizance for supporting the OSS project works. The recent models and methods that analyze the patches acceptance are quite rack of comprehensive; hence, complex activities such as a committer portioning the Passed QA patch out and accept are still excluded from the analysis. Therefore, the results derived from those methods would be inadequate to conclude the actual patch acceptance. In this research, we introduce an algorithm for analyzing patch acceptance including the partial and gradually accepted conditions. Validating our algorithm, we present our methods for indicating the partial and gradual application of the Passed QA patch between either mailing list and SVN or Bugzilla and CVS which are the commonly deployed patch-activities related system. We studied on two well known OSS projects; Apache HTTP and Eclipse Platform. We obtained a fascinating conclusion that larger patches have more confident to be accepted than the smaller contradicted to other analysis that came from the recent methods.

In this paper, we introduce SCACS, a Social Context-Aware Communication System that facilitates face-to-face communications between old-timers and newcomers in a research community. SCACS provides users with information on coauthor relationships collocutors have in order to help users understand collocutors' research background and relations to own. While the system works so as to help newcomers get better understandings on the research community by meeting old-timers---central to the community, it also works to recruit newcomers who might bring new ideas and research topics, in order to make the community sustainable. One of the contributions of the paper is to show an example of a fusion of social networking and ubiquitous computing technologies, which have attracted a considerable amount of attentions in the last few years. In contrast to exploiting social interactions in real world to enhance experiences of social networking services in virtual world, SCACS collects information on social networks (e.g., coauthor relationships networks) from virtual spaces (that is, databases), and then visualizes them to facilitate face-to-face communications among people in physical environments through using wearable interfaces. Instead of providing users with complex social network graphs, SCACS transforms network graphs into tree maps so that users are able to better understand the community.

The creation of modern software systems requires knowledge from a wide range of domains: application domains, computer hardware and operating systems, algorithms, programming languages, vast amount of component libraries, development environments, the history of the software system, and users. Because few software developers have all the required knowledge, the development of software is no longer confined to an individual but has to rely on distributed cognition by reaching into a complex and networked world of information and computer mediated collaboration. Knowledge collaboration has thus become an important aspect of software development.

The scale-free network shown in the small world phenomenon indicates that our human society consists of a small number of people who play the role of hubs linked with many nodes (persons) and a large number of people as nodes linked with few nodes. From our analysis of a large-scale online community - SourceForge.net - which has a large number of developers and projects, we have found that SourceForge also exists as a scale-free network. That is, only a minority of developers joins many projects and has rich links with other developers, while the majority joins few projects and has very limited social relations with others. The goal of our study is to build a system that supports knowledge collaboration in a large-scale online community of software development projects. In this paper, we discuss the challenges of supporting knowledge collaboration in such a large online community that is a scale-free network and then introduce the prototype system called D-SNS (dynamic social networking system).

The goal of our research is to develop computer systems that support designers' collective creativity; such systems support individual creative aspects in design through the use of representations created by others in the community. We have developed two systems, IAM-eMMa and EVIDII, that both aim at supporting designers in finding visual images that would be useful for their creative design task. IAMeMMa uses knowledge-based rules, which are constructed by other designers, to retrieve images related to a design task and infers the underlying "rationale" when a designer chooses one of the images. EVIDII allows designers to associate affective words and images, and then shows several visual representations of the relationships among designers, images and words. By observing designers interacting with the two systems, we have identified that systems for supporting collective creativity need to be based on design knowledge that (1) is contextualized, (2) is respectable and trustful, and (...