1. Open Source Project Development – A case study - CSC8350, 4/07/2008 - Instructor: Xiaolin Hu - Presenters: Fasheng Qiu & Xue Wang

2. Outline Introduction –Example –Characteristics –License Case study –FreeBSD Six Hypotheses

3. Introduction Desktop: OpenOffice Browser: Mozilla Firefox Web browser Server: Tomcat, Apache Http Server OS: Linux Platform: Eclipse Language: Perl, Python, PHP Framework: Zope, uPortal Database: MySQL

4. Introduction Open source: a set of principles and practices (adhere to open source definition) on how to write software. –Free Redistribution –Source code –Derived Works –Integrity of the author’s source code –No discrimination against persons or groups or fields of endeavors –Distribution of license Open source software: computer software for which the human-readable source code is made available under a copyright license that meets the Open Source Definition.

5. Introduction Science activity planar (SAP)

6. Introduction

7. FreeBSD license Non-copyleft free software license, compatible with the GNU GPL. Apache License, Version 2.0 Compatible with version 3 of the GPL. LGPL version 3 A free software license, but not a strong copy-left license, it permits linking with non-free modules. It is compatible with GPLv3. GPL version 3 A copyleft license. Suitable for most software packages.

8. Introduction Mozilla Public License (MPL) Not a strong copy-left; A module covered by the GPL and a module covered by the MPL cannot legally be linked together. Eclipse public license This is a free software license. Unfortunately, it has a choice of law clause which makes it incompatible with the GNU GPL.

9. Introduction

10. Case Study/FreeBSD [3] FreeBSD –an open-source version of the unix operating system starting from 1993 –Pure OSS –Successful –Development process well-defined, well- documented, easy to access

11. Case study/FreeBSD Concurrent Version Control Archive (CVS) –contains all of the code and related documentation that is committed to the project from1993 until the present (2003). GNATS database (Bug management system) –Contains information describing all reported problems, as well as the status (such as fixed, under test, or open) of each problem. –Report bug Use the send-pr command of FreeBSD Fill an online form Email Questionnaire to core members

12. Case study/FreeBSD Core team members Committers Contributors Senior developers. Contribute code Around 10 at any time Decide the overall goals Assign privilege, solve conflictions Select, revoke select Change the project CVS Identify job to be done Assign job, test code … Test code Report problems Suggest solution All volunteers Release engineer team members Manage releasing One from core team others from committer

13. Case study/FreeBSD Core Team Members Committers Contributors < 10 at each time two-year terms ~ 50 Select, revoke select > 356 > 6082 1993 - 2003

14. Case study/FreeBSD Core Team Members Committers Contributors < 10 at each time two-year terms ~ 50 Select, revoke select 356- 337 add code 227 fix bugs 183 report bugs > 6082 1993 - 2003

15. Case study/FreeBSD Core Team Members Committers Contributors < 10 at each time two-year terms ~ 50 Select, revoke select 356- 337 add code 227 fix bugs 183 report bugs > 6082 1993 - 2003 People do not primarily Assume a single role

16. Case study/FreeBSD 30% modified by one committer 8% modified by >= 10 committers 26,048.c and.h file Stable version of FreeBSD 25% modified by two committers 15% modified by three committers

17. Case study/FreeBSD 30% modified by one committer 8% modified by >= 10 committers 26,048.c and.h file 25% modified by two committers 15% modified by three committers No code ownership enforced Stable version of FreeBSD

18. Case study/FreeBSD

19. Case study/Apache Pure OSS starting in 1996 Very similar to FreeBSD –The developer roles –Concepts of code ownership –Mechanism to assign tasks to developers Size is smaller than FreeBSD. Testing process before releasing is less well- defined than FreeBSD.

20. Case study/comparison

21. Case study/hypothesis 1. A core of <= 15 core developers will control the code base and contribute most of the new functionality. A group of 50 or fewer top developers at any one time will contribute 80 percent of new functionality. The group will represent < 25% of the set of all developers. 2. As the number of developers need to contribute 80% of OSS code increase, a more well-defined mechanism must be used to coordinate project work. 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 will report problems 4. OSD that have a strong core of developers but never achieve large number 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. 5. Defect density in open source releases will generally be lower than commercial code that has been feature tested. 6. In successful OPD, the developers will also be the user of the software.

22. Case study/hypothesis Hold for FreeBSD, Apache Not for Mozilla ! –Initially commercial. Became open source project in 1998. –The group mozilla.org was charted to act as a central point of contact of dictator for the open source effort –Diverse: Mozilla browser, CVS, Bugzilla, Bonsai, Tinderbox –Code is owned by someone

23. More Questions Does the hypotheses hold for other OOS, smaller OOS, failed OOS? Other hypothesis –OSS developments exhibit very rapid responses to customer problems –…

24. References: Wikipedia http://www.opensource.org/docs/definition.php Trung T. Dinh-Trong and James M. Bieman, The FreeBSD Project: A Replication Case of Open Source Development, IEEE Transactions on Software Engineering, vol. 31, no. 6, pp 481-494, June 2005 A. Mockus, T. Fielding and D. Herbsleb, Two Case Studies of Open Source Software Development: Apache and Mozilla, ACM Trans. Software Eng. And Methodology, vol. 11, no. 3, pp. 309-346, July 2002 Cristina Gacek and Budi Arief, The Many Meanings of Open Source, IEEE Software, January/February 2004 Jeffrey S. Norris, Mission-Critical Development with Open Source Software: Lessons Learned, IEEE Software, January/February 2004

25. Thanks!