(2) Question 2: Size of Mozilla community.

Transcription

1 Open Source Software Development Case Studies CSE564 Group 17 HW1 Shihuan Shao, Tuyue Chen, Yongming Zhang 1. Introduction Open source software(oss) development is considered to be a competitive rivalry of traditional commercial software development. People believe that it can provide softwares with at least equal quality to conventional development in a faster and cheaper manner. To investigate this topic, some successful open source projects were analyzed by studying their lists, version control systems, online code repositories and problem reporting databases. Researchers were attempting to study the cases by answering the following questions: Question 1: What was the development process of the project? Question 2: How many people developed the new functionality? How many people reported bugs? How many people fixed bugs? Question 3: Did people play single or multiple roles in the development? Was most work completed by a large number of people or a small number? Question 4: Was there any explicit code ownership? Question 5: What is the defect density? Question 6: How long did it take to resolve a bug? Was there any priority among the bugs? Did the solution interval decrease over time? 2. Case Study: Apache (1) Question 1: Development process Apache HTTP Server Project was a pure open source project. The core team managing the project was an informal organization called Apache Group(AG), the members of which were all volunteers located around the world. [1] so they usually used lists as the communication tool. Whenever a decision was needed, a voting system based on would be used. [2] The development process includes: [2] 1. Discovering problems. Developer list is the major method to report problems. 2. Finding volunteers who were interested to work on the problem. 3. Identifying the optimal solution and getting feedbacks from other developers. 4. Testing the changes on local copy, submitting them to list for review and approval, and committing them. Each commit was be visible by other developers through list. 5. Preparing for release. Before each release, one of the core developers would volunteer to be the release manager. He would make sure that all critical issues were identified and solved, the software had achieved a stable status, and control the access to the code repository. (2) Question 2: Size of Apache community About 400 developers contributed code. 182 people contributed code to 695 problem repair changes, while 249 contributed to new function changes. [2] 3060 people submitted 3975 problem reports, among which 591 reports by 458 contributors actually caused changes to the project. [2]

2 (3) Question 3: Work distribution The top 15 developers contributed more than 83% of the modification requests(mr), 88% of added lines, 91% of deleted lines, and 66% of the problem report(pr) changes. The production of the Apache core group was at least the same with commercial development. In terms of problem discovery, non-core contributors submitted more than 95% of the PRs. [2] A module can be modified by multiple developers, and code ownership was only respect and recognition of contribution and expertise. So actually no explicit code ownership was enforced. [2] It was difficult to investigate the absolute defect density, so the authors compared the pre-system test defects with those in five commercial projects. The result showed that the defect density of Apache was much lower than those commercial projects. [2] (6) Question 6: Time and priority to fix problems It took one day to solve 50% of PRs, 42 days for 75% of PRs and 140 days for 90% of PRs. PRs with higher priority got closed faster. Moreover, the resolution interval during the late phase was significantly shorter than that in the early phase. [2] 3. Case Study: Mozilla (1) Question 1: Development process Mozilla is a hybrid rather than a pure OSS project. It is developed from the commercial project of Netscape s browser, and then opened its source code to take the advantage of open source community to survive. Now the development and maintenance of Mozilla is managed by mozilla.org. mozilla.org staff and some external workers get paid for this project. mozilla.org has ultimate decision authority, permission to add new modules, and the right to assign and remove code ownership to developers. A module can be modified with module owner s authorization. [3] Generally, the process can be summarized as below: 1. Identifying tasks (develop new features or report problems) according to the roadmap made by mozilla.com. 2. Assigning the task to someone interested and completing it. 3. Building the project and running minimal test everyday. Fixing the problems as soon as possible if any. 4. Module owner reviews the changes for the the module, and a small group of super-reviewers inspects the changes for the whole project. 5. Issuing milestone release every month. (2) Question 2: Size of Mozilla community.

