Bug management in open source projects

Bug management in open source projects Thomas Basilien, Roni Kokkonen & Iikka Manninen Abstract 1. Introduction 2. Bug management in general 2.1 Bug management in proprietary projects 2.2 Project management and personnel 2.3 Communication 2.4 Usage of tools 2.5 Pace of development 3. Usage of bug trackers 3.1 Defect Handling in Medium and Large Open Source Projects 4. Community involvement in bug management 4.1 Communities in open source project 4.2 Organization inside communities 4.3 Case of commercial software 5. Conclusions References

Abstract Bug management is an important issue in the development of a software. We wanted to understand how this whole process was working in open source projects and then compare it to how it is done in commercial projects. Our paper will use studies based on a big variety of project, either in size, type, in open source software as in closed software. We will focus on three points: the bug fixing process itself, the use of bug tracker to manage bugs, and the impacts of the community both in reporting bugs and fixing them. The key differences that we found between open source projects and commercial projects were in project management, personnel, communication and speed of development. Project management methods differ between different open source projects. However, as a generalization most OSS projects are developed in a distributed way and they have more flexibility in both personnel and structure. Both open source and commercial do use bug tracking tools to manage their bugs, but in open source projects they are a very central part of bug management. In the process we will show that the community have a huge impact on this process and that the closed software firms started to aim to have this kind of system.

1. Introduction Like all software projects, open source projects come in all different sizes. Some of the more widely used examples of open source software are Apache web server, Mozilla browser and Linux kernel (Gunes Koru & Tian, 2004). Even now, ten years later, these continue to be widely used. For instance, nearly 40 % of websites are served by Apache based servers (Builtwith, 2014). In web browsers, Mozilla's Firefox is the third most popular browser (StatCounter, 2014). In operating systems, Linux is often the only open source operating system to be mentioned when usage statistics are described (NetMarketShare, 2014). Thus, it can be reasonably deduced that wide amount of academic literature should exist that discusses these larger open source projects. In this research paper, we are taking a closer look on these larger open source projects. We have chosen bug management as our broad topic and our aim is to investigate how bugs are managed in these types of open source projects and compare it to the bug management done in proprietary projects. We have formulated the following general research question: Does bug management in open source projects differ from proprietary projects? Firstly, we aim to research the generic details of the bug fixing process in open source projects. Secondly, Gunes Koru and Tian (2004) explain that in medium and large sized open source projects a more organized approach is needed for bug management and as a result these projects use bug tracking tools to help in managing bugs. This use of bug tracking tools or systems in bug management is also reported in studies by Ohira, Hassan and Osawa (2012) and Ardagna, Banzi, Damiani and Frati (2009). Our research goal is then to determine how bug trackers are used in large projects. Finally, we aim to find out how the community is involved in bug management process and how it differs from community involvement in proprietary projects and what those differences bring.. 2. Bug management in general In this chapter we are going to tell about bug management in open source projects and compare it to proprietary projects. First, we begin by outlining the importance of bug management and then we explain how a typical bug fixing process works in a commercial

