Explainable Software Bot Contributions: Case Study of Automated Bug Fixes

In a software project, esp. in open-source, a contribution is a valuable piece of work made to the project: writing code, reporting bugs, translating, improving documentation, creating graphics, etc. We are now at the beginning of an exciting era where software bots will make contributions that are of similar nature than those by humans. Dry contributions, with no explanation, are often ignored or rejected, because the contribution is not understandable per se, because they are not put into a larger context, because they are not grounded on idioms shared by the core community of developers. We have been operating a program repair bot called Repairnator for 2 years and noticed the problem of "dry patches": a patch that does not say which bug it fixes, or that does not explain the effects of the patch on the system. We envision program repair systems that produce an "explainable bug fix": an integrated package of at least 1) a patch, 2) its explanation in natural or controlled language, and 3) a highlight of the behavioral difference with examples. In this paper, we generalize and suggest that software bot contributions must explainable, that they must be put into the context of the global software development conversation

Usability discussions in open source development

The public nature of discussion in open source projects provides a valuable resource for understanding the mechanisms of open source software development. In this paper we explore how open source projects address issues of usability. We examine bug reports of several projects to characterise how developers address and resolve issues concerning user interfaces and interaction design. We discuss how bug reporting and discussion systems can be improved to better support bug reporters and open source developers

Why do commercial companies contribute to open source software?

This is the post-print version of the Article. The official published version can be accessed from the link belowMany researchers have pointed out that the opensource movement is an interesting phenomenon that is difficult to explain with conventional economic theories. However, while there is no shortage on research on individuals’ motivation for contributing to opensource, few have investigated the commercial companies’ motivations for doing the same. A case study was conducted at three different companies from the IT service industry, to investigate three possible drivers: sale of complimentary services, innovation and open sourcing (outsourcing). We offer three conclusions. First, we identified three main drivers for contributing to opensource, which are (a) selling complimentary services, (b) building greater innovative capability and (c) cost reduction through open sourcing to an external community. Second, while previous research has documented that the most important driver is selling complimentary services, we found that this picture is too simple. Our evidence points to a broader set of motivations, in the sense that all our cases exhibit combinations of the three drivers. Finally, our findings suggest that there might be a shift in how commercial companies view opensource software. The companies interviewed have all expressed a moral obligation to contribute to open source

Exploring usability discussions in open source development

The public nature of discussion in open source projects provides a valuable resource for understanding the mechanisms of open source software development. In this paper we explore how open source projects address issues of usability. We examine bug reports of several projects to characterise how developers address and resolve issues concerning user interfaces and interaction design. We discuss how bug reporting and discussion systems can be improved to better support bug reporters and open source developers

Are developers fixing their own bugs?: Tracing bug-fixing and bug-seeding committers

This is the post-print version of the Article. The official published version can be accessed from the link below - Copyright @ 2011 IGI GlobalThe process of fixing software bugs plays a key role in the maintenance activities of a software project. Ideally, code ownership and responsibility should be enforced among developers working on the same artifacts, so that those introducing buggy code could also contribute to its fix. However, especially in FLOSS projects, this mechanism is not clearly understood: in particular, it is not known whether those contributors fixing a bug are the same introducing and seeding it in the first place. This paper analyzes the comm-central FLOSS project, which hosts part of the Thunderbird, SeaMonkey, Lightning extensions and Sunbird projects from the Mozilla community. The analysis is focused at the level of lines of code and it uses the information stored in the source code management system. The results of this study show that in 80% of the cases, the bug-fixing activity involves source code modified by at most two developers. It also emerges that the developers fixing the bug are only responsible for 3.5% of the previous modifications to the lines affected; this implies that the other developers making changes to those lines could have made that fix. In most of the cases the bug fixing process in comm-central is not carried out by the same developers than those who seeded the buggy code.This work has been partially funded by the European Commission, under the ALERT project (ICT-258098)