3 486 developers contributed new feature code and 412 contributed PR fix code people submitted 58K PRs, among which reports by 1403 people actually caused changes to the project. [3] (3) Question 3: Work distribution Internal participants contributed more to code changes while the external did more in problem reporting. 5% of the 6873 contributors were internal but they were responsible for 47% of PRs. [3] 113 contributors submitted 50% PRs among which the top one submitted more than 1000 reports. 46 of them did not do any coding, which indicates there was a group specifically focusing on testing. [3] Since many core developers are full time staff, Mozilla achieves very high productivity: the most productive developers in each module contributed 83% of MRs and 88% of added lines. One person was the most productive one in seven modules, and there are 38 developers who are the most productive one in at least two modules. [3] Mozilla has explicit code ownership policy. The module owner of each module is responsible for maintaining his module, and review all the changes submitted by other developers. Changes submitted by other developers must be reviewed by module owner before committing. [3] All the PRs of Mozilla result from pre-release test rather than pre-system test. The defect density of Mozilla was similar to that of Apache, and significantly lower than the pre-release tests of commercial projects used in the case study of Apache, while it was much higher than that of commercial products. [3] (6) Question 6: Time and priority to fix problems Due to the code inspection step, the resolution interval was much larger than that of Apache. The middle number of PR resolution was larger than 15 days, and smaller than 30 days. The interval was significantly related to priority. PRs with high priority got resolved within 30 days, while those with lower priority needed 80 days or more than 100 days. Besides, the interval was also related to modules. With increasing maturity and participants, the interval in the second phase was much lower than that in the first phase. [3] 4. Case Study: FreeBSD For FreeBSD, the case study obtained data to cover the first five problems (1)Question 1: Development process FreeBSD is an Unix-like operating system derived from BSD Unix. It is developed in a pure OSS project where all participants are volunteers. There are three types of participants. Core Team is the group of senior developers who guide the direction of the project. Committers are the developers with the access to commit to CVS repository. Contributors are the people who do the testing, report problems, suggest solutions but not commit code. [4]

4 The development process of the FreeBSD operating system is summarized as following. 1. Identifying the work, mainly developing new feature and fixing existing bugs, to be done. 2. Finding appropriate volunteers. Contributor can find PR through bug report database and decide whether to solve it. 3. Performing development work. Contributors can do the change the local branch and send the solution to committer. Committers test the solution made by himself or contributor, and insert it into Current or Stable code base. 4. Testing. Code needs to be tested by committers and/or other developers before committed into Current branch, Stable branch and release. 5. Inspecting code. Changes into other committer s module needs to be reviewed by that committer. Important changes also needs other committers review. 6. Preparing for release. A new version is released every four months. The operations before release include: integrating new changes into Stable branch, reviewing code and freezing code. (2) Question 2: Size of FreeBSD community 354 committers committed code into the CVS repository. 197 committers made commits to fix bugs, and 290 committers made 300k commits for new features. At least 6,082 participants reported 16,115 problems. [5] (3) Question 3: Work distribution The top 15 committers wrote 56% of the new feature code, the top 50 wrote 80%, and the 36 people in the Core Team wrote 75%. The top 15 contributors fixed 40% of the issues, and the top 50 fixed 70%. The top 15 reporters reported 49 to 100 problems each, which represents the 0.6 % of the problem reports reporters reported one problem. [5] FreeBSD project does not enforce explicit code ownership, so a committer can modify the any file, and a file can be modified by multiple commiter. However, before a committer commits changes to a module actively maintained by others, he is still required to ask them to review. [5] The authors compared the defects number in FreeBSD and the commercial projects used in Apache case, concluding that the defect density is lower than those commercial projects after feature tests. [5] Seven hypotheses were extracted according to the answers to the questions above, and the projects were checked against these hypotheses and revised. Hypothesis 1: Open source developments will have a core of developers who control the code base, and will create approximately 80% or more of the new functionality. If this core group uses only informal, ad hoc means of coordinating their work, it will be no larger than people. [3] Hypothesis 2: If a project is so large that more than people are required to complete 80%

5 of the code in the desired time frame, then other mechanisms, rather than just informal, ad hoc arrangements, will be required in order to coordinate the work. These mechanisms may include one or more of the following: explicit development processes, individual or group code ownership, and required inspections. [3] Hypothesis 3: In successful open source developments, a group larger by an order of magnitude than the core will repair defects, and a yet larger group (by another order of magnitude) will report problems. [3] Hypothesis 4: Open source developments that have a strong core of developers but never achieve large numbers of contributors beyond that core will be able to create new functionality but will fail because of a lack of resources devoted to finding and repairing defects. [3] Hypothesis 5: Defect density in open source releases will generally be lower than commercial code that has only been feature-tested, i.e., received a comparable level of testing. [3] Hypothesis 6: In a successful open source development, the developers will use the products they developed. [3] Hypothesis 7: Open source development shows faster response to problems reported by user. [3] 5. References: 1. Roy T. Fielding. Shared leadership in the Apache project. Communications of the ACMI 42, no. 4 (1999): Mockus, Audris, Roy T. Fielding, and James Herbsleb. "A case study of open source software development: the Apache server." In Software Engineering, Proceedings of the 2000 International Conference on, pp IEEE, Mockus, Audris, Roy T. Fielding, and James D. Herbsleb. "Two case studies of open source software development: Apache and Mozilla." ACM Transactions on Software Engineering and Methodology (TOSEM) 11, no. 3 (2002): Dinh-Trong, Trung T., and James M. Bieman. "The FreeBSD project: A replication case study of open source development." Software Engineering, IEEE Transactions on 31, no. 6 (2005): Dinh-Trong, Trung, and James M. Bieman. "Open source software development: a case study of FreeBSD." In Software Metrics, Proceedings. 10th International Symposium on, pp IEEE, 2004.