Voting for bugs in Firefox: a voice for Mom and Dad?

Voting for bugs in Firefox: a voice for Mom and Dad? Jean-Michel Dalle, Matthijs Den-Besten To cite this version: Jean-Michel Dalle, Matthijs Den-Besten. Voting for bugs in Firefox: a voice for Mom and
of 13
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Voting for bugs in Firefox: a voice for Mom and Dad? Jean-Michel Dalle, Matthijs Den-Besten To cite this version: Jean-Michel Dalle, Matthijs Den-Besten. Voting for bugs in Firefox: a voice for Mom and Dad?. Pär Agerfalk, Cornelia Boldyreff, Jesus M. Gonzalez-Barahona, Gregory R. Madey, John Noll. Open source software: new horizons, Springer, pp.73-84, hal HAL Id: hal Submitted on 7 Jan 2016 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d enseignement et de recherche français ou étrangers, des laboratoires publics ou privés. Distributed under a Creative Commons Attribution 4.0 International License Voting for bugs in Firefox: A voice for Mom and Dad? Jean-Michel Dalle 1 and Matthijs den Besten 2 1 Université Pierre et Marie Curie, Paris 2 Ecole Polytechnique, Paris Abstract. In this paper, we present preliminary evidence suggesting that the voting mechanism implemented by the open-source Firefox community is a means to provide a supplementary voice to mainstream users. This evidence is drawn from a sample of bug-reports and from information on voters both found within the bug-tracking system (Bugzilla) for Firefox. Although voting is known to be a relatively common feature within the governance structure of many open-source communities, our paper suggests that it also plays a role as a bridge between the mainstream users in the periphery of the community and developers at the core: voters who do not participate in other activities within the community, the more peripheral, tend to vote for the more user-oriented Firefox module; moreover, bugs declared and first patched by members of the periphery and bug rather solved in I mode tend to receive more votes; meanwhile, more votes are associated with an increased involvement of core members of the community in the provision of patches, quite possibly as a consequence of the increased efforts and attention that the highly voted bugs attract from the core. 1 Introduction Firefox is an open source project that explicitly tries to cater to the needs of a mainstream audience. Judging by its market share, as estimated for instance by the firm StatCounter (, Firefox is succeeding. What might explain this success? To a large extent it is due to the leadership of people like Blake Ross, Dave Hyatt and Asa Dotzler and to their apparently correct judgement in deciding which features and bugs deserve the highest priority for development. In addition, however, we expect that the success is due to explicit mechanisms that have been put in place in order to make sure that the needs of mainstream users are assessed and addressed correctly. Voting for bugs in the Bugzilla bug tracking system is one such mechanism. Voting for bugs is of course not unique to Firefox. It is a feature of the Bugzilla bug tracking system that has been activated by many of the projects who use it. Moreover, it is generally assumed that some sort of voting is a standard element of the open source software development model (see, e.g., [11]). Yet, apart from the governance of Apache [10] and Debian [12], there 2 Jean-Michel Dalle and Matthijs den Besten are to our knowledge surprisingly few explicit analyses or even descriptions of voting procedures in free/libre open source software communities. In her analysis of the emergence of voting procedures in Debian, O Mahony focuses on the greater efficiency and transparency that is provided by voting compared to consensus based collective decision making usually dominant in small groups and presents the introduction of voting as a reaction to the increases in scale and scope of the Debian enterprise. Voting can however be useful even in small groups: see for example the seminal paper on collective problem identification and planning by Delbecq and Van De Ven [4], who propose a model of an effective group process in which the first phase of problem exploration is concluded with a vote. This, they note, serves to make the results of the exploration explicit and create pressure for change on the people who will be responsible for resolving the problem. Here voting is not just about representation, it is also about getting heard. In this context it might be useful to ponder the framework that Hirschman [5] developed on the means by which patrons can influence their organizations. Patrons have basically two options: either they leave the organization and buy or produce with a competitor ( exit ), or they express their concerns more explicitly through channels that might be provided by the organization ( voice ). In open source software development, the primary mechanism for exit is forking [9] and the primary mechanism for voice is to show code by proposing patches [1]. For mainstream users such as mom and dad, however, neither forking nor patching is a realistic option, as they typically do not have the skills to do either. Since Firefox precisely wants to be a product for mom and dad [6], other options have to be found: exit can be implemented by switching to other browsers like Internet Explorer, Safari, Opera, and Chrome. For voice, voting might be an appropriate answer. In what follows, we present circumstantial evidence to support our conclusion that voting for bugs in Firefox is a means to provide a voice to mainstream users. This evidence is drawn from a sample of bug-reports maintained by Mozilla s Bugzilla and from explicit information on voters found at the same site. We present results regarding voters and bugs in sections 4 and 5, respectively. We present some more background information on our research in section 2 and describe our sampling strategy in section 3. 2 Background This paper is number four in a succession of papers that we have presented at OSS conferences. In the first paper, presented in Limerick in 2007 [2], we analyzed bug reports from Mozilla and found that there are some bugs that take exceedingly long to resolve and that part of the reason for the existence of these superbugs, as we named them, could be related to the insufficient provision of contextual elements such as screenshots in the bug threads. The second paper, presented in Milan in 2008 [3], analyzed bug reports that are associated with Voting for bugs in Firefox 3 the Firefox branch and exploited the existence of the so-called CanConfirm privilege the privilege to declare bugs as new given that the initial status of bugs is unconfirmed by default to distinguish between core and peripheral participants within bug resolution processes and inquired whether various variables could influence the speed at which new and unconfirmed bugs were patched. In the third and latest paper, presented in Skövde in 2009 [8], we used text mining techniques to arrive at a further characterization of participants within the core and the periphery of the Firefox community, stressing notably the fact that members of the core tend to use to pronoun We disproportionately while members of the periphery, conversely, seem to prefer to use I. By focusing on voters this paper tries to exploring an additional layer of the onion model of the Firefox community. To echo the language we used in our 2008 paper, while the likes of Blake Ross and Dave Hyatt clearly belong to the inner core, the periphery is probably mostly populated by alpha-geek users that is, exactly by those people who Ross and Hyatt professed to ignore in Firefox development [6]. Mom and dad are not there. If at all, they are more likely to be among the outer periphery of people who are simply voting and contributing very little otherwise. This line of inquiry obviously owes a lot to the pioneering work by Mockus et al. [10] and also to subsequent work by Ripoche [13], who established bug reports as an object of study. Together with others, e.g. [14], we continue to exploit this extremely rich source of information. Conceptually we have been inspired by the analysis of MacCormack at al. [7], who argue that it was necessary to make the existing code that was left by Netscape more modular before Mozilla could attract patches from the periphery. We wonder here whether votes could constitute another element which could help to explain how Firefox could turn the unwieldy open source project that Mozilla had become into the sleek browser for the mainstream market that we have now. 3 Sampling Method For our analysis we constructed two types of data-sets. The first type relates to bugs, which may or may not have attracted votes, and concerns the history of the bug resolution process as it is recorded by Bugzilla as well information about the bugs that can be found in the logs of the cvs code repository. The second type concerns information that is stored in Bugzilla about the activities of the people who have voted for one or more bug. For each type we have obtained several sets and sub-sets of data based on three criteria: first of all, we are interested in bugs for which we can assume that they have had an impact on the Firefox code-base in the sense that they are mentioned in the commitcomments and the cvs repository; secondly, we are interested in bugs that have received votes; and finally, we are interested in bugs that Bugzilla associates with the Firefox project. Similarly, we are interested in people who voted for 4 Jean-Michel Dalle and Matthijs den Besten bugs which eventually found their way into the cvs; we are also interested in the other bugs they voted for; and we are interested in the people who voted with them on Firefox bugs. Figure 1 is a Venn diagram which illustrates this admittedly somewhat complex constellation of sets. Our main interest is in the intersection of bugs from cvs that have been voted on and are also officially associated with Firefox as well as in the people who have voted for this particular set of bugs. Other than that we also have some interest in the other subsets formed by the intersection of the three criteria in order to be able to compare and contrast with what we find in our main set. Fig. 1. Sampling of bugs: appear in the code base (cvs); among them 3787 have attracted at least one vote (Votes cvs) and 418 among these are associated with the Firefox project (Firefox Votes cvs). In practice we followed a procedure similar to snowball sampling in order to obtain our sets and subsets of bugs and voters. We started with the bugs that we found in the logs of our copy of the Mozilla s cvs archive concerning the code for Firefox up until version 2.0. Only a small subset of these bugs, some 10%, has ever attracted a vote. Associated with those bugs is a list of all people who have cast a vote (people can also retract there vote later; in that case they fall through our net). Our next step was to retrieve all those lists and compile a list of cvs voters constituted by union of all sets of voters contained in these lists we found of them. The list of voters that is attached to the bugreports in Bugzilla also contains, for each voter, a link to a voter-page that lists all the bugs the voter in question has voted for split according to the project with which Bugzilla associates the bug. As far as we can tell, this project field is a new data element in the bug-reports that was not yet displayed in the original bug-reports that constitute the cvs-set of bugs. That is why we do not have such project-data for most of the bugs. Nevertheless via the voter-pages we can determine the project for those bugs for which at least one vote was cast. Contrary to what one might assume just a fraction of the bugs that we associate with code in the Firefox-branch of the Mozilla cvs are associated with Firefox by Bugzilla as well. Partly, this may be due to misattribution from our Voting for bugs in Firefox 5 part, but mostly this seems to be a reflection of the fact that Firefox shares code with other applications and the fact that it is based on code that was developed earlier for other projects. In addition to the project affiliation of cvs bugs the voter-pages also give the project affiliation for bugs that did not make it into that set that is, bugs that did get votes but where not mentions in the commit-comments we looked at. The union of all these bugs constitutes the voter-set of bugs. We did not retrieve the complete Firefox-set of bugs, but we do not which part of the voter-set overlaps with it and that another part of the cvs-set should do as well. Finally, our set of Firefox-voters is by looking at the voter-lists of all bugs in the voter-set that are associated with Firefox through Bugzilla and taking the union of the sets of voters listed in those lists. Table 1 gives a short summary of the manner in which we obtained our sets described above. Table 1. Summary indication of source of the main sets of bugs and voters. CVS Votes Firefox Bugs Bugs associated with Firefox code before version 2.0. All bugs that received one or more votes by voters on the cvs bugs. All the bugs associated with Firefox in the listing of bugs per voter. Voters Union of lists of voters on bugs in set defined in previous column. As above, ceteris paribus. Another and, for now, final detail about the data preparation concerns the way we link voter-identities with other activities by the same people in the bug resolution process. For this we rely on the fact that up until recently the voters as well as participants to the bug forum discussions, bug-reporters, bugassignees, etcetera, were identified by their address. Hence we could assign various bug-activities to the voters by matching these addresses. This method works fine for the bugs that we focus on for this study. However, studies concerned with the most recent bugs would not be able to apply this method as Bugzilla has moved to enhanced identity management and does no longer provide the full address for voters. 4 Characterizing Voters A first dimension along which voters can be distinguished from non-voters, reported in Table 2, is with respect to both groups status in the community. Table 2 is a contingency table comparing community status and voting activity of participants in the bug resolution process for the intersection of 418 bugs with the following properties: they appear in the cvs; they have attracted votes; and they are associated with Firefox. As participants, we consider people 6 Jean-Michel Dalle and Matthijs den Besten Table 2. Number of voters by status for participants in the resolution of bugs which have received at least one vote, are mentioned in the cvs, and are associated with the Firefox project (n = 2968; χ 2 = 366, df = 3, p-value = 5.243e 79 ). Status Unconfirmed New Both Other Total Vote No Vote who have either contributed at least one comment to at least one discussion thread or who have cast at least one vote for these bugs. Among the 418 bugs of interest, this definition yields a total of 2968 participants, 1681 of whom have cast a vote and 1755 of whom have written at least one message, which implies that 1213 participants have voted but never written a message. A first conclusion that can be drawn from these numbers, then, is that most voters do not engage in other activities. If we go one step further and check participation on a bug-by-bug basis, this finding becomes even more pronounced: typically, voters who are active in the bugs in the set tend to engage in this activity on bugs for which they did not vote. In order to gauge the status of participants we rely on the CanConfirm privilege mentioned earlier. In particular, we check for each participant whether he or she has ever declared bugs contained in the set of bugs that appeared in the cvs logs. For those participants who did declare bugs we look at the initial status of those bugs. If all the bugs that a participant declared start with status new the participant is considered to belong to the core; if all the bugs start with status unconfirmed the participant belongs to the periphery; if some bugs start with unconfirmed and others with new the participant is considered to be a freshly joined or a freshly expelled member of core; finally if the participant has not declared any bug, he or she is classified as member of the outer-periphery, here denoted as Other. Given all this, the main conclusion from table 2 is that the people who cast a vote are mostly, yet not exclusively, outsiders. Interestingly, this finding also holds for the status of the people who voted for any one of the bugs that appeared in the cvs logs. Of the voters among these 3787 bugs have never declared a bug while only 283 participants have had all the bugs they declared accepted as new right-away. Furthermore, when we consider the top 1000 most active voters, 688 among them can still be classified as outsiders while only 36 belong to the core. Figure 2 gives some indications about the voting activities of the people who have cast a vote for at least one of the 418 bugs in the latter sample. It shows the distribution of the number of bugs to which people have cast their vote as split according to projects and status. Actual outsiders, with status Other, tend to declare pure Firefox bugs while contributors with another status disperse their votes much more. Voting for bugs in Firefox 7 SeaMonkey Toolkit other 10^3.0 10^2.5 10^2.0 10^1.5 10^1.0 bugs 10^3.0 Core Firefox MailNews.Core 10^0.5 10^0.0 10^2.5 10^2.0 10^1.5 10^1.0 10^0.5 10^0.0 B N O U B N O U B N O U Fig. 2. Distribution of number of bug declared by status per project. B = both; N = new; O = other; U = unconfirmed. total Core Firefox MailNews Core SeaMonkey Toolkit other total e+00 1e+05 2e+05 3e+05 4e+05 id 0e+00 1e+05 2e+05 3e+05 4e+05 5e+05 id Fig. 3. Cumulative sum of bugs per project against bug-id; in the plot on the left specifically for Firefox (see text). 8 Jean-Michel Dalle and Matthijs den Besten Figure 3 tries to shed some light on the timing of bug activity. Votes do not come with timestamps in the Bugzilla records, but we know that bug-ids are assigned sequentially. Figure 3 shows how many bugs had received votes before a given bug id against the sequence number that is used to identify them and this gives a rough indication about the distribution of voting over time. On the left is shown this distribution for bugs with votes and that appear in the cvs logs: typically, a steady proportion of bugs attract votes; not all projects are active at the same time; and some, for instance SeaMonkey, are gradually abandoned while others take off. The right graph focuses on bugs associated with the Firefox project more in particular. This graph includes the bugs that were voted on by the people who voted for the 418 Firefox cvs bugs that are represented in purple in the middle of the graph. The picture that appears is one of a very loyal electorate. Note that we are looking at all the votes that were cast by people who voted during the specific time window which is occupied by the 418 Firefox cvs bugs. Normally, one would expect a certain level of turnover among these people, implying that number of people who continue to vote would decrease over time. Nevertheless the ratio between increase in the number of bugs with votes and the increase in the total number of bugs looks more or less stable. So either people continue to vote, or abandonment of the project by some people is compensated by increased voting activity of the people who remain. In addition, the slope might also have been influenced by a change in the proportion of bug-ids that are attributed to the Firefox project. 5 Analyzing
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks