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 work. These mechanisms may include one or more of the following: explicit development processes, individual or group code ownership, and required inspections. Apache/Mozilla Conclusions
H3 : In successful open source developments, a group larger by an order of magnitude than the core will repair defects, and a yet large group (by another order of magnitude) will report problems. H4 : 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. Apache/Mozilla Conclusions
H5 : Defect density in open source releases will generally be lower than commercial code that has only been feature-tested, that is, received a comparable level of testing. H6 : In successful open source developments, the developers will also be the users of the software. H7 : OSS developments exhibit very rapid responses to customer problems. Discussion Question
What determines the success of open source projects in the real world? Discussion Questions
In the future will competing open source projects spread scarce resources too thin? Has sourceforge (and other OSS containers) succeeded in spreading open source or made it more difficult to find useful projects? Discussion Question
Given the quality and breadth of open source projects, how can companies sell software? How Companies Sell Software
Companies support their product Users can (potentially) receive assistance Tangible entity to blame when software fails Enterprise software requires greater security and compliance Existing contracts bundle software and hardware People become familiar with a family of products that were pre-installed on their PC Products are developed around dominant software systems OSS lacks awareness in general public/OSS is not in stores OSS leaders do not play golf OSS versus Commercial Development
OSS Commercial -"Many eyeballs implies shallow -Limited testing resources bugs" -Project plan set months in -Updates are published as soon advance as they are implemented -Products involve marketing, -No hard schedule sales, documentation, -Patches and features are not production, hardware, ... sold as features -Assigned to project -Choose where time is spent -Fear of losing your job -No/little income possible -Career advancement concerns -Little accountability (limit involvement in a domain) -Trains thousands of developers The End is Nigh
You will now clap and mean it!
?/!