Open Source III GNOME, Apache, Mozilla Justin Enderle & Seth Holloway EE382V - Perry 02/19/2008 Papers The GNOME Project: a Case Study of Open Source, Global Software Development , 2003. Author: Daniel German Two Case Studies of Open Source Software Development: Apache and Mozilla , 2001. Authors: Audris Mockus Roy T Fielding James D Herbsleb GNOME Paper Daniel German, the author, was an active contributor to GNOME from 1999-2001, GNOME Foundation member as of 2003 Introduction to GNOME organizational structure and design methods. Information sources Personal experiences, "immersion study" CVS repository mailing list archives GNOME Overview GNOME = GNU Network Object Model Environment Started in 1996 by Miguel de Icaza An alternative to KDE, which used non-free software for development Collection of libraries to make Linux a viable desktop alternative Components Easy to use GUI environment 'Office Suite' of applications Tools, libraries and components for development and application Paper Highlights / Drawbacks (+) Author is intimately familiar with GNOME (+) Nice introduction to GNOME and it's background (-) Author cites himself 3 times (-) Whole paper spent describing GNOME (-) No critical look at relevant SW engineering topics (-) Lacks detailed quantitative analysis of GNOME Apache/Mozilla Paper Authors Roy Fielding was a primary author of HTTP Mockus is a SW engineer working at AVAYA Herblseb is a professor at CMU Paper sets out to Characterize OSS development Compare to traditional software methods Describe prospects for OSS Data Sources OSS Email CVS BugDB/Bugzilla Commercial ECMS/SCCS Apache Overview "A patchy" web server that is skillful and reliable in battle Grew out of NCSA HTTPd 1.3 Apache HTTPd 2.0 was developed to improve modularization and portability Serves most pages (~51%) on the Internet Released under the Apache License (copyright) Success spawned more work and led to Apache Foundation Apache Foundation Projects Web servers HTTP server Tomcat Programming languages Perl TCL Build support Ant Maven Reusable code Xerces ... Mozilla Overview Mozilla was the codename of Netscape Navigator and mascot Mozilla was the integrated internet suite Grew out of Netscape Navigator Became too bloated and split into more-specialized projects Firefox Thunderbird SeaMonkey Released under Mozilla License (weak copyleft) Now, the Mozilla Organization and the Mozilla Foundation Paper Highlights / Drawbacks (+) Very well written (+) Knowledgeable authors (+) Great empirical study good rationale, accepted methodology, well known metrics, statistically sound (+) Amazing example of how to make your work into a paper (+) Important information about OSS (-) Long (-) Dry (?) The paper was written after both sets of data were analyzed... Did they really hypothesize before getting secondary data? :) Discussion Questions Who uses products by Mozilla? Apache? GNOME? Discussion Questions Does anyone contribute to open source projects? If so, what project(s)? Why? If not, why not? What is your dream project? Ways to contribute to OSS How could an individual contribute to OSS? Ways to contribute to OSS Write code Internationalize/translate Find and report defects Manage release Promote the product Provide technical support Document the code, development process, and usage Design the interface Provide artistic works Communication What are the most effective ways to communicate in a highly distributed group? Communication Methods Mailing lists IRC Web sites Project-specific Conferences Summaries periodically sent to mailing list Structure/Organization How would you structure a large group consisting of project contributors and users? GNOME Organization No single GNOME maintainer Modularized architecture ==> Modularized development 76 modules of libraries and core apps in Spring 04 Modules have own set of maintainers, developers, time lines, and objectives. Originally run as a pseudo legislature All contributors have a voice the 'floor' is the developers mailing lists Miguel de Icaza the 'constitutional monarch' and 'supreme court' GNOME Foundation Corporate interest in GNOME success Red-Hat and SUN using for desktop environment Two companies (Eazel and Ximian) spawned to sell services Large number of corporate contributors Concerns that large number of industry contributors could use their votes to hijack the project GNOME Foundation created in 2000 Mitigate industry influence Democratic process where community can have a voice GNOME decisions made in open and transparent way GNOME Organization Release Team 6 month time-based releases Determine schedules and keep project on track Set and monitor test release dates Code freezes Version 2.4 Release schedule GNOME Organization More than 500 people have write access to CVS repository Top 10 programmers account for 46% of total Modification Requests (MR's) MR's per developer for Evolution mail client GNOME Organization Contributors more likely to join the project earlier than late, due to more glory and respect involved Methods in place to help attract new contributors bug fixing TODO lists GNOME-love mailing list Active developers per month Apache Organization Structured similarly to GNOME Leverage users as developers and contributors almost 400 developers total 3060 people submitted problem reports 306 people reported 2 PRs 85 submitted 3 1 submitted 32 458 individuals' reports led to changes 182 people worked on fixes Apache Organization Top 15 developers 83% of MRs/deltas contributed 88% of added lines 91% of deleted lines Apache Organization Top 15 Apache developers were more productive than top 15 commercial developers in other projects Apache Organization Modular architecture facilitates distributed development Multiple people responsible for individual files Mutual trust amongst developers Code ownership is a matter of expertise Software Development Process How would you develop software for open source? GNOME Process Where is the guiding light? Vision provided by one or several leaders Reference applications, ex: Microsoft Office Suite Mailing list discussions Prototypes Post-hoc additions Maintainers largely responsible for breaking up module level tasks for individuals Paper does not address influence of industry on requirements, or level to which above are influential Apache Development Process All developers had outside jobs =>Needed decentralized decision-making abilities =>Apache Group (AG) consists of core members General Process 1. Find work (bug or new functionality) 2. Determine developer 3. Identify solution 4. Develop and test locally 5. Present change to AG 6. Commit code, update documentation Apache Development Process General Process 1. Find work (bug or new functionality) Bugs submitted to mailing list, BugDB, USENET 2. Determine developer Core issue: core developer Other issue: area expert ... newbie 3. Identify solution Discuss alternatives on mailing list Apache Development Process General Process (continued) 4. Develop and test locally Left up to owner 5. Present change to AG Code approved before release Development branch: reviewed after commit Stable release: reviewed before commit 6. Commit code, update documentation Left up to owner Discussion Questions Is OSS architected better than commercial products? Does the success of all software depend on the architecture? Are successful OSS projects "better" architecturally than their commercial competitors? Which has more defects? How quickly are defects fixed? Software Quality What is the level of software quality in open source projects? Apache Quality Expect more bugs in Apache due to widespread usage Competitive with industry Apache Quality 50% of defects are resolved in 1 day 75% in 42 days 100% in 500 days Competitive with industrial development Industry affiliation For OSS, what are the risks/rewards of close collaboration with industry affiliates? GNOME Industry Affiliation Red-Hat and Sun interested in GNOME to enable viable desktop alternative Companies spawned to sell services around GNOME Ximian founded by Miguel de Icaza and other GNOME founders Top 10 most active developers (as proportion of MR's) shown to be affiliated with Ximian employees or consultants Industry employees often responsible for tasks undesirable to volunteers Project coordination Testing Documentation Bug fixing Apache/Mozilla Industry Affiliation Both have ties to industry IBM WebSphere application server uses Apache Google, IBM, others employ Mozilla committers Lessons Learned Are there any lessons that commercial software companies can learn from open source? Lessons "Learned" from GNOME Potential points of benefit Flatten the organization Multiple types of communication Treat developers as partners Regularly scheduled co-located meetings Task forces Procedures for conflict management Modularize Ask developers to document daily contributions States FOSS significantly different than commercial, so these may not apply. Does not enumerate differences or how they may effect lessons learned. Apache/Mozilla Conclusions H1 : 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, the group will be no larger than 10 to 15 people. H2: If a project is so large that more than 10 to 15 people are required to complete 80% 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