company. After that, we compare the process with how large open source projects do the same tasks. The areas that we have included are project management and how it affects bug fixing, personnel, communication, tools and pace of development. Baysal, Holmes and Godfrey (2012) define bug reporting and fixing as being an essential part of the software development process. Ohira, Hassan and Osawa (2012) note the importance of efficient bug management process; they describe it as critical for the success of a project. Zhang, Khomh, Zou and Hassan (2012) tell that bug fixing is a major part of software development and that most of the costs in a project are spent on bug fixing. We can thus see that bug management is a very integral part of software development also in open source projects. First of all, because of the inherent openness of open source software there often exists a possibility for anyone to take a look on how bug management is handled in a open source project. If somebody wanted to for instance know more about how bug management is done at a large company that develops closed source software it would very likely be not as easy as it is in the case of open source projects. For example, on their websites both Apache and Eclipse feature clear descriptions on how users can submit bugs and how the bug fixing process goes in each project (Apache, 2014; Eclipse, 2014). Overall, this openness of FLOSS (Free/Libre/Open Source Software) also means that academic researchers are able to investigate these systems from different perspectives (Izquierdo Cortazar, 2012). 2.1 Bug management in proprietary projects In their work, Crowston and Scozzi (2008) describe how a bug fixing process works at a commercial software company. In this so called traditional way, the organization structure is defined and the development is not done in a distributed manner; additionally, the produced software is commercial in nature (Crowston & Scozzi (2008). The bug fixing process starts with the customer who reports a problem in software. This report that is sent to the company's response center is delivered either manually by the customer or automatically by the software. The company staff then looks at a database of known bugs of the relevant software. If a fix is found the staff will then send it to the customer. If the problem cannot be resolved in this manner the problem is then forwarded to an engineer. The engineer's job is to try to reproduce the problem and try to identify the cause for it, and in which process more information might be requested from the customer. In those cases where the bug is real, it is forwarded to a manager who is responsible for the module that is affected by the bug. After that, the bug is assigned to a software engineer who designs a fix. This stage also involves making sure that the fix does not affect any other modules negatively. Finally, the bug fix is written, tested, integrated and released. (Crowston & Scozzi 2008.)

2.2 Project management and personnel One sentiment that appears in many papers is the fact that open source software lacks a formal development process. For example, Ahmed, Mohan and Jensen (2014) mention that FLOSS projects follow different development practices, which includes bug reporting, compared to traditional closed source projects. Rahmani and Khazanchi (2010) additionally explain that because there isn't a formal definition of open source development process, there is accordingly a considerable variance between different projects and how they use different practices. However, there are still some common details that can be used to compare proprietary software and open source software. Ohira et al (2012) describe that in an open source project that uses a bug tracking system in its bug management process there are three different types of people involved: the reporter, who reports the bug, triager, often a senior developer who has the authority to assign a bug to a relevant person, and finally the fixer who is responsible for fixing the bug. The triager can also function as a reporter or a fixer. (Ohira et al, 2012.) If we compare this to the bug fixing process used in commercial companies as described by Crowston and Scozzi (2008) there are some differences. The number of parties is clearly smaller in open source projects. Whereas in the commercial bug fixing process there are at least a customer, helpdesk/customer staff and engineers, manager and more engineers. In open source projects, the structure is much simpler, and additionally, one person may function in multiple different roles. However, this does also place more burden on a single individual, which in the case of open source projects is usually a senior developer. Ahmed et al (2014) explain that in open source projects, the people working on the project are often not physically collocated. Rahmani and Khazanchi (2010) also mention the distributed way of working that is used in open source projects, as do Zou and Davis (2008), who note the global collaboration aspect. If we contrast this to the definition given by Crowston and Scozzi, we can see that there is a difference in how the development work is done. Of course, commercial software is also developed in a distributed manner, but in open source s case the distributed method of working seems to be the norm rather than just an option out of many other development methods. 2.3 Communication The distributed way of working also has an effect on communication. In other words, only the biggest and most well established projects and project members have a chance to meet face to face, and even that may only be in conferences. Additionally, this may only apply to a small subset of people working on the project, so communication and coordination will have to

happen in a distributed manner. (Crowston & Scozzi, 2008.) Obviously, this is a difference compared to a commercial project or a company, which should have more resources to allow for closer communication (for example travel or collocated development). However, distributed work could also give an advantage to open source projects over commercial projects. Aranda and Venolia (2009) note that since most communication in open source projects happens electronically it could allow more effective handling of bugs because the information is already available. 2.4 Usage of tools Gunes Koru and Tian (2004) tell that large open source projects need a more organized handling of bugs and by their knowledge most such projects use a bug tracking tool such as Bugzilla. Ardagna et al (2009) also mention that big open source projects will at least implement a bug tracker. In these bug trackers, both users and developers can create bug records. The developers have additional rights to for example change the status of the bug. Bug trackers are not necessarily limited to simply tracking information about bugs or defects since the definition of these terms is very broad. As a result, bug trackers also function as a communication and collaboration medium that helps developers and testers to solve problems. (Gunes Koru & Tian, 2004.) This use of bug tracking systems as a communication tool is mentioned too by Izquierdo Cortazar (2012). Baysal et al (2012) also tell that bug tracking systems in large open source projects such as Eclipse and Firefox function as a central hub for coordination and for gathering informal comments about bug reports and other issues. Crowston and Scozzi do not concretely specify what kind of tools are used in commercial projects. However, in a study conducted by Aranda and Venolia (2009) that investigated how bug fixing is coordinated at Microsoft the use of software repositories such as bug databases is mentioned. Aranda and Venolia (2009) also note that the use of these tools should be similar to other comparable companies (i.e. large companies). Additionally, it would be unreasonable to think that a large company would not use any tools to organize their bug information, so in this case there may not be a big difference between commercial software and open source software. 2.5 Pace of development A difference between commercial software and open source software also exists in the pace of development in regards to fixing bugs. In open source world, bug fixes or patches can be delivered to the users as soon as they are made. In commercial software, the delivery of these patches can often follow a more rigid scheduling where different patches are compiled into bundles that are released according to a predetermined schedule. (Mockus, Fielding &

Herbsleb, 2002.) However, as said before, practices between open source projects vary. For example, as Mozilla has used a more commercial style and disciplined approach for development, the reaction is not as rapid as it is in projects such as Apache (Mockus et al, 2002; Gunes Koru & Tian, 2004). 3. Usage of bug trackers The term bug usually describes software problems. There are many types of software problems and they are often referred to as defects. Tracking, recording and resolving defects is described as defect handling. Defect handling can be very different in many projects, for example in small open source projects bugs can be fixed without making notes of it or making a note in change logs. A mailing list is often used to discuss defects and the possible fixes. Bigger projects with more developers involved usually have more organized bug handling. (Günes Koru and Tian, 2004) The most used program for bug handling is Bugzilla and it s variations. Bugzilla has many functions such as create, store and query bugs via the graphical user interface. You are able to describe the bugs, classify them, generate reports and automatically notify people when a bug s status is changed. All the bugs are stored in a database. Users and developer are able to create bug records but usually only developers have the rights to modify the records. When a bug is recorded, it usually gets an unconfirmed status and a developer can then confirm the bug. On the other hand, as soon as a bug is reported in Android based apps, the bug has the status New. This shows that in the Android projects hosted on Google Code there is no difference between a real bug (which has not been assigned or investigated yet) and an unconfirmed bug (Bhattacharya et al., 2013). It is common that a bug s status changes many times before it is resolved but sometimes the bug s can t be resolved. They are either invalid or they can t be fixed or something else. Bug are fixed by commiting a patch with the fixed source files to the CVS which is a version management system. CVS is very popular in open source projects. The bug number can be written in the commit log so the bug record in Bugzilla is updated with the fixed source files. Projects often have different opinions about what count s as a bug and what kind of information they store in their bug tracker about the bugs. (Günes Koru and Tian, 2004) 3.1 Defect Handling in Medium and Large Open Source Projects Li et al., (2006) studied Mozilla and Apache and their results suggest that memory bugs have decreased in these projects and semantic bugs are the dominant root cause. Their results also indicate that GUI modules account for more than half of bugs in Mozilla. According to the study done by Günes Koru and Tian (2004), people who are workin in open source projects occasionally record false positives (not actually a defect), feature enhancements, and tasks

as defects. They also found out that source code dominates as the subject of defect records, following by design documents and requirement documents. Their study also revealed that defects are often found in user documentation such as manuals, guides, and tutorials. Open source projects usually either employ a defect database and defect tracking tool right after starting the project or inherit them from other projects or previous releases. Defects are recorded rather consistently and the defect records are almost always complete. (Günes Koru and Tian, 2004) Günes Koru and Tian (2004) also claims that the relationship between the completeness of defect records and consistency of defect recording indicates the discipline exercised in defect handling. In the ideal case, developers and testers consistently record every defect they discover and fix, completing all required fields for each record. They argue that there s generally a positive correlation between consistency and completeness (Günes Koru and Tian, 2004). Most bugs are reported by a relatively small developer community rather than end users (Mockus et al., 2002). Günes Koru and Tian (2004) explains that open source projects often follow an iterative process or no specific process, the developers use both object oriented and traditional languages, and various types of project data, such as the project schedule, plan, personnel s education and background. They claim that such information can be used to characterize open source projects and customize various models for them. On the other hand, their survey revealed that there s little detailed information collected for analyzing and classifying defect data. Developers and testers usually classify defects according to impact severity because this helps them prioritize defect fixing efforts. (Günes Koru and Tian, 2004) According to Günes Koru and Tian (2004) defect databases and defect tracking tools are generally considered a communication and collaboration medium that helps developers and testers solve whatever they consider a problem. Günes Koru and Tian (2004) claim that code is the main subject of defect records, followed by design documents, requirement documents, and user documentation. Based on their study, they suggest that usually, developers and testers record both prerelease and post release defects. However, they claim that in some projects no distinction exists because development is considered a continuous activity and releases are only perceived as snapshots of an ever evolving product rather than a finished product. Günes Koru and Tian (2004) claim that developers and testers record defects fairly consistently and keep fairly complete defect records, although considerable variability exists among different projects. Some projects, such as Mozilla, are more disciplined. On the other hand, in some projects, if developers can immediately correct a defect without further investigation, they might not feel a need to record this incident. Similarly, if developers and testers think a defect record conveys enough information to fix a defect, they might not complete all the fields. (Günes Koru and Tian, 2004) (Now that we have described the process of handling bug, we will focus on how the community around a sofware impacts all thoses activities

4. Community involvement in bug management In this section we will go through the different kind communities existing around a lot variety of projects, either in size, commercial or open source and how they managed bugs. In their paper, K. Nakakoji, Y. Yamamoto, Y. Nishinaka, K. Kishida and Y. Ye have found a high correlation between the size of a community and the development of the open source software, which means that the quality of a community and his involvement have a huge impact on the software. In this section we will first focus on the panel of community existing in open source projects and how they have evolved over time, then we will concentrate on the different member of the community, their roles in it and how they communicate with each other. And finally we will contrast the open source communities with the commercial communities. 4.1 Communities in open source project There is open source software project of every size, and of every kind, from a video game (GNU Chess) to an IDE (Eclipse) through drivers for Linux. Before focusing on the size of a community, K. Nakakoji, Y. Yamamoto, Y. Nishinaka, K. Kishida and Y. Ye decided first to categorize the kind of community and succeed to classify the software in three types: Exploration Oriented, Utility Oriented, and Service Oriented. Those classifications had the purpose to make more efficient the community depending of the type of software. But the study of K. Crowston and J. Howison (2005) shows that it s not exactly how it happens in real life. After they have examined 120 projects from SourceForge from every kind, they couldn t find any rules who could apply to a project depending on their size and/or their kind, only some predilection. Larger developer team seems to have decentralized communication when smaller one are focused around a leader. We can see that this is a case by case community, depending of the members in it. Thought this not a fixed model, community can grow larger over time, and then can evolve to adapt to this increase in members. We will now look into the people who are part of those communities, their roles and how the community is communicating to solve problem. 4.2 Organization inside communities

In their studies, M. S. Zanetti, I. Scholtes, C. J.Tessone and F. Schweitzer have identified three different members in the community: the core developer, the part time contributor and the users. We will explain for each case their function in the community. The core developers are often the people who first start the project. They are the one who usually fixe the bug, and implement the new features. We could think that this is a team who start the project and make the maintenance over time, but S. Krishnamurthy (2002) shows in a study based on 100 open source projects, that actually the average number of core developer is one, with a median at four. Huge teams exist only for really huge project, who just represent a fraction of all the open source software. The core developer are often people working it IT related jobs, and they find a motivation in improving their skills, and around 40% are actually paid to participate in those open source projects (S. Krishnamurthy,2002). If there is more than one core developer, they often share the authority using democracy. Some can naturally gain some over time depending on their work (S. O'Mahony and F. Ferraro, 2007). The part time contributor is usually somebody who starts in the IT world. They want to be part of something bigger, and contribute at the elaboration of something big. They may sometimes provide some fixes for some problems, and their bug reports are more detailed. And finally the user, he will be mostly using the software, and can send bug reports, but which are not often usable. But his feedback is valuable and is taking into account. (R. Sandusky, L. Gasser, and G. Ripoche, 2004). The number of bug report done by simple users who want to help the development of the software are actually sometime a jam in a process. Core developers have to spend some time to figure out what the bug really is, and the common procedure who appear is to discard report who doesn t seem complete. ( J. Anvik, L. Hiew and G. C. Murphy,2005). With such a large number of members, a community has to possess many ways of interacting with each other. But as show the study of J. Anvik, L. Hiew and G. C. Murphy(2005), each open source project has his own personal way of transmitting information. The study is based on very successful projects which uses different ways to communicate. Though there is not one perfect way who stand out, each way have different kind of benefices, but they always have to make compromises. To illustrate those differences we can use the research of K. Ehrlich and M. Cataldo (2012) where they studied precisely the mechanism of communication of informal information in distributed projects. In a project where there is enough member to split into teams who have specific tasks, the use a shared information channel for all the teams, instead than specific channel for each team, makes the productivity drop. We will now focus on how bugs get reported, which is the most used communication way between the developers and the rest of the community. A paper from D Bertram, A. Voida, S. Greenberg and R. Walker (2010) explain precisely that this database of existing bug are not just data stored, waiting to be used, it is the focal point of communication and coordination between the different party of a project. As we saw before, the majority of the reports are not usable. Other studies point out this problem as the one from M. S. Zanetti, I. Scholtes, C. J.

Tessone and F. Schweitzer (2013), who try to improve the detection of good report. Indeed more than half of the bugs reported are just duplicates of bugs or report who don t allow to figure out what are the bugs. A solution was found to reduce this problem, which is to focus on the report of people who already submit correct bug reports. The same problem is also mentioned in the paper by R. Sandusky, L. Gasser, and G. Ripoche(2004), and they propose a way where they focus more about the classification and organization of the different bug in a network, in order to assign efficiently the tasks to the developer. The community owns a crucial part in the positive development of a software. Everything who was explained earlier was about open source projects. We will now attach more importance to commercial projects, by making some parallel observations. 4.3 Case of commercial software Some papers have studied the difference in the community and the process between commercial and open source project. The purpose was not to find the best way, but rather to spot the difference and evaluate the result. L Grammel (2010) compared the open source project Eclipse and the closed source project IBM jazz. Both of those projects use different way to get feedback from the community. The closed project decided to make the issue trackers available public, which had improved his development. Another study from A. Mockus, R. T. Fielding, J. D. Herbsleb (2002) shows us that the open source community compete (or overtake) with traditional development methods, but each has some advantage. A proposition was to create commercial/open source process hybrids, which would be more performant. As J. West and S. O'Mahony (2005) exposed in their paper, open source is sometime the next step of a closed project. They studied a case where a closed project vista became open source to continue his development through his community. And it is not only one who make this kind of change. A lot of firm developing closed software are backing up open source software. G. Wilson (1999) studied some of those cases (IBM with Apache for example), and also makes the remarks that Linux (developed and fixed by the community) succeed to become more robust than some commercial Unix. The community in open source project never cease to improve itself over time, and even closed software saw the opportunities to use those amazing intellect for themselves. We can also confirm that the help of the community is a mandatory step for the management of bugs, as much as for the detection than for fixing them. 5. Conclusions Bug management is an important part of software development proces and that also applies to open source projects. Bug management in general in open source projects differs

considerably from commercial projects and their bug management. For researchers, open source offers more possibilities because research data is often openly available. In this paper, we compared open source projects and their methods of bug management to more traditionally developed proprietary projects. Open source projects often lack a formal development process so in that sense it is difficult to draw strong concusions because there is a wide variety of development methods between different open source projects. Open source projects can have a more simplified structure compared to proprietary projects. In those projects that use bug tracking systems, three different roles can exist: bug reporter, triager and bug fixer. One single individual, often a senior developer, can also function at multiple roles. This puts more responsibility on a single person compared to a commercial company, which can have multiple layers of engineers and managers. Distributed development is often used in open source projects. This is due to the fact that contributors are often volunteers and are located far apart from each other. Additionally, the lack of resources has an effect when compared to commercial projects. In terms of bug management, the necessity of using electronical communication can be an advantage, as information is always available, such as for example in bug tracking tools. Bug tracking is a big part of open source software development and there are some different tools for it. Most large open source use bug tracking tools to manage their bugs, and the most common one of these tools is Bugzilla. According to the studies, bugs are recorded fairly consistently and bug tracking is quite effective in open source projects. Big projects use bug databases and the tracking tools and if a bug is found, it is reported into the system with the most important details of it. The studies show that bug tracking has developed a lot and it is very effective in open source projects. Bug trackers are used communication and collaboration to exchange information on various issues relating to a particular open source project. In the case of tools, it is presumed that commercial projects also use similar tools in organizing their bug information. Open source projects can benefit from their flexibility by being able to release bug fixes much quicker than traditional proprietary projects, which may need to follow a more rigid approach in releasing patches. The community has also a big role in the process.the fact to have thousands of people willing to participate in a project, who invest themselves from everywhere is the world is a non neglictable labour force. And the closed software firm tends to make some part or the whole project public in order to take a benefice from this formidable resource. Even if the open source project had a less efficient way of tracking bug at the beginning, the willingness of thousand of people to improve a software was enough to overcome this

problem. Now that they had the time to improve the bug tracking system, they are now ahead of closed project managing bugs. References Ahmed, I. Mohan, N., & Jensen, C. (2014). The Impact of Automatic Crash Reports on Bug Triaging and Development in Mozilla. Proceedings of The International Symposium on Open Collaboration (OpenSym 14). Apache. (2014). Bug reporting. Retrieved from http://httpd.apache.org/bug_report.html Aranda, J. & Venolia, G. (2009). The secret life of bugs: Going past the errors and omissions in software repositories. Proceedings of the 31st International Conference on Software Engineering (ICSE 09), 298 308. Ardagna, C.A., Banzi, M., Damiani, E., & Frati, F. (2009). Assurance Process for Large Open Source Code Bases. Proceedings of the International Conference on Computational Science and Engineering (CSE 09), 412 417. Baysal, O., Holmes, R. &, and Godfrey, M. (2012). Revisiting Bug Triage and Resolution Practices. Proceedings of the User evaluation for Software Engineering Researchers (USER) Workshop at the International Conference on Software Engineering (ICSE 12), 29 30. Bettenburg N. and Hassan A. E., Studying the Impact of Social Structures on Software Quality, 2010 IEEE 18th International Conference on Program Comprehension, pp. 124 133, Jun. 2010. Bhattacharya, P., Ulanova, L., Neamtiu, I., & Koduru, S.C. (2013). An Empirical Analysis of Bug Reports and Bug Fixing in Open Source Android Apps. Proceedings of the 2013 17th European Conference on Software Maintenance and Reengineering (CSMR '13), 133 143. Builtwith. (2014). Web Server Usage Statistics. Retrieved from http://trends.builtwith.com/web server Crowston, K. & Scozzi, B. (2008). Bug Fixing Practices within Free/Libre Open Source Software Development Teams. Journal of Database Management, 19(2), 1 30.

Bertram, D., Voida, A., Greenberg, S., & Walker, R. (2010). Communication, collaboration, and bugs: the social nature of issue tracking in small, collocated teams. Proceedings of the 2010 ACM conference on Computer supported cooperative work, 291 300. Čubranić D. and Booth K. S.. Coordinating open source software development. In WETICE 1999, pages 61 65, 1999. IEEE Computer Society Press. Eclipse. (2014). Bug Reporting FAQ. Retrieved from https://wiki.eclipse.org/bug_reporting_faq English, M., Exton, C., Rigon, I., & Cleary, B. (2009). Fault detection and prediction in an open source software project. Proceedings of the 5th International Conference on Predictor Models in Software Engineering (PROMISE '09). Feng, Z., Khomh, F., Ying, Z., & Hassan, A.E. (2012). An Empirical Study on Factors Impacting Bug Fixing Time. Proceedings of the 19th Working Conference on Reverse Engineering (WCRE), 225 234. Grammel, L., Schackmann, H., Schröter, A., Treude, C., & Storey, M A. (2010). Attracting the community's many eyes: an exploration of user involvement in issue tracking. Proceedings of the Human Aspects of Software Engineering (HAoSE '10). Gunes Koru, A., & Tian, J. (2004). Defect Handling in Medium and Large Open Source Projects. IEEE Software, 21(4), 54 61. Izquierdo Cortazar, D.(2012). Global and Geographically Distributed Work Teams: Understanding the Bug Fixing Process and Potentialy Bug prone Activity Patterns. Proceedings of the 16th European Conference on Software Maintenance and Reengineering (CSMR), 505 508. Anvik, J., Hiew L.and Murphy,G. C.. Proceeding eclipse '05 Proceedings of the 2005 OOPSLA workshop on Eclipse technology exchange Pages 35 39 Crowston K.and Howison J.. The social structure of free and open source software development. First Monday, 10, 2005 Ehrlich K.and Cataldo M., All for one and one for all?: a multi level analysis of communication patterns and individual performance in geographically distributed software development, in Proceedings of the ACM 2012 conference on Computer Supported Cooperative Work, ser. CSCW NY, USA: ACM, 2012, pp. 945 954.

Nakakoji K., Yamamoto Y., Nishinaka Y., Kishida K. and Ye Y.. Evolution patterns of open source software systems and communities. Proceedings of the International Workshop on Principles of Software Evolution Pages 76 85 Krishnamurthy, Sandeep, Cave or Community?: An Empirical Examination of 100 Mature Open Source Projects. First Monday, 2002. Lakhani, Karim and Wolf, Robert G., Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects (September 2003). MIT Sloan Working Paper No. 4425 03 Li, Z., Tan, L., Wang, X., Lu, S., Zhou, Y., Zhai, C. Have Things Changed Now? An Empirical Study of Bug Characteristics in Modern Open Source Software, 2006 Michael Fisher, Martin Pinzger and Harald Gall. Analizing and Relating Bug Report Data for Feature Tracking. WCRE '03 Proceedings of the 10th Working Conference on Reverse Engineering, Page 90, IEEE Computer Society Washington, DC, USA 2003 Mockus, A., Fielding, R.T., & Herbsleb, J.D. (2002). Two case studies of open source software development: Apache and Mozilla. ACM Transactions on Software Engineering and Methodology (TOSEM), 11(3), 309 346. NetMarketShare. (2014). Desktop Operating System Market Share. Retrieved from http://www.netmarketshare.com/operating system market share.aspx?qprid=10&qpcustomd= 0 Ohira, M., Hassan, E.A., & Osawa, N. (2012). The Impact of Bug Management Patterns on Bug Fixing: A Case Study of Eclipse Projects. Proceedings of the 28th IEEE International Conference on Software Maintenance (ICSM 12), 264 273. Rahmani, C., & Khazanchi, D. (2010). A Study on Defect Density of Open Source Software. Proceedings of the 9th International Conference on Computer and Information Science (ICIS), 679 683. Sandusky R., Gasser, and Ripoche G.. Bug report networks: Varieties, strategies, and impacts in a f/oss development community. Proc. of 1st Int'l Workshop on Mining Software Repositories, pages 80 84, 2004. O'Mahony, S. & Ferraro, F. The Emergence of Governance in an Open Source Community, ACAD MANAGE J October 1, 2007 50:5 1079 1106; StatCounter. (2014). StatCounter Global Stats. Retrieved from http://gs.statcounter.com/

West, J., O'Mahony, S. (2005). Contrasting Community Building in Sponsored and Community Founded Open Source Projects. Proceedings of the 38th Annual Hawaii International Conference on System Sciences (HICSS 05), 196. Wilson, G., "Is the open source community setting a bad example?," Software, IEEE, vol.16, no.1, pp.23,25, Jan/Feb 1999 Ying, Z., & Davis, J. (2005). Open source software reliability model: an empirical approach. Proceedings of the fifth workshop on Open source software engineering (5 WOSSE), 1 6. Zanetti, M.S., Scholtes, I., Tessone C.J., & Schweitzer, F. (2013). Categorizing bugs with social networks: a case study on four open source software communities. Proceedings of the 2013 International Conference on Software Engineering (ICSE '13), 1032 1041. Zanetti M. S., Scholtes I., Tessone C. J. and Schweitzer F.. Study on Four Open Source Software Communities. Chair of Systems Design ETH Zurich Zou, F., & Davis, J. (2008). Analyzing and Modeling Open Source Software Bug Report Data. Proceedings of the 19th Australian Conference on Software Engineering (ASWEC 08), 461 